Investigating Okta Alerts - A Step-by-Step Guide

The beginning of a security incident and subsequent response is set in motion when an alert hits the queue for triage. One of the most notoriously difficult alerts to triage are “Suspicious Logon” style alerts. Part of the problem with these types of alerts is that it’s really challenging to have ironclad context that early in the attacker lifecycle. Is someone on a family vacation or did a threat actor compromise this user’s account and login from an unusual country? These are the investigations that can quickly chew away a day without an efficient process.

In this blog, we’ll break down our investigative approach to the “Suspicious Logon” alert below. We will also provide an estimated duration for each step of the investigation.

Security Vendor: Okta
Timestamp: Today
Description: A user logged in from a new IP address
Username: alice@prophet.security
Logon Status: SUCCESS

Throughout this blog, we’ll be relying on the overarching investigative questions we outlined in our recent SOC best practices post.

1. Did the user log on with multi-factor authentication? (2 - 5 minutes)

It might initially seem counterintuitive to prioritize verifying multi-factor authentication (MFA) from Okta when their primary purpose is multi-factor verification. However, confirming whether the MFA method used was valid will significantly limit the scope of your investigation to confidently close as benign activity. Unusual travel is irrelevant if you can validate the user is who they say they are. 

Here’s how we break down this question:

1. Check the authentication event for evidence that multi-factor was used. With Okta policies, you can bypass requiring MFA for specific users. This increases security gaps while giving a false sense of security for the investigator who implicitly may think every Okta event involves MFA. For Okta, you can verify whether MFA was used in the “user.session.start” event with the Okta System Log which signals a successful sign-on. Specifically, look in the target.DisplayName block; here you’ll see items like “Okta Verify”, “Google Authenticator”, “SMS Authentication”, which confirms the use of MFA. In the event you don’t see an authenticator event, check the conditional access policies that apply to this user and make sure there isn’t a bypass allowed.
2. Check for new multifactor methods. If this logon was a successful authentication, look-up the devices associated with the user in Okta and see if a newly added method was used. If the method has been in use for a while, the two primary potentials for compromise are token reuse and MFA fatigue.
3. Check for token theft and reuse. Use the “externalSessionID” within the Okta alert to search for all relevant activity that occurred in a session. Look for any changes in Source IP or User device during the session – particularly if it’s a different country or device that’s being used mid-session. This is generally unlikely to occur.
4. Check for MFA fatigue. Look for recent failed logins from the user over the last 4 hours. Are they multiple failed logon events preceding this one that may indicate MFA spamming?

Pro tip: Understanding whether MFA was used should immediately dispel any concerns about a user who used valid multifactor authentication, without the need to examine their baseline activity.

2. What’s the reputation of the source IP address? (2 minutes)

Generally, you’re expecting malicious activity to originate from an unusual location or IP block that differs from standard behavior. While a VirusTotal lookup may help provide some quick answers on threat reputation, go a bit deeper into the infrastructure metadata.

1. Is this Source IP address coming from a Virtual Private Server (VPS) provider? These infrastructure services are notoriously used by threat actors given their ease of use and anonymity. 
2. Are there any recent domain registrations associated with this IP address? Newly registered domains aren’t as common as you might think and often line up with attacker infrastructure.
3. Is this a VPN provider, Proxy, or Tor node that the user doesn’t frequently use? Any of these three will likely trigger a policy violation and could give you an indication that something more suspicious is happening.

Pro tip: Residential IP addresses are much more rare and operationally expensive for threat actors to use in their operations, so while anything related to residential or business telecom providers may not entirely assuage your suspicions, it should certainly lower your creep score.

3. Does the user’s logon activity follow their standard behavior? (5 - 10 minutes)

This is generally the part of the investigation that can bog an investigator down because it requires historical lookups to understand how this logon compares to their baseline. For small teams managing high volumes of these alerts, I’d advise building a SIEM dashboard or similar to retrieve and display some of the key information.

1. Is the user logging in from a device with an Endpoint Detection and Response (EDR) agent? If you have a tool like CrowdStrike Falcon or SentinelOne, a quick win is to check if the source IP lines up with one (or many) endpoint agents in your environment. An EDR agent without any related alerts is a good indication of normal activity. Multiple EDR agents might also explain a new IP address as a co-working location or office space and resolve the activity.
    
2. How often does this user log on from a particular IP address? Look back at your Okta logs (30 days minimum) and see if there’s previous evidence of successful logins from this IP address. Longer history should generally increase your trust. If possible, group source IP addresses by Organization or ASN to increase your fidelity from residential IP changes.
   
   
3. How often does this user authenticate with a particular user-agent string? Look back at historical Okta logs (30 days minimum) and identify if the user is logging in from a consistent browser and device, or if there’s variation. While user agent strings are readily changeable, mobile device user agents generally drop your suspicions, especially from a telecom network. Deviations in browser and OS with low frequency usage would be of interest.

4. What actions occurred during the session? (5 - 10 minutes)

If the activity doesn’t line up with the baseline, consider reaching out to the user for validation while digging into this question. You’ll want to use Okta’s External Session ID to retrieve and evaluate all the events within this particular session.

1. Was there any evidence of attempted persistence creation? Were new users created, MFA methods added to multiple users, or passwords changed for infrequently used accounts? If the investigation has revealed suspicious findings up until now, these elements would be of interest.
2. Did the user attempt to access applications with sensitive data access or that are infrequently used? Cloud infrastructure providers, code repositories, and company documentation stores are common places threat actors look for data. Keep an eye out for suspicious use (or failed logins) for these resources during a suspicious session.

5. Is the activity ongoing? (10 minutes+)

At this point you should have a strong bearing on the initial login, the user’s typical activity, and what occurred during the session. You should also have contacted the user and possibly revoked a session or reset credentials as a preventative measure. Gather IDP logging after the alert is triggered and look for the same source IP and user tuple and any follow-on sessions that may have been created. Repeat the process in question #4 and evaluate activities related to data access and persistence.

Wrapping up

Remember, early stage indications of compromise, such as an identity alert from Okta, are difficult to triage and challenging to detect. The above investigative steps will take anywhere from 25 minutes to 1 hour to complete. While they generally don’t provide the investigator the biggest bang for your buck in terms of efficacy, being able to respond to them quickly and identify quick false positives (or true positives) can save you hours of combing through authentication logs. 

If you’re reading this investigation and thinking “that sounds like the world’s worst SOAR playbook to build” or “that’s a lot of investigating” – you’re right! At Prophet Security, we’ve built a tool to dynamically perform these types of investigations on your behalf without ever drag-and-dropping a square or writing a line of code. Request a demo of Prophet AI to learn how you can triage and investigate security alerts (including Okta alerts) 10 times faster.

Further reading

• SOC metrics that matter
• What is MFA fatigue attack?
• Investigating geo-impossible travel alert
• Top 3 scenarios for auto remediation
• Automated incident response: streamlining your SecOps
• Key SOC tools every security operations needs
• Demystifying SOC automation
• Alert triage and investigation in cybersecurity: best practices
• SOC challenges for analysts and managers
• Alert tuning best practices: keys to reducing false positives
• AI SOC: Key to solving persistent challenges
• AI SOC Analyst: A comprehensive guide
• Will AI replace cybersecurity jobs?
• How to investigate AWS GuardDuty Finding