Entra risk detection
Microsoft Entra ID Protection raised a risk detection against an account and it is still OPEN (riskState: atRisk) — nobody has dismissed it, remediated…
What it detects
Microsoft Entra ID Protection raised a risk detection against an account and it is still OPEN (riskState: atRisk) — nobody has dismissed it, remediated it, or marked it safe.
This rule exists because the alternative does not work. Identity Protection names each detection with a riskEventType string, and the obvious rule is to list the interesting ones — anonymizedIPAddress, impossibleTravel, leakedCredentials, and so on. That list is a losing game twice over:
* Microsoft adds detection types regularly, and a rule that enumerates them is silently blind to every one added after it was written. * A tenant WITHOUT Entra ID P2 reports riskLevel: hidden and riskDetail: hidden. The detection is real and the account is genuinely at risk; only the severity is masked behind the licence. Any rule keyed on "risk is high or medium" misses every detection in every non-P2 tenant — which, for an MSP, is most of them.
So this rule keys on the one field that is always present, never masked, and never changes: the STATE. If Identity Protection says the account is at risk and nobody has closed it out, that is worth an analyst's attention regardless of which detection fired or what the tenant is licensed for.
cloud.identity.entra_risky_signin still names the high-fidelity types and rates them higher. This rule is the backstop underneath it, so an unrecognized type degrades to a medium finding instead of to silence.
MITRE ATT&CK mapping
- T1078.004Valid Accounts: Cloud Accounts· Initial Access
False positives and triage
Identity Protection rates on behaviour, so a genuinely benign change of behaviour can raise a detection: a first trip abroad reads as atypical travel, a new corporate VPN egress reads as an unfamiliar or anonymized address, and a newly onboarded automation reads as unfamiliar sign-in properties. The state being open means only that nobody has triaged it yet — not that it is real.
Triage by asking what the type actually claims, then whether the sign-in SUCCEEDED. A detection on a failed sign-in is an attempt; the same detection on a successful one is a possible account takeover, and the account's next actions (a new inbox rule, a registered MFA method, mass file access) are what settle it.
riskLevel: hidden is not missing data and is not a parsing failure — it is what a tenant without Entra ID P2 reports. Treat it as "level unknown", never as "level low".
Closing a detection in the Entra portal (dismiss / remediate / confirm safe) moves it out of atRisk, so triaged detections stop matching on re-import.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/entra_risk_detection.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_risk_detection
version: 1.0.0
status: stable
severity: medium
confidence: 0.75
platforms: [application]
mitre_techniques: [T1078.004]
description: |
Microsoft Entra ID Protection raised a risk detection against an account and it
is still OPEN (`riskState: atRisk`) — nobody has dismissed it, remediated it,
or marked it safe.
This rule exists because the alternative does not work. Identity Protection
names each detection with a `riskEventType` string, and the obvious rule is to
list the interesting ones — `anonymizedIPAddress`, `impossibleTravel`,
`leakedCredentials`, and so on. That list is a losing game twice over:
* Microsoft adds detection types regularly, and a rule that enumerates them
is silently blind to every one added after it was written.
* A tenant WITHOUT Entra ID P2 reports `riskLevel: hidden` and
`riskDetail: hidden`. The detection is real and the account is genuinely
at risk; only the severity is masked behind the licence. Any rule keyed on
"risk is high or medium" misses every detection in every non-P2 tenant —
which, for an MSP, is most of them.
So this rule keys on the one field that is always present, never masked, and
never changes: the STATE. If Identity Protection says the account is at risk
and nobody has closed it out, that is worth an analyst's attention regardless
of which detection fired or what the tenant is licensed for.
`cloud.identity.entra_risky_signin` still names the high-fidelity types and
rates them higher. This rule is the backstop underneath it, so an unrecognized
type degrades to a medium finding instead of to silence.
match:
provider: AzureAD
# Set by the Identity Protection normalizer for `riskDetections` and
# `riskyUsers`, whether they arrived via a diagnostic setting or straight off
# Microsoft Graph.
event_action: risk_detection
# atRisk is the only OPEN state. dismissed / remediated / confirmedSafe are
# closed by a human and must not re-alert; confirmedCompromised is a different
# and far more serious finding (cloud.identity.entra_confirmed_compromise).
ext:azuread.risk_state_any:
- atRisk
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Identity Protection rates on behaviour, so a genuinely benign change of
behaviour can raise a detection: a first trip abroad reads as atypical travel,
a new corporate VPN egress reads as an unfamiliar or anonymized address, and a
newly onboarded automation reads as unfamiliar sign-in properties. The state
being open means only that nobody has triaged it yet — not that it is real.
Triage by asking what the type actually claims, then whether the sign-in
SUCCEEDED. A detection on a failed sign-in is an attempt; the same detection on
a successful one is a possible account takeover, and the account's next actions
(a new inbox rule, a registered MFA method, mass file access) are what settle
it.
`riskLevel: hidden` is not missing data and is not a parsing failure — it is
what a tenant without Entra ID P2 reports. Treat it as "level unknown", never
as "level low".
Closing a detection in the Entra portal (dismiss / remediate / confirm safe)
moves it out of `atRisk`, so triaged detections stop matching on re-import.
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.