Okta threat detected
Okta ThreatInsight blocked or flagged a request it judged malicious (security.threat.detected).
What it detects
Okta ThreatInsight blocked or flagged a request it judged malicious (security.threat.detected).
This is Okta's OWN verdict, reached from signals we cannot see: the reputation of the source IP across Okta's whole customer base, and password-spray patterns spanning tenants. It is the one Okta event that arrives pre-adjudicated, so it carries higher confidence than anything a rule of ours infers from a single tenant's logs — and it is worth surfacing even when the outcome is DENY, because a blocked attempt still tells you the tenant is being targeted.
MITRE ATT&CK mapping
False positives and triage
ThreatInsight is reputation-driven, so a shared corporate egress IP, a VPN exit or a CGNAT range can be flagged because of somebody else's traffic — check whether the IP is one your users legitimately come from before treating it as an attack on this tenant. The outcome matters: DENY means Okta already blocked it, so the question is whether the same actor succeeded by another route; ALLOW with a threat verdict is the urgent case. Correlate with what that IP did before and after.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/cloud/okta_threat_detected.yaml, licensed under the Apache License 2.0.
id: cloud.okta.threat_detected
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [application]
mitre_techniques: [T1078.004, T1110]
description: |
Okta ThreatInsight blocked or flagged a request it judged malicious
(`security.threat.detected`).
This is Okta's OWN verdict, reached from signals we cannot see: the reputation of
the source IP across Okta's whole customer base, and password-spray patterns
spanning tenants. It is the one Okta event that arrives pre-adjudicated, so it
carries higher confidence than anything a rule of ours infers from a single
tenant's logs — and it is worth surfacing even when the outcome is DENY, because a
blocked attempt still tells you the tenant is being targeted.
match:
provider: Okta
event_action_contains_any:
- security.threat.detected
correlation_keys: [source_ip]
false_positive_guidance: |
ThreatInsight is reputation-driven, so a shared corporate egress IP, a VPN exit or
a CGNAT range can be flagged because of somebody else's traffic — check whether the
IP is one your users legitimately come from before treating it as an attack on this
tenant. The outcome matters: DENY means Okta already blocked it, so the question is
whether the same actor succeeded by another route; ALLOW with a threat verdict is
the urgent case. Correlate with what that IP did before and after.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.