--- title: "Okta evolving situation: am i impacted?" page_name: "Okta evolving situation: Am I impacted?" type: "blog" slug: "okta-evolving-situation-am-i-impacted" published_at: "2023-11-02" modified_at: "2025-06-17" url: "https://www.sumologic.com/blog/okta-evolving-situation-am-i-impacted" canonical: "https://www.sumologic.com/blog/okta-evolving-situation-am-i-impacted" markdown_url: "https://www.sumologic.com/blog/okta-evolving-situation-am-i-impacted.md" lang: "en" excerpt: "You need a proactive approach to secure your environment with a defense-in-depth strategy and appropriate monitoring, especially in light of recent attacks and breaches. Learn about the latest Okta breach and how Sumo Logic can help you improve your security posture." taxonomy_blog_category: - "SecOps & Security" --- [ All blogs ](https://www.sumologic.com/blog "blog")[SecOps & Security](https://www.sumologic.com/blog/secops-security) # Okta evolving situation: Am I impacted? [George Gerchow](#blog-author-block-133) November 2, 2023 8 min read [SecOps & Security](https://www.sumologic.com/blog/secops-security) ##### Table of contents Cybersecurity is never boring. In recent months, we’ve seen major [cyberattacks on Las Vegas casinos](https://www.sumologic.com/blog/cyber-attackers-jackpot-vulnerabilities/) and [expanded SEC cybersecurity disclosure rules](https://www.sumologic.com/blog/sec-cybersecurity-disclosure-rules/) are top of mind. Is it any wonder we consistently recommend taking a proactive approach to secure your environment with a defense-in-depth strategy and appropriate monitoring? News outlets [reported](https://www.cybersecuritydive.com/news/okta-customer-support-system-cyberattack) the recent compromise at the Identity and Authentication (IAM) firm, Okta. Okta Security discovered unauthorized activity in which a threat actor accessed Okta’s support case management system using a stolen credential. This breach allowed the intruder to view files that specific Okta customers uploaded as part of their recent support cases. Our Global Operations Center investigated Okta’s evolving situation and so far we have no evidence that Sumo Logic, our employees or services are impacted in any way. Okta emphasizes [in their blog](https://sec.okta.com/harfiles) the significance of being alert and monitoring for dubious activities. To aid this, a list of Indicators of Compromise is provided, primarily IP addresses, many of which are linked to commercial VPNs. Additionally, they highlight two older user agents, though legitimate, as they might be uncommon due to the release of a newer Chrome version in March 2022. ### Sumo Logic customers If you are a Sumo Logic customer or if you are trialing Sumo Logic services, we can help you determine if you are at risk. You can use the [Okta App for Sumo Logic](https://www.sumologic.com/application/okta/) to get started with securing your environment by using the Okta logs to determine this potential compromise and much more, including: - Identify top 10 user account lockouts in the last 24 hours - Correlate user account lockout with a successful login - Identify abnormal user activities - Perform geo-velocity analysis - Detect successful and failed logins - Monitor admin activities - Identify accounts with MFA disabled Some examples are below: - Account granted SSO Administrator privileges - External support access to SSO environment - Password or MFA reset activity by unexpected accounts ## Example attack paths Below, we’ll attempt to walk through some of the attack paths an attacker might take to attack your organization via SSO. Remember that the below searches are best used for general SSO security monitoring, investigations or feeding an entity risk score for risk aggregation, like Cloud SIEM. The searches we provide throughout the blog are based on Okta logs but can be easily updated for use against any SSO provider log. ### Supply chain An attacker that manages to compromise any SSO provider directly and subsequently uses that to access or manipulate customer environments would fall under a supply chain attack. Defenders should monitor for unusual or unexpected access from the SSO provider. #### Unexpected SSO provider service access In the example below, we’ll use the Sumo Logic SaaS Log Analytics Platform to search for any activity from Okta accounts that should be further investigated. _sourceCategory=*okta* @okta.com | json field=_raw “eventType” | json field=_raw “displayMessage” | json field=_raw “outcome.result” as outcome | json field=_raw “actor.type” | json field=_raw “actor.alternateId” as act_id | json field=_raw “actor.displayName” | json field=_raw “target[0].alternateId” as target_id | json field=_raw “target[0].displayName” as target_Name | where act_id != “system@okta.com” | count eventType,displayMessage,outcome,act_id,target_id The next search (which we would advise be set up to generate an alert when seen) indicates that a **session impersonation event** has occurred. This should only occur if Okta administrative access has been requested by an organization. _sourceCategory=*okta* “user.session.impersonation.initiate” | json field=_raw “actor.alternateId” as user | json field=_raw “outcome.result” as result | json field=_raw “outcome.reason” as outcome | json field=_raw “eventType” as event | json field=_raw “client.userAgent.rawUserAgent” as user_agent | json field=_raw “client.userAgent.os” as os | json field=_raw “client.ipAddress” as srcIP #### Anomalous password resets An attacker might also reset user passwords or reset MFA. Looking for instances where unusual accounts are resetting passwords or MFA might warrant further analysis. _sourceCategory=*okta* “user.account.reset_password” OR “user.mfa.factor.deactivate” OR “user.mfa.factor.reset_all” | json field=_raw “eventType” | json field=_raw “published” as time | json field=_raw “displayMessage” | json field=_raw “outcome.result” as outcome | json field=_raw “actor.type” | json field=_raw “actor.alternateId” as act_id | json field=_raw “actor.displayName” | json field=_raw “target[0].alternateId” as target_id | json field=_raw “target[0].displayName” as target_Name | where act_id != target_id //| where !(act_id matches “<expected user>” OR act_id matches “*expected user>*”) | count time,eventType,displayMessage,outcome,act_id,target_id ### Credential theft The attacks you are most likely to see are attacks against employee credentials, typically in the form of phishing, password spray attacks and MFA fatigue attacks. #### Password spray attacks Password spray attacks can take many forms—and security teams should keep an eye for the signs of an ongoing password spray attack. #### General awareness – deviations in failed logins It’s not a bad idea to keep an eye on spikes or baseline deviations in failed logins to your SSO provider. Establish a baseline of unique accounts with failed logins to your SSO and look for outliers. This may help identify low and slow password spray attacks and provides a decent 10,000-foot view of attacks or probes against your SSO. #### High volume password spray One of our favorite ways to identify active password spray attacks is to look for a spike in SSO failed logins sourcing from the same ASN. Attackers can change the source of their password spray easily, so building your search around a source IP is too narrow. We’ve found grouping by the source ASN and putting a 30 or 60-minute time window around it is the sweet spot. _sourceCategory=<SSO SOURCE> (failure AND “user.session.start”) | json field=_raw “actor.alternateId” as user | json field=_raw “eventType” as event | json field=_raw “client.userAgent.rawUserAgent” as user_agent | json field=_raw “client.userAgent.os” as os | json field=_raw “client.ipAddress” as srcIP | timeslice 30m | lookup asn, organization from asn://default on ip=srcIP | lookup country_name from geo://location on ip=srcIP | values(user) as users,values(user_agent) as UA, count_distinct(user) as dist_users by organization,ASN,_timeslice,users,UA,country_name | where dist_users > 10 Another way to look at authentication failures: _source=”SSO Source” “failure” !(“radius”) | json field=_raw “request.ipChain[0].ip” as request_ip nodrop | json field=_raw “request.ipChain[0].geographicalContext.country” as request_country nodrop | json field=_raw “request.ipChain[0].geographicalContext.state” as request_state nodrop | json field=_raw “target[0].type” as target_0_type nodrop | json field=_raw “target[*].alternateId” as target_altid nodrop | json field=_raw “target[0].alternateId” as target0_altid nodrop | json field=_raw “target[1].alternateId” as target1_altid nodrop | json field=_raw “actor.alternateId” nodrop | json field=_raw “client.ipAddress” nodrop | json field=_raw “outcome.result” as result nodrop | json field=_raw “securityContext.asNumber” as asn nodrop | json field=_raw “securityContext.asOrg” as asn_org nodrop | json field=_raw “securityContext.isp” as isp nodrop | json field=_raw “client.userAgent.rawUserAgent” as user_agent nodrop //| where !(asn_org matches “*[Your Organizations ASN]*” ) | timeslice 30m | values(target_altid) as users,values(asn_org) as asn_org,values(request_country) as country,count_distinct(target_altid) as target_count, count group by request_ip,user_agent,_timeslice | where target_count > 10 Expanding the search to look for spikes in failed logins over a short time window (10 minutes) can also prove useful but can sometimes generate false positives. Think Monday morning when everyone is first logging in or after a holiday break and no one can remember their password. #### MFA push notification fatigue Adding an additional layer of security on top of SSO is recommended, and the most common method for doing this is in the form of push notifications. Once valid credentials have been provided to the SSO platform, an MFA push notification will be sent to a pre-enrolled device that requires accepting or acknowledging the attempt to complete the login process. Once an attacker has a username and password, they can attempt to initiate a logon with the hope that the victim unknowingly or unintentionally acknowledges the push notification. Believe us when we tell you that this happens more often than you think! To increase their chance of success, attackers will flood or spam victims with push notifications. Okta published a great [blog](https://sec.okta.com/everythingisyes) on this attack technique in early March 2022. We’ve adapted their detection for use in Sumo’s CIP: _source=<SSO LOG SOURCE> (user.authentication.auth_via_mfa or OKTA_VERIFY_PUSH) | json field=_raw “outcome.result” as result | json field=_raw “actor.alternateId” as user | timeslice 10m | if(result=”SUCCESS”,1,0) as success| if(result=”FAILURE”,1,0) as failure | count as total_pushes,sum(success) as success, sum(failure) as failure by user,_timeslice | failure/total_pushes as push_fail_ratio | “No Finding” as finding | if(failure=total_pushes AND total_pushes>1,”Authentication attempts not successful because multiple pushes denied”,finding) as finding | if(total_pushes=0,”Multiple pushes sent and ignored”,finding) as finding | if(success>0 AND total_pushes>3,”Multiple pushes sent, eventual successful authentication!”,finding) as finding | if(push_fail_ratio>.1,”High push fail Ratio with successful login detected”,finding) as finding | where finding = “High push fail Ratio with successful login detected” and total_pushes > 1 This search will identify instances where an account has been observed with a high number of push notifications sent with multiple failures with at least one successful login. #### Post SSO compromise activity Once an attacker steals credentials and successfully gets a victim to accept a push notification, they have some form of access to the organization and its data. We’ve observed attackers performing a variety of actions following initial access, which we will discuss below. Please note that any results that may return from the below searches do not indicate a compromise has occurred and should be considered in aggregate with other events of interest associated with the account in question. #### Interesting MFA and password reset activity If an attacker has managed to compromise an SSO account, they might reset the account password and update and take control of the victim’s MFA. The below CIP search is also looking at Okta data and identifying any accounts that have had both an MFA update and password reset event within a specified time window. _source=<SSO LOG SOURCE> (user.account.reset_password or user.mfa.factor.update) | json field=_raw “eventType” as action | if(action matches”*reset_password*”,1,0) as reset_password | if(action matches”*user.mfa.factor.update*”,1,0) as user_mfa_factor_update | json field=_raw “actor.alternateId” as user | json field=_raw “target[*].alternateId” as target_user //identifies target, rather than system@okta.com | count, sum(user_mfa_factor_update) as user_mfa_factor_update, sum(reset_password) as reset_password by target_user | where user_mfa_factor_update>1 and reset_password>1 #### Unusual SSO app access One of the behaviors that we often observe following initial access is the attacker exploring all of the applications the compromised account has access to. A user may have access to dozens of published applications, but usually, only access a small number of those apps daily. The behavior of normal user application access looks very different than an attacker who has just gained access to a victim’s application portal SSO. Imagine the attacker drooling when they see SalesForce, GitHub, Confluence, Slack or PowerBI applications available for access! These applications are a goldmine and you can bet that an attacker will attempt to access as many of these applications as possible to discover what data they can steal. #### User application access deviation Let’s look for accounts that trigger a deviation for the number of distinct applications that are being accessed by an account. If a legitimate user normally accesses five apps a day, but we observe the account accessing 20 apps, that might be something worth noting. #### Unauthorized app access attempts An attacker that is engaging in discovery activity using compromised SSO credentials will likely attempt to access applications that the account does not have the authorization to access. These violations will often have an associated log event, which can be useful for defenders attempting to identify suspicious activity. We can use another CIP search to identify accounts that have attempted to access multiple applications that the account is not authorized to access. _sourceCategory=<SSO LOG SOURCE> (app.generic.unauth_app_access_attempt OR app.oauth2.as.authorize.scope_denied OR app.oauth2.client_id_rate_limit_warning OR app.oauth2.invalid_client_credentials OR app.oauth2.invalid_client_ids OR app.oauth2.token.detect_reuse) | json field=_raw “actor.alternateId” as user | json field=_raw “eventType” as event | json field=_raw “target[0].displayName” as appName | timeslice 3d | values(appName) as appNames, values(event) as event_type, count_distinct(appName) as unique_count by user,_timeslice,appNames,event_type | where unique_count >=2 ### Summary Sumo Logic Saas Log Analytics Platform makes easy work of slicing and dicing your SSO log data to identify potential signs of compromised credentials. Furthermore, Sumo Logic Cloud [SIEM](https://www.sumologic.com/solutions/cloud-siem) provides out-of-the-box security rules for normalized authentication log data and additional rules specific to SSO providers. Signals generated from these rules apply risk to entities, and Cloud SIEM automatically creates Insights if risk thresholds are exceeded. This provides customers with a powerful security solution they can easily adapt and custom tailor to their specific environment. The searches shared above can be used to create dashboards for daily review, trigger email alerts based on various parameters to notify your security team of activity of interest, or best of all, send an event to Sumo Logic Cloud SIEM to contribute to an entity risk model. Check out the [modern SIEM guide](https://www.sumologic.com/guides/siem/) to learn more or see our product in action with the [Cloud SIEM demo](https://www.sumologic.com/demos/). ### Article Tags - [SecOps & Security](https://www.sumologic.com/blog/secops-security) George Gerchow CSO and SVP of IT As Sumo Logic’s CSO and SVP of IT, George Gerchow brings over 20 years of information technology and systems management expertise to the application of IT processes and disciplines. George has been on the bleeding edge of public cloud security, privacy and modernizing IT systems since being a co-founder of the VMware Center for Policy & Compliance. He is a Faculty Member for [IANS](https://www.iansresearch.com/our-faculty/faculty/detail/%5Bf669d9a7-009d-4d83-ddaa-000000000002%5D2CFAB8BA-3C3D-440F-AC51-75AE8FD0D8A6) – [Institute of Applied Network Security ](https://www.iansresearch.com/our-faculty/faculty/detail/%5Bf669d9a7-009d-4d83-ddaa-000000000002%5D2CFAB8BA-3C3D-440F-AC51-75AE8FD0D8A6) and sits on several industry advisory boards. Mr. Gerchow is also a known philanthropist and CEO of a nonprofit corporation, [XFoundation](https://www.xfoundationx.org/). [](https://www.sumologic.com/feed "RSS Feed")[](https://twitter.com/intent/tweet?text=Okta%20evolving%20situation%3A%20Am%20I%20impacted%3F&url=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fokta-evolving-situation-am-i-impacted "X")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fokta-evolving-situation-am-i-impacted "Facebook")[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fokta-evolving-situation-am-i-impacted "Linkedin") [Previous blog Achieving observability in Heroku applications with Sumo Logic](https://www.sumologic.com/blog/achieving-observability-in-heroku-applications-with-sumo-logic)[Next blog How does your AWS environment stand up to the MITRE ATT&CK framework?](https://www.sumologic.com/blog/detecting-mitre-attck-stages-aws) People who read this also enjoyed [ AI across the security lifecycle June 18, 2026 ](https://www.sumologic.com/blog/ai-across-security-lifecycle)[ Balance AI innovation and governance with Sumo Logic AI and ML apps June 10, 2026 ](https://www.sumologic.com/blog/sumo-logic-ai-ml-apps-governance)[ Sumo Logic AWS Region European Sovereign Cloud is now generally available June 2, 2026 ](https://www.sumologic.com/blog/sumo-logic-aws-region-european-sovereign-cloud-generally-available)[ How digital banking is redefining fraud prevention May 28, 2026 ](https://www.sumologic.com/blog/digital-banking-redefining-fraud-prevention) [AI Instructions](https://www.sumologic.com/ai-instructions.md)