Demystifying Okta Attacks with Dorothy and Splunk
Overview
Okta is a leading identity and access management (IAM) platform designed to help organizations securely manage and streamline user authentication and authorization. It provides a comprehensive suite of services, including single sign-on (SSO), multi-factor authentication (MFA), lifecycle management, and API access management. Okta enables organizations to ensure secure access to applications and data for employees, partners, and customers, whether they are using on-premises or cloud-based applications. With robust security features, detailed auditing, and extensive integration capabilities, Okta helps enhance security, improve user experience, and simplify IT management.
The Okta System Log is a detailed logging and auditing tool that tracks and records all system activities and events within the Okta environment. It provides a comprehensive and searchable record of actions such as user logins, authentication attempts, role changes, application accesses, and administrative actions. The System Log is essential for monitoring security events, troubleshooting issues, ensuring compliance, and conducting forensic analysis. It offers real-time visibility and insights into user behaviors and system operations, helping organizations maintain a secure and well-managed identity and access management system. By ingesting these logs into our SEIM we are able to hunt and detect activity alongside all our other logsources.
In this blog we are going to break down various attacks against Okta and how to identify them in Splunk. Some of the logs shown in this blog will be truncated to show the important parts for brevity.
Dorothy
We utilized Dorothy from the Elastic team for our attacks. Dorothy is a tool to help security teams test their monitoring and detection capabilities for their Okta environment. Dorothy has several modules to simulate actions that an attacker might take while operating in an Okta environment and actions that security teams should be able to audit. The modules are mapped to the relevant MITRE ATT&CK® tactics, such as persistence, defense evasion, and discovery. We focused on the Defense Evasion, Impact, and Persistence modules. Most Discovery commands did not appear to create events in the Okta System Log.
Dorothy Modules
dorothy > list-modules
+-------------------------+------------------------+---------------------------------------------------------------+
| Tactics | Module Name | Description |
+-------------------------+------------------------+---------------------------------------------------------------+
| Discovery | whoami | Get info for user linked with current API token |
| Discovery | get-users | Harvest information on all Okta users |
| Discovery | find-admins | Identify Okta users with admin roles assigned |
| Discovery | get-policies | Harvest information on all Okta policies and policy rules |
| Discovery | get-groups | Harvest information on all Okta groups |
| Discovery | get-user | Get an Okta user's profile info and group memberships |
| Discovery | get-policy | Get an Okta policy and its rules |
| Discovery | get-zones | Harvest information on all Okta network zones |
| Discovery | find-admin-groups | Identify Okta groups with admin roles assigned |
| Discovery | find-users-without-mfa | Identify Okta users with no MFA factors enrolled |
| Discovery | get-apps | Harvest information on all Okta applications |
| Defense Evasion, Impact | change-rule-state | Deactivate or activate a rule in an Okta policy |
| Defense Evasion, Impact | modify-policy-rule | Make a temporary change to a rule in an Okta policy |
| Defense Evasion, Impact | change-policy-state | Deactivate or activate an Okta policy |
| Defense Evasion, Impact | change-zone-state | Deactivate or activate an Okta network zone |
| Defense Evasion, Impact | modify-policy | Make a temporary change to an Okta policy |
| Defense Evasion, Impact | modify-zone | Make a temporary change to an Okta network zone |
| Defense Evasion, Impact | change-app-state | Deactivate or activate an Okta application |
| Persistence | create-user | Create and activate an Okta user with an assigned password |
| Persistence, Impact | change-user-state | Change an Okta user's state by executing lifecycle operations |
| Persistence | reset-factors | Reset all MFA factors for an Okta user |
| Persistence | set-recovery-question | Set the recovery question and answer for an Okta user |
| Persistence | create-admin-user | Assign an admin role to an Okta user |
| Persistence | delete-factor | Remove a MFA factor for a specified Okta user |
| Persistence | create-admin-group | Assign an admin role to an Okta group |
| Persistence | reset-password | Generate a one-time token to reset a user's password |
| - | manage-config | Manage Dorothy's configuration profiles |
+-------------------------+------------------------+---------------------------------------------------------------+
Change Rule State
This attack deactivates or activates a rule in an Okta policy. An Okta policy plays a crucial role in managing and enforcing security and access controls within the Okta environment. Policies define rules and conditions that govern user authentication, password management, multi-factor authentication (MFA), and access to applications and resources.
Looking at the logs for this attack there will be a policy.rule.deactivate event triggered by a call to /api/v1/policies/<policyid>/rules/<ruleid>/lifecycle/deactivate.
The important part of this log when hunting for this activity will be the eventType and legacyEventType fields. The details around what rule was deactivated will be in the target field.
displayMessage: Deactivate policy rule
eventType: policy.rule.deactivate
outcome:
result: SUCCESS
reason: null
published: 2024-06-10T16:53:34.255Z
securityContext:
asNumber: 701
asOrg: verizon
isp: verizon
domain: verizon.net
isProxy: false
severity: INFO
debugContext:
debugData:
requestId: 6d3716c6a3ff70b72f74f84b97c63f25
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
requestUri: /api/v1/policies/00phla2qxfNgG3sYb5d7/rules/0prhla3j02zFqqDIG5d7/lifecycle/deactivate
url: /api/v1/policies/00phla2qxfNgG3sYb5d7/rules/0prhla3j02zFqqDIG5d7/lifecycle/deactivate?
legacyEventType: policy.rule.deactivated
transaction:
type: WEB
id: 6d3716c6a3ff70b72f74f84b97c63f25
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: f96d23f3-2749-11ef-8475-cde5bcd7155e
version: "0"
target:
- id: 00phla2qxfNgG3sYb5d7
type: PolicyEntity
alternateId: unknown
displayName: Test
detailEntry:
policyType: OktaSignOn
- id: 0prhla3j02zFqqDIG5d7
type: PolicyRule
alternateId: 00phla2qxfNgG3sYb5d7
displayName: Test Rule
detailEntry: null
For more information about this attack and additional logs see Okta — Change Policy Rule State
For detections see our Okta Collection.
Modify Policy Rule
In addition to deactivating the rule, an attacker can also modify the rules of a policy. The eventType for this attack will be a policy.rule.update. The log will also include details about the old policy rule and the changed version. This can give great insights into what an attacker modified about the rule.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
severity: INFO
debugContext:
debugData:
oldPolicyRulePriority: "1"
oldPolicyRuleAction: |
[
{
"actionType": "signon",
"properties": {
"maxSessionLifetimeMinutes": 0,
"access": "ALLOW",
"factorPromptMode": "ALWAYS",
"usePersistentCookies": false,
"maxSessionIdleMinutes": 720,
"requireFactor": true,
"TYPE": "signon",
"primaryFactor": "PASSWORD_IDP"
}
}
]
newPolicyRuleAction: |
[
{
"actionType": "signon",
"properties": {
"maxSessionLifetimeMinutes": 0,
"access": "ALLOW",
"factorPromptMode": "ALWAYS",
"usePersistentCookies": false,
"maxSessionIdleMinutes": 720,
"requireFactor": true,
"TYPE": "signon",
"primaryFactor": "PASSWORD_IDP"
}
}
]
requestId: 72454a07a9322fedfb53fc924550604b
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
newPolicyRuleName: Test Rule TEMP_STRING
oldPolicyRuleConditionsJson: |
[
{
"lastUpdatedBy": "00u5r5dwce6yRXsCI5d7",
"createdDate": 1717770429000,
"policyId": "00phla2qxfNgG3sYb5d7",
"data": {"level": "ANY"},
"createdBy": "00u5r5dwce6yRXsCI5d7",
"lastUpdate": 1717770607000,
"conditionType": "riskScore",
"id": "0rchla3j05S1XTk5U5d7",
"ruleId": "0prhla3j02zFqqDIG5d7",
"version": 0,
"orgId": "00o4l63wddWDH7vWK5d7",
"status": "ACTIVE"
},
...
{
"lastUpdatedBy": "00u5r5dwce6yRXsCI5d7",
"createdDate": 1717770429000,
"policyId": "00phla2qxfNgG3sYb5d7",
"data": {"behaviors": []},
"createdBy": "00u5r5dwce6yRXsCI5d7",
"lastUpdate": 1717770607000,
"conditionType": "risk",
"id": "0rchla3j04SRG9VNV5d7",
"ruleId": "0prhla3j02zFqqDIG5d7",
"version": 0,
"orgId": "00o4l63wddWDH7vWK5d7",
"status": "ACTIVE"
}
]
newPolicyRuleConditionsJson: |
[
{
"lastUpdatedBy": "00u5r5dwce6yRXsCI5d7",
"createdDate": 1717770429000,
"policyId": "00phla2qxfNgG3sYb5d7",
"data": {"level": "ANY"},
"createdBy": "00u5r5dwce6yRXsCI5d7",
"lastUpdate": 1717770636000,
"conditionType": "riskScore",
"id": "0rchla3j05S1XTk5U5d7",
"ruleId": "0prhla3j02zFqqDIG5d7",
"version": 0,
"orgId": "00o4l63wddWDH7vWK5d7",
"status": "ACTIVE"
},
{
"lastUpdatedBy": "00u5r5dwce6yRXsCI5d7",
"createdDate": 1717770429000,
"policyId
For more information about this attack and additional logs see Okta — Modify Policy Rule
For detections see our Okta Collection.
Change Policy State
Another action that a bad actor can take is completely deactivating policies as a whole. Since these policies control security and access controls, disabling one can drastically change how the Okta environment functions.
For this one the eventType we are concerned with is policy.lifecycle.deactivated. The target fields will contain the policy that was changed as well as some basic information around it. In our test we used a policy that controlled Okta Sign On controls.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Deactivate policy
eventType: policy.lifecycle.deactivate
outcome:
result: SUCCESS
reason: null
published: 2024-06-07T14:32:12.141Z
securityContext:
asNumber: 701
asOrg: verizon
isp: verizon
domain: verizon.net
isProxy: false
severity: INFO
debugContext:
debugData:
requestId: 50ec2f47800fec7849ffa8d445b2cc71
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
requestUri: /api/v1/policies/00phla2qxfNgG3sYb5d7/lifecycle/deactivate
url: /api/v1/policies/00phla2qxfNgG3sYb5d7/lifecycle/deactivate?
legacyEventType: policy.deactivated
transaction:
type: WEB
id: 50ec2f47800fec7849ffa8d445b2cc71
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: ba740271-24da-11ef-9640-41c042218b54
version: "0"
...
target:
- id: 00phla2qxfNgG3sYb5d7
type: PolicyEntity
alternateId: unknown
displayName: Test
detailEntry:
policyType: OktaSignOn
For more information about this attack and additional logs see Okta — Modify Policy State
For detections see our Okta Collection.
Modifying Okta Network Zone States
In an Okta environment, Network Zones are used to define specific ranges of IP addresses that can be grouped together for security and access management purposes. They allow administrators to create policies that apply to certain geographic locations or network segments, enhancing security by controlling access based on where a request originates. Network Zones can be used to enforce security measures such as requiring multi-factor authentication (MFA) for logins from outside trusted zones, blocking access from untrusted locations, or applying different access policies based on the network zone of the user.
Deactivating one of these zones can also drastically change the security of the environment. The eventType we are concerned with will be a zone.deactivate.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Network zone deactivate
eventType: zone.deactivate
outcome:
result: SUCCESS
reason: null
published: 2024-06-06T17:53:18.074Z
securityContext:
asNumber: 701
asOrg: verizon
isp: verizon
domain: verizon.net
isProxy: false
severity: INFO
debugContext:
debugData:
zoneData: '{"type":"IP","gateways":[{"type":"RANGE","value":"192.168.200.200-192.168.200.200"}],"proxies":[]}'
requestId: f10368bf9c5741046b51f603793888e4
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
requestUri: /api/v1/zones/nzo5tvh54fc8joGxy5d7/lifecycle/deactivate
url: /api/v1/zones/nzo5tvh54fc8joGxy5d7/lifecycle/deactivate?
legacyEventType: zone.deactivate
transaction:
type: WEB
id: f10368bf9c5741046b51f603793888e4
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: a7e585b8-242d-11ef-aa93-2b6480755fae
version: "0"
...
target:
- id: nzo5tvh54fc8joGxy5d7
type: NetworkZoneEntity
alternateId: unknown
displayName: Test Zone
detailEntry: null
We can see the Zone that was deactivated (Test Zone) in the target field.
For more information on this attack and additional logs see Okta — Modify Zone Activation State
For detections see our Okta Collection.
User Actions
In addition to messing with the security controls of Okta, an attacker can create or modify users and groups. These actions are thankfully logged in the system log so we can hunt for them.
Unlike some of the previous attacks we’ve looked at the user actions are a bit more complex. Looking at the logs for a new user being created we see multiple actions happening in the background. First the User is created and has their password and MFA factors set.
displayMessage: Activate factor for user
target{}.alternateId: [email protected]
target{}.displayName: mal icious
target{}.type: User
extracted_eventType: user.mfa.factor.activate
legacyEventType: core.user.factor.activate
displayMessage: Create okta user
target{}.alternateId: [email protected]
target{}.displayName: mal icious
target{}.type: User
extracted_eventType: user.lifecycle.create
legacyEventType: core.user.config.user_creation.success
displayMessage: User update password for Okta
target{}.alternateId: [email protected]
target{}.displayName: mal icious
target{}.type: User
extracted_eventType: user.account.update_password
legacyEventType: core.user.config.password_update.success
Then if you have any applications configured the user is pushed and synced with the applications
displayMessage: Push new user to external application
target{}.alternateId: [email protected], [email protected], Test App (Basic Auth)
target{}.displayName: mal icious, mal icious, Test App (Basic Auth)
target{}.type: AppUser, User, AppInstance
extracted_eventType: application.provision.user.push
legacyEventType: app.user_management.push_new_user
displayMessage: Sync user in external application
target{}.alternateId: [email protected], [email protected], Test App (Basic Auth)
target{}.displayName: mal icious, mal icious, Test App (Basic Auth)
target{}.type: AppUser, User, AppInstance
extracted_eventType: application.provision.user.sync
legacyEventType: app.user_management.provision_user_success
Finally the account is activated.
displayMessage: Activate Okta user
target{}.alternateId: [email protected]
target{}.displayName: mal icious
target{}.type: User
extracted_eventType: user.lifecycle.activate
legacyEventType: core.user.config.user_activated
If the compromised account the attacker is using to interact with Okta has the permissions for it, they can also add Administrative roles to the new user they created. This will create several logs around the admin permissions being granted, and updates to okta applications.
First is the permissions being added to the user.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Grant user privilege
eventType: user.account.privilege.grant
outcome:
result: SUCCESS
reason: null
published: 2024-06-06T16:26:35.238Z
...
severity: INFO
debugContext:
debugData:
requestId: edeea9ff2ad50c09bbdaa48f217734a6
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
privilegeGranted: Super administrator
requestUri: /api/v1/users/00u5uyih6hSy0QEAm5d7/roles
url: /api/v1/users/00u5uyih6hSy0QEAm5d7/roles?
legacyEventType: core.user.admin_privilege.granted
transaction:
type: WEB
id: edeea9ff2ad50c09bbdaa48f217734a6
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: 8ac3c068-2421-11ef-9337-6d2a3a21e5b0
version: "0"
...
target:
- id: 00u5uyih6hSy0QEAm5d7
type: User
alternateId: [email protected]
displayName: mal icious
detailEntry: null
Then the user is added to the Okta Admin application.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Add user to application membership
eventType: application.user_membership.add
outcome:
result: SUCCESS
reason: null
published: 2024-06-06T16:26:35.171Z
...
severity: INFO
debugContext:
debugData:
appname: saasure
requestId: edeea9ff2ad50c09bbdaa48f217734a6
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
requestUri: /api/v1/users/00u5uyih6hSy0QEAm5d7/roles
url: /api/v1/users/00u5uyih6hSy0QEAm5d7/roles?
legacyEventType: app.generic.provision.assign_user_to_app
transaction:
type: WEB
id: edeea9ff2ad50c09bbdaa48f217734a6
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: 8ab98732-2421-11ef-9337-6d2a3a21e5b0
version: "0"
...
target:
- id: 0uahkjc721ewRxrS55d7
type: AppUser
alternateId: unknown
displayName: mal icious
detailEntry: null
- id: 0oa4l63wdmecYnNHr5d7
type: AppInstance
alternateId: Okta Admin Console
displayName: Okta Admin Console
detailEntry: null
- id: 00u5uyih6hSy0QEAm5d7
type: User
alternateId: [email protected]
displayName: mal icious
detailEntry: null
Admin roles can also be applied directly to a group instead of an individual user. This will first add the new privileges to the group itself. The permissions being added are actually not in the target block in this log. Instead it will be in the debugContext under privilegeGranted.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Grant group privilege
eventType: group.privilege.grant
outcome:
result: SUCCESS
reason: null
published: 2024-06-07T15:54:35.140Z
...
severity: INFO
debugContext:
debugData:
requestId: 6d751b880e11731c7b5324290f6d946a
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
privilegeGranted: Super administrator, Application administrator (all)
requestUri: /api/v1/groups/00g5ss3x36wbgzBZL5d7/roles
url: /api/v1/groups/00g5ss3x36wbgzBZL5d7/roles?
legacyEventType: core.group.admin_privilege.granted
transaction:
type: WEB
id: 6d751b880e11731c7b5324290f6d946a
detail:
requestApiTokenId: 00T21qqyrlYTrCf1R5d7
uuid: 3cb5cc48-24e6-11ef-bc24-21ecf840f902
version: "0"
...
target:
- id: 00g5ss3x36wbgzBZL5d7
type: UserGroup
alternateId: unknown
displayName: Test Group
detailEntry: null
Then the accounts under that group will gain the privileges. Again, the roles being added are in the privilegeGranted section.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
displayMessage: Grant user privilege
eventType: user.account.privilege.grant
outcome:
result: SUCCESS
reason: null
...
debugContext:
debugData:
privilegeGranted: Super administrator, Application administrator (all)
legacyEventType: core.user.admin_privilege.granted
transaction:
type: JOB
id: rtchld0dw4KnrQIQ85d7
detail: {}
uuid: 3e2561f0-24e6-11ef-858a-27ea5eadd3ac
version: "0"
...
target:
- id: 00u5ss6iqnVcGyjbD5d7
type: User
alternateId: [email protected]
displayName: mal icious
detailEntry: null
Another user action that an attacker can perform is deleting accounts. This will create a few logs around clearing the user session, deactivating the user, and removing its application memberships. For more information about these attacks and additional logs see:
Okta — Add Admin Role
Okta — Create Admin
Okta — Create User
Okta — Delete User
For detections see our Okta Collection.
MFA Factors
An attacker can also interact with other facets of user security such as Multi-Factor Authentication (MFA) factors. Resetting MFA factors in Okta removes all the existing MFA methods configured for a user. This action forces the user to re-enroll their MFA devices or methods the next time they log in. This can weaken the security around another account that the attacker might be trying to access.
The Okta system log does log this event with user.mfa.fctor.reset_all. Here is an example.
actor:
id: 00u5r5dwce6yRXsCI5d7
type: User
alternateId: [email protected]
displayName: Okta User
detailEntry: null
...
displayMessage: Reset all factors for user
eventType: user.mfa.factor.reset_all
outcome:
result: SUCCESS
reason: null
published: 2024-06-06T16:47:18.553Z
...
severity: INFO
debugContext:
debugData:
requestId: 8712a62a9e3a4b17e2737c8c2d948776
dtHash: 9e688d4a4c77945604ff1c4b0bc7d2e81022e97df113168d17129080bfe5a309
requestUri: /api/v1/users/00u5uyih6hSy0QEAm5d7/lifecycle/reset_factors
url: /api/v1/users/00u5uyih6hSy0QEAm5d7/lifecycle/reset_factors?
legacyEventType: core.user.factor.reset_all
transaction:
type: WEB
id: 8712a62a9e3a4b17e2737c8c2d948776
detail: {}
uuid: 6fd690a5-2424-11ef-9837-d3eb8d8f4615
version: "0"
...
target:
- id: 00u5uyih6hSy0QEAm5d7
type: User
alternateId: [email protected]
displayName: Test User
detailEntry: null
In addition to reseting the MFA factors, an attacker can also delete specific factors from the account. This will weaken the security and potentially enable account compromise. For more information about these attacks and additional logs see:
Okta — Reset MFA Factors
Okta — Delete MFA Factor
For detections see our Okta Collection.
Passwords
Another serious action that an attacker can attempt is to reset a users password. This would enable them to generate a reset token, use that token to reset the password for the account, and then sign in using the new credentials. This is one of the noiser activities in the okta logs and generates a ton of events. Here is the important snippets from several of these system log events.
published: 2024-06-06T16:45:45.787Z
displayMessage: Fired when the user's Okta password is reset
extracted_eventType: user.account.reset_password
legacyEventType: core.user.config.user_status.password_reset
debugContext.debugData.requestUri: /api/v1/users/00u5uyih6hSy0QEAm5d7/lifecycle/reset_password
target{}.displayName: Test User
target{}.type: User
published: 2024-06-06T16:46:03.252Z
displayMessage: Verify user identity
extracted_eventType: user.authentication.verify
legacyEventType: nan
debugContext.debugData.requestUri: /idp/idx/challenge/answer
target{}.displayName: nan
target{}.type: nan
published: 2024-06-06T16:46:03.678Z
displayMessage: User update password for Okta
extracted_eventType: user.account.update_password
legacyEventType: core.user.config.password_update.success
debugContext.debugData.requestUri: /idp/idx/challenge/answer
target{}.displayName: Test User
target{}.type: User
published: 2024-06-06T16:46:03.736Z
displayMessage: Activate factor for user
extracted_eventType: user.mfa.factor.activate
legacyEventType: core.user.factor.activate
debugContext.debugData.requestUri: /idp/idx/challenge/answer
target{}.displayName: Test User
target{}.type: User
published: 2024-06-06T16:46:03.804Z
displayMessage: User login to Okta
extracted_eventType: user.session.start
legacyEventType: core.user_auth.login_success
debugContext.debugData.requestUri: /idp/idx/challenge/answer
target{}.displayName: Password, Okta Dashboard
target{}.type: AuthenticatorEnrollment. AppInstance
published: 2024-06-06T16:46:04.340Z
displayMessage: Push user's Okta password to application
extracted_eventType: application.provision.user.push_okta_password
legacyEventType: app.user_management.push_okta_password_update
debugContext.debugData.requestUri: nan
target{}.displayName: Test User, Test User, SCIM 2.0 Test App (Basic Auth)
target{}.type: AppUser, User, AppInstance
published: 2024-06-06T16:46:05.977Z
displayMessage: User accessing Okta admin app
extracted_eventType: user.session.access_admin_app
legacyEventType: app.admin.sso.login.success
debugContext.debugData.requestUri: /admin/sso/callback
target{}.displayName: Test User
target{}.type: AppUser
From this we can see the entire flow from requesting the reset, to changing the password, to the new password being updated in applications, and finally, if the account was an admin, we can see them accessing the Okta admin app.
There is another related attack that an attacker may perform: changing a security question. This allows them to potentially get around the security protections on some account actions. For more information about these attacks and additional logs see:
Okta — Change Security Question
Okta — Reset Password
For detections see our Okta Collection.
Geolocation Data
For each system log there will also be client and requests objects that will contain the geographical information about where the request came from. This can be useful for tracking if an account was accessed outside a typical location.
request:
ipChain:
- ip: 25.137.37.189
geographicalContext:
city: Baltimore
state: Maryland
country: United States
postalCode: 21201
geolocation:
lat: 39.1740
lon: -76.36
version: V4
source: null
Conclusion
In conclusion, Okta provides a robust identity and access management (IAM) platform that enhances security and simplifies IT management through features like single sign-on (SSO), multi-factor authentication (MFA), and comprehensive lifecycle management. The Okta System Log is a critical tool for tracking and auditing all activities within the Okta environment, offering real-time visibility into user behaviors and system operations.
This blog has detailed various attacks against Okta and how they can be identified in Splunk, utilizing the Dorothy tool to simulate these attacks. Key attack vectors include modifying or deactivating policies, changing network zone states, resetting MFA factors, creating or modifying users and groups, and resetting passwords. Each of these actions leaves a trail in the Okta System Log, which can be monitored to detect and respond to potential security threats.
By understanding the logs generated by these actions and implementing effective monitoring and detection strategies, organizations can strengthen their security posture and mitigate the risks associated with unauthorized access and other malicious activities.
For further insights, additional attacks, full logs, and premade detections, check out the Okta Collection on SnapAttack.
SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other community detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!
Demystifying Okta Attacks with Dorothy and Splunk was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from SnapAttack - Medium authored by Trenton Tait. Read the original post at: https://blog.snapattack.com/demystifying-okta-attacks-with-dorothy-and-splunk-7800f75d27bc?source=rss----3bac186d1947---4
