Okta Alerts Following Unusual Proxy Authentication
Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/02/20"
3integration = ["okta"]
4maturity = "production"
5updated_date = "2026/02/20"
6
7[rule]
8author = ["Elastic"]
9description = """
10Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the
11same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when
12using stolen credentials, and their post-authentication activity often triggers additional detection rules.
13"""
14false_positives = [
15 """
16 Legitimate users who routinely use VPN or proxy services for privacy may trigger this if they also trigger unrelated
17 security alerts.
18 """,
19 "Security testing or red team exercises using proxy infrastructure.",
20]
21from = "now-60m"
22index = [".alerts-security.*"]
23interval = "30m"
24language = "eql"
25license = "Elastic License v2"
26name = "Okta Alerts Following Unusual Proxy Authentication"
27note = """## Triage and analysis
28
29### Investigating Okta Alerts Following Unusual Proxy Authentication
30
31This rule correlates the first occurrences of authentication behind a proxy followed by an alert with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules.
32
33By correlating the proxy alert with other Okta alerts using an EQL sequence, this rule identifies users whose proxy-based authentication was followed by suspicious activity within a 1-hour window.
34
35#### Possible investigation steps
36- Identify the affected user and review the correlated security alerts to understand what suspicious activity was detected after the proxy authentication.
37- Examine the proxy source IP addresses and cross-reference with threat intelligence feeds for known malicious infrastructure.
38- Review the time gap between the proxy authentication and subsequent alert generation.
39- Review the user's recent Okta activity for signs of account takeover (MFA changes, new devices, unusual app access).
40- Verify with the user whether they intentionally used a proxy or VPN during this session.
41
42### False positive analysis
43- Users who legitimately use VPN services for privacy or remote work may trigger this rule if they also trigger unrelated alerts.
44- Security testing or red team exercises using proxy infrastructure combined with testing that triggers alerts.
45- Corporate VPN egress points that Okta classifies as proxy infrastructure.
46
47### Response and remediation
48- If account compromise is suspected, immediately revoke all active sessions for the user.
49- Reset the user's password and MFA factors.
50- Review and revoke any OAuth tokens or API keys associated with the account.
51- Block the source proxy IP at the network perimeter if confirmed malicious.
52- Review the user's access to sensitive applications and data during the suspicious session.
53"""
54references = [
55 "https://developer.okta.com/docs/reference/api/system-log/",
56 "https://developer.okta.com/docs/reference/api/event-types/",
57 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
58 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
59 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
60 "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
61]
62risk_score = 73
63rule_id = "af2d8e4c-3b7c-4e91-8f5a-6c9d0e1f2a3b"
64severity = "high"
65tags = [
66 "Domain: Identity",
67 "Domain: Cloud",
68 "Use Case: Identity and Access Audit",
69 "Use Case: Threat Detection",
70 "Data Source: Okta",
71 "Data Source: Okta System Logs",
72 "Tactic: Initial Access",
73 "Rule Type: Higher-Order Rule",
74 "Resources: Investigation Guide",
75]
76timestamp_override = "event.ingested"
77type = "eql"
78
79query = '''
80sequence by user.name with maxspan=30m
81 [any where event.dataset == "okta.system" and
82 kibana.alert.rule.rule_id == "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"]
83 [any where event.dataset == "okta.system" and
84 kibana.alert.rule.rule_id != null and
85 kibana.alert.severity != "low" and
86 kibana.alert.rule.rule_id not in (
87 "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd",
88 "af2d8e4c-3b7c-4e91-8f5a-6c9d0e1f2a3b"
89 )
90 ]
91'''
92
93
94[[rule.threat]]
95framework = "MITRE ATT&CK"
96[[rule.threat.technique]]
97id = "T1078"
98name = "Valid Accounts"
99reference = "https://attack.mitre.org/techniques/T1078/"
100[[rule.threat.technique.subtechnique]]
101id = "T1078.004"
102name = "Cloud Accounts"
103reference = "https://attack.mitre.org/techniques/T1078/004/"
104
105
106
107[rule.threat.tactic]
108id = "TA0001"
109name = "Initial Access"
110reference = "https://attack.mitre.org/tactics/TA0001/"
Triage and analysis
Investigating Okta Alerts Following Unusual Proxy Authentication
This rule correlates the first occurrences of authentication behind a proxy followed by an alert with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules.
By correlating the proxy alert with other Okta alerts using an EQL sequence, this rule identifies users whose proxy-based authentication was followed by suspicious activity within a 1-hour window.
Possible investigation steps
- Identify the affected user and review the correlated security alerts to understand what suspicious activity was detected after the proxy authentication.
- Examine the proxy source IP addresses and cross-reference with threat intelligence feeds for known malicious infrastructure.
- Review the time gap between the proxy authentication and subsequent alert generation.
- Review the user's recent Okta activity for signs of account takeover (MFA changes, new devices, unusual app access).
- Verify with the user whether they intentionally used a proxy or VPN during this session.
False positive analysis
- Users who legitimately use VPN services for privacy or remote work may trigger this rule if they also trigger unrelated alerts.
- Security testing or red team exercises using proxy infrastructure combined with testing that triggers alerts.
- Corporate VPN egress points that Okta classifies as proxy infrastructure.
Response and remediation
- If account compromise is suspected, immediately revoke all active sessions for the user.
- Reset the user's password and MFA factors.
- Review and revoke any OAuth tokens or API keys associated with the account.
- Block the source proxy IP at the network perimeter if confirmed malicious.
- Review the user's access to sensitive applications and data during the suspicious session.
References
-
The Okta System Log records system events that are related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems. The System Log API provides near real-time, read-only access to your organization's System Log and is the programmatic counterpart of the [System Log UI](https://help.okta.com/okta_help.htm?id=ext_Reports_SysLog). The terms "event" and "log event" are often used interchangeably. In the context of this API, an "event" is an occurrence of interest within the system, and a "log" or "log event" is the recorded fact. The System Log API supports these primary use cases: * Event data export into a security information and event management system (SIEM) * System monitoring * Development debugging * Event introspection and audit > **Note:** Some of the curl code examples on this page include SSWS API token authentication. However, Okta recommends using scoped OAuth 2.0 and OIDC access tokens to authenticate with Okta management APIs. OAuth 2.0 and OIDC access tokens provide fine-grain control over the bearer's actions on specific endpoints. See [Okta API authentication methods](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/). For further details and examples, see [System Log query](https://developer.okta.com/docs/reference/system-log-query/).
Read More -
-
Testing your Okta visibility and detection with Dorothy and Elastic Security — Elastic Security Labs
Dorothy is a tool for security teams to test their visibility and detection capabilities for their Okta environment. IAM solutions are frequently targeted by adversaries but poorly monitored. Learn how to get started with Dorothy in this post.
Read More -
This article guides readers through establishing an Okta threat detection lab, emphasizing the importance of securing SaaS platforms like Okta. It details creating a lab environment with the Elastic Stack, integrating SIEM solutions, and Okta.
Read More -
This article delves into Okta's architecture and services, laying a solid foundation for threat research and detection engineering. Essential reading for those aiming to master threat hunting and detection in Okta environments.
Read More -
ShinyHunters-branded operations are using sophisticated vishing and victim-branded sites to steal data from cloud-based SaaS applications.
Read More
Related rules
- Okta Successful Login After Credential Attack
- First Occurrence of Okta User Session Started via Proxy
- Potential Okta Brute Force (Multi-Source)
- Potential Okta Password Spray (Multi-Source)
- Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource