Investigating Suspicious Events in Okta: Security Tips

Okta, like other identity providers, enables secure user authentication across applications. When unnatural or potentially malicious events are detected by Okta, they are recorded as suspicious events.

In this guide, we'll walk through the basics of suspicious events in Okta, what they mean, and how your security team can respond.

Understanding Okta Suspicious Events

Suspicious events are activities that Okta has defined as being unusual or unfamiliar, suggesting a higher risk of malicious or unauthorized access to an account. 

This could include log-in attempts from new locations, an unusual number of failed log-in attempts from the same IP address, or multiple authentication failures.

There are some common examples of types of suspicious events that Okta flags:

• "Sign-in Failed" – This indicates a high number of consecutive failed log-in attempts. Such attempts indicate that someone has tried to access an account with incorrect credentials.

• "Account Locked - Max sign-in attempts exceeded" – This is triggered when the maximum allowed number of failed sign-in attempts is exceeded in a certain period from the same IP address.

• “Unable to validate SAML Response" – When an SAML response is sent back to Okta, Okta will check it for validity. If there are discrepancies, such as an invalid signature or time stamp, the request will be considered suspicious.

• “A bypass of MFA may have been attempted for this user" – This occurs when a user attempts to bypass multi-factor authentication (MFA), such as by repeatedly entering the same verification code or using multiple devices to access the same account.

• “OAuth2 token revocation request rejected for client" – This is triggered when the token revocation request initiated by an OAuth2 client, such as a mobile application, is rejected.

• “Multiple requests with a client id about to be rate limited" – This happens when an application makes multiple requests within a short amount of time with the same client ID. This could indicate an unauthorized user is attempting to gain access, or it could be a malfunction of the application.

All of these events are labeled as suspicious automatically in Okta, and you can see a more comprehensive list here.

If you have configured your Okta settings to Enable Suspicious Reporting, then you can also have end-users mark whether an activity they are notified about is suspicious. 

This reporting would apply to these select types of events:

• Notification for New Sign-On
• New Authenticator Enrolled
• Authenticator Reset
• Changed Password

Regardless of whether a suspicious event was flagged by Okta automatically or reported by an end-user, it’s important to take the next step of investigating what happened and taking the appropriate actions.

How to Respond to Suspicious Events from Okta

When admins log in to the Okta console, they will be able to view all suspicious events and review the System Logs to investigate further. Admins can also adjust their notification settings to receive emails when each suspicious event arises.

For any event that wasn’t manually reported, the next step for the admin is to reach out to the end user to confirm if the activity associated with their account was really them. 

Since that requires drafting a message with the right context and sending a message, it can be time-consuming to respond to all suspicious events.

What if the owner of the Okta account confirms that the suspicious event wasn’t their activity? You should have a standard process for boosting the security for their account, like resetting their password or fetching additional information. The faster you can execute these mitigation steps, the better positioned you are against could have a major impact on the risk of attack damage.

Without automations in place to streamline this response process, investigating and mitigating each suspicious event is a continual challenge.

Confirming Suspicious Events Automatically With Blink

With Blink, you can run this automation to streamline reaching out to the individual, sharing the context, and acting upon their response.

When you run this automation, it executes the following steps:

1. Drafts a Slack notification for the suspicious event.
2. Sends a slack message to ask the user to confirm if they performed the suspicious action.
3. If the user denies responsibility, it will automatically reset the user’s password and send a notification to a designated Slack channel.

By having this in place, your security systems can respond faster to suspicious events and reduce your risk from attacks.

You can also reduce alert fatigue for your team by having automation handle these standard follow-ups. This ensures that you are able to focus on the most pressing issues.

There are over 5K automations in the Blink library just like this one that you can use to turn best practices into routine automated processes, or you can simply create custom automations to fit your unique needs.

Get started with Blink today to see how easy automation can be.