Okta AiTM Session Cookie Replay

Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/01/26"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when
 11an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial
 12authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them
 13from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy
 14evaluations or SSO attempts that occur from different IPs or programmatic user agents.
 15"""
 16false_positives = [
 17    """
 18    Users legitimately switching networks (e.g., VPN connect/disconnect, office to home) may trigger IP-based detection.
 19    Review the geographic distance and time between IP changes to assess legitimacy.
 20    """,
 21    """
 22    Automated integrations or scripts using service accounts with session cookies may trigger user-agent based
 23    detection. Consider excluding known automation accounts by okta.actor.alternate_id.
 24    """,
 25    """
 26    Mobile users switching between WiFi and cellular may show IP address changes. Correlate with device type and typical
 27    user behavior patterns.
 28    """,
 29]
 30from = "now-30m"
 31language = "esql"
 32license = "Elastic License v2"
 33name = "Okta AiTM Session Cookie Replay"
 34note = """## Triage and analysis
 35
 36### Investigating Okta AiTM Session Cookie Replay
 37
 38Adversary-in-the-Middle (AiTM) attacks use reverse proxies to intercept authentication flows, capturing session cookies after victims complete MFA. Attackers then replay these cookies from their own infrastructure to hijack authenticated sessions. This rule detects the post-capture phase by identifying sessions used from anomalous contexts.
 39
 40This is an ES|QL aggregation-based rule. Pivot into raw events using the root session ID for full investigation context.
 41
 42### Possible investigation steps
 43
 44- Review the collected IP addresses from the alert to identify all IPs that accessed this session. Investigate geographic locations and ASN ownership for each IP.
 45- Examine the user agent values for non-browser user agents like `python-requests`, `curl`, or `Headless` browsers that indicate programmatic access.
 46- Check Okta's risk assessment fields. HIGH risk with reasons like "Anomalous Device" or "Anomalous Location" strengthens AiTM suspicion.
 47- Correlate the session start timestamp with the first replay attempt timestamp to understand the attack timeline.
 48- Query raw Okta events for the session ID to see all activity within this session, including accessed applications.
 49- Review proxy detection fields to determine if attacker requests originated from VPN/proxy infrastructure.
 50- Check the user's recent password reset or MFA enrollment events, as these may indicate account compromise leading to the AiTM attack.
 51- Contact the user to verify if they received phishing emails with links to suspicious login pages around the session start time.
 52
 53### False positive analysis
 54
 55- Legitimate VPN usage may cause IP address changes within a session. Check if both IPs belong to known corporate VPN ranges or the user's typical locations.
 56- Users traveling may show geographic IP changes. Correlate with travel schedules or expense reports if available.
 57- Browser extensions or security tools may modify user agents. Verify the user agent patterns match known tools in the environment.
 58- API integrations using user context may trigger non-browser UA detection. Exclude known service accounts.
 59
 60### Response and remediation
 61
 62- Immediately terminate all active sessions for the affected user via Okta Admin Console.
 63- Reset the user's password and require MFA re-enrollment to invalidate any captured credentials.
 64- Review and revoke any OAuth tokens or API keys associated with the user.
 65- Check Okta System Log for applications accessed during the suspicious session and assess data exposure.
 66- If downstream applications were accessed, coordinate with application owners to review access logs and potential data exfiltration.
 67- Block the attacker IP addresses at the network perimeter and add to threat intelligence feeds.
 68- Implement Okta sign-on policies that challenge or block sessions with HIGH risk scores or proxy detection.
 69- Consider enabling Okta ThreatInsight to automatically block known malicious IPs.
 70- Review email security logs for phishing attempts targeting the user around the session start time.
 71- Escalate to incident response if sensitive applications (AWS, Salesforce, email) were accessed from the attacker IP.
 72"""
 73references = [
 74    "https://www.bleepingcomputer.com/news/security/okta-sso-accounts-targeted-in-vishing-based-data-theft-attacks/",
 75    "https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration/",
 76    "https://securitylabs.datadoghq.com/articles/investigating-an-aitm-phishing-campaign-m365-okta/)",
 77    "https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/",
 78    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
 79    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
 80]
 81risk_score = 73
 82rule_id = "9ed5d08f-aad6-4c03-838c-d686da887c2c"
 83severity = "high"
 84tags = [
 85    "Domain: Identity",
 86    "Use Case: Identity and Access Audit",
 87    "Data Source: Okta",
 88    "Data Source: Okta System Logs",
 89    "Tactic: Credential Access",
 90    "Tactic: Lateral Movement",
 91    "Resources: Investigation Guide",
 92    "Noise: Low",
 93    "Performance: Normal",
 94    "Profile: Recommended",
 95    "Threat: AiTM Phishing",
 96    "Rule Type: ES|QL",
 97    "Platform: Okta",
 98]
 99timestamp_override = "event.ingested"
100type = "esql"
101
102query = '''
103FROM logs-okta.system-*
104
105// Filter to relevant event types for AiTM detection
106| WHERE
107    okta.event_type IN ("user.session.start", "policy.evaluate_sign_on", "user.authentication.sso") AND
108    okta.authentication_context.root_session_id IS NOT NULL AND
109    okta.actor.alternate_id != "system@okta.com"
110
111// Create event type flags
112| EVAL Esql.is_session_start = okta.event_type == "user.session.start"
113| EVAL Esql.is_policy_eval = okta.event_type == "policy.evaluate_sign_on"
114| EVAL Esql.is_sso = okta.event_type == "user.authentication.sso"
115| EVAL Esql.is_replay_event = Esql.is_policy_eval OR Esql.is_sso
116
117// Flag suspicious non-browser user agents
118| EVAL Esql.is_suspicious_ua =
119    user_agent.original LIKE "python-requests*" OR
120    user_agent.original LIKE "curl/*" OR
121    user_agent.original LIKE "httpx*" OR
122    user_agent.original LIKE "aiohttp*" OR
123    user_agent.original LIKE "Go-http-client*" OR
124    user_agent.original LIKE "*Headless*" OR
125    user_agent.original LIKE "Java/*" OR
126    user_agent.original LIKE "okhttp*"
127
128// Aggregate by session
129| STATS
130    Esql.session_start_count = SUM(CASE(Esql.is_session_start, 1, 0)),
131    Esql.replay_event_count = SUM(CASE(Esql.is_replay_event, 1, 0)),
132    Esql.session_start_time = MIN(CASE(Esql.is_session_start, @timestamp, null)),
133    Esql.first_replay_time = MIN(CASE(Esql.is_replay_event, @timestamp, null)),
134    Esql.last_replay_time = MAX(CASE(Esql.is_replay_event, @timestamp, null)),
135    Esql.session_start_ip = MAX(CASE(Esql.is_session_start, okta.client.ip, null)),
136    Esql.session_start_ua = MAX(CASE(Esql.is_session_start, user_agent.original, null)),
137    Esql.suspicious_ua_count = SUM(CASE(Esql.is_suspicious_ua, 1, 0)),
138    Esql.okta_client_ip_count_distinct = COUNT_DISTINCT(okta.client.ip),
139    Esql.user_agent_count_distinct = COUNT_DISTINCT(user_agent.original),
140    Esql.okta_client_ip_values = VALUES(okta.client.ip),
141    Esql.user_agent_values = VALUES(user_agent.original),
142    Esql.okta_event_type_values = VALUES(okta.event_type),
143    Esql.okta_outcome_result_values = VALUES(okta.outcome.result),
144    Esql.source_geo_country_name_values = VALUES(source.geo.country_name),
145    Esql.source_geo_city_name_values = VALUES(source.geo.city_name),
146    Esql.okta_debug_context_debug_data_risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
147    Esql.okta_debug_context_debug_data_risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
148  BY okta.authentication_context.root_session_id, okta.actor.alternate_id
149
150// Detection conditions
151| WHERE
152    Esql.session_start_count >= 1
153    AND Esql.replay_event_count >= 1
154    AND Esql.first_replay_time > Esql.session_start_time
155    AND (
156            (
157                Esql.okta_client_ip_count_distinct > 1 OR Esql.user_agent_count_distinct > 1
158            ) AND Esql.suspicious_ua_count > 0
159        )
160
161| SORT Esql.session_start_time DESC
162| KEEP Esql.*, okta.authentication_context.root_session_id, okta.actor.alternate_id
163'''
164
165
166[[rule.threat]]
167framework = "MITRE ATT&CK"
168
169[[rule.threat.technique]]
170id = "T1539"
171name = "Steal Web Session Cookie"
172reference = "https://attack.mitre.org/techniques/T1539/"
173
174[rule.threat.tactic]
175id = "TA0006"
176name = "Credential Access"
177reference = "https://attack.mitre.org/tactics/TA0006/"
178
179[[rule.threat]]
180framework = "MITRE ATT&CK"
181
182[[rule.threat.technique]]
183id = "T1550"
184name = "Use Alternate Authentication Material"
185reference = "https://attack.mitre.org/techniques/T1550/"
186
187[[rule.threat.technique.subtechnique]]
188id = "T1550.004"
189name = "Web Session Cookie"
190reference = "https://attack.mitre.org/techniques/T1550/004/"
191
192[rule.threat.tactic]
193id = "TA0005"
194name = "Defense Evasion"
195reference = "https://attack.mitre.org/tactics/TA0005/"

Triage and analysis

Adversary-in-the-Middle (AiTM) attacks use reverse proxies to intercept authentication flows, capturing session cookies after victims complete MFA. Attackers then replay these cookies from their own infrastructure to hijack authenticated sessions. This rule detects the post-capture phase by identifying sessions used from anomalous contexts.

This is an ES|QL aggregation-based rule. Pivot into raw events using the root session ID for full investigation context.

Possible investigation steps

  • Review the collected IP addresses from the alert to identify all IPs that accessed this session. Investigate geographic locations and ASN ownership for each IP.
  • Examine the user agent values for non-browser user agents like python-requests, curl, or Headless browsers that indicate programmatic access.
  • Check Okta's risk assessment fields. HIGH risk with reasons like "Anomalous Device" or "Anomalous Location" strengthens AiTM suspicion.
  • Correlate the session start timestamp with the first replay attempt timestamp to understand the attack timeline.
  • Query raw Okta events for the session ID to see all activity within this session, including accessed applications.
  • Review proxy detection fields to determine if attacker requests originated from VPN/proxy infrastructure.
  • Check the user's recent password reset or MFA enrollment events, as these may indicate account compromise leading to the AiTM attack.
  • Contact the user to verify if they received phishing emails with links to suspicious login pages around the session start time.

False positive analysis

  • Legitimate VPN usage may cause IP address changes within a session. Check if both IPs belong to known corporate VPN ranges or the user's typical locations.
  • Users traveling may show geographic IP changes. Correlate with travel schedules or expense reports if available.
  • Browser extensions or security tools may modify user agents. Verify the user agent patterns match known tools in the environment.
  • API integrations using user context may trigger non-browser UA detection. Exclude known service accounts.

Response and remediation

  • Immediately terminate all active sessions for the affected user via Okta Admin Console.
  • Reset the user's password and require MFA re-enrollment to invalidate any captured credentials.
  • Review and revoke any OAuth tokens or API keys associated with the user.
  • Check Okta System Log for applications accessed during the suspicious session and assess data exposure.
  • If downstream applications were accessed, coordinate with application owners to review access logs and potential data exfiltration.
  • Block the attacker IP addresses at the network perimeter and add to threat intelligence feeds.
  • Implement Okta sign-on policies that challenge or block sessions with HIGH risk scores or proxy detection.
  • Consider enabling Okta ThreatInsight to automatically block known malicious IPs.
  • Review email security logs for phishing attempts targeting the user around the session start time.
  • Escalate to incident response if sensitive applications (AWS, Salesforce, email) were accessed from the attacker IP.

References

Related rules

to-top