Entra risky sign-in
A Microsoft Entra sign-in that Identity Protection rated risky, or that carries a named risk detection.
What it detects
A Microsoft Entra sign-in that Identity Protection rated risky, or that carries a named risk detection. These are Microsoft's highest-fidelity identity signals — a risky sign-in, especially one that SUCCEEDED, is a strong account-takeover indicator.
The detection-type list below is the high-fidelity subset, rated high because each names a specific adversary behaviour rather than a score. It is deliberately NOT the complete set, and it never can be: Microsoft adds detection types regularly. cloud.identity.entra_risk_detection sits underneath this rule and fires on any OPEN detection regardless of type, so a type missing from this list degrades the finding from high to medium instead of losing it. That layering is the point — enumerating vendor strings is a losing game played on top of a safety net, not instead of one.
Note what is absent from the match: any test on the risk LEVEL beyond high/medium. A tenant without Entra ID P2 reports riskLevel: hidden, so level-based matching is blind in exactly the tenants an MSP most often inherits. The named types work regardless of licence.
MITRE ATT&CK mapping
- T1078.004Valid Accounts: Cloud Accounts· Initial Access
- T1550.001Use Alternate Authentication Material: Application Access Token· Defense Evasion
- T1557Adversary-in-the-Middle· Credential Access
- T1110.003Brute Force: Password Spraying· Credential Access
- T1090.003Proxy: Multi-hop Proxy· Command and Control
False positives and triage
Identity Protection can rate benign sign-ins as risky, and some types are much noisier than others. Atypical travel and unfamiliar sign-in properties fire on ordinary travel, a new VPN egress or a newly onboarded automation; anonymized IP address fires on privacy browsers and some consumer VPNs as well as on Tor.
The signal is a risky sign-in that SUCCEEDED, a high risk level, or one of the specific detections — impossible travel, malicious IP, leaked credentials, or any of the token-theft types. Correlate with what the account did next: a new inbox rule, a registered authentication method, an OAuth consent grant, or mass file access. Confirm and, if real, revoke sessions AND rotate credentials — revoking sessions alone does not help if the adversary holds a stolen refresh token.
Treat the token-theft group as materially more serious than the location group. Impossible travel is often a VPN; attackerinTheMiddle and anomalousToken mean MFA was satisfied and then bypassed, so the usual "but they passed MFA" reassurance does not apply.
userReportedSuspiciousActivity deserves its own note: it is not an inference at all, it is the account owner saying they did not initiate the prompt. Treat a report as a report.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/entra_risky_signin.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_risky_signin
version: 1.1.0
status: stable
severity: high
confidence: 0.75
platforms: [application]
mitre_techniques: [T1078.004, T1550.001, T1557, T1110.003, T1090.003]
description: |
A Microsoft Entra sign-in that Identity Protection rated risky, or that carries
a named risk detection. These are Microsoft's highest-fidelity identity
signals — a risky sign-in, especially one that SUCCEEDED, is a strong
account-takeover indicator.
The detection-type list below is the high-fidelity subset, rated high because
each names a specific adversary behaviour rather than a score. It is
deliberately NOT the complete set, and it never can be: Microsoft adds
detection types regularly. `cloud.identity.entra_risk_detection` sits
underneath this rule and fires on any OPEN detection regardless of type, so a
type missing from this list degrades the finding from high to medium instead
of losing it. That layering is the point — enumerating vendor strings is a
losing game played on top of a safety net, not instead of one.
Note what is absent from the match: any test on the risk LEVEL beyond
high/medium. A tenant without Entra ID P2 reports `riskLevel: hidden`, so
level-based matching is blind in exactly the tenants an MSP most often
inherits. The named types work regardless of licence.
match:
provider: AzureAD
event_category: authentication
raw_message_contains_any:
# Aggregate risk level, for tenants that report one at all.
- "risk=high"
- "risk=medium"
# --- Location and network origin ---
- "anonymizedIPAddress" # Tor / anonymizing proxy
- "maliciousIPAddress"
- "maliciousIPAddressValidCredentialsBlockedIP"
- "malwareInfectedIPAddress"
- "suspiciousIPAddress"
- "riskyIPAddress"
- "nationStateIP"
- "impossibleTravel"
- "unlikelyTravel"
- "mcasImpossibleTravel"
- "newCountry"
# --- Credential compromise ---
- "leakedCredentials"
- "passwordSpray"
# --- Token theft and session hijack (AiTM) ---
# The detections that matter most against modern phishing kits: the victim
# completes MFA, the proxy steals the resulting token, and every subsequent
# sign-in looks legitimate because it IS the legitimate token.
- "attackerinTheMiddle"
- "anomalousToken"
- "tokenIssuerAnomaly"
- "attemptedPrtAccess"
# --- Behaviour and client anomalies ---
- "unfamiliarFeatures"
- "suspiciousBrowser"
- "anomalousUserActivity"
- "suspiciousAPITraffic"
- "suspiciousSendingPatterns"
- "mcasSuspiciousInboxManipulationRules"
# --- Microsoft threat intelligence and human verdicts ---
- "investigationsThreatIntelligence"
- "investigationsThreatIntelligenceSigninLinked"
- "adminConfirmedUserCompromised"
- "adminConfirmedSigninCompromised"
# The user pressed "this wasn't me" on an MFA prompt. Under MFA-fatigue
# (push-bombing) this is the victim telling you directly.
- "userReportedSuspiciousActivity"
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Identity Protection can rate benign sign-ins as risky, and some types are much
noisier than others. Atypical travel and unfamiliar sign-in properties fire on
ordinary travel, a new VPN egress or a newly onboarded automation; anonymized
IP address fires on privacy browsers and some consumer VPNs as well as on Tor.
The signal is a risky sign-in that SUCCEEDED, a high risk level, or one of the
specific detections — impossible travel, malicious IP, leaked credentials, or
any of the token-theft types. Correlate with what the account did next: a new
inbox rule, a registered authentication method, an OAuth consent grant, or
mass file access. Confirm and, if real, revoke sessions AND rotate credentials
— revoking sessions alone does not help if the adversary holds a stolen
refresh token.
Treat the token-theft group as materially more serious than the location
group. Impossible travel is often a VPN; `attackerinTheMiddle` and
`anomalousToken` mean MFA was satisfied and then bypassed, so the usual
"but they passed MFA" reassurance does not apply.
`userReportedSuspiciousActivity` deserves its own note: it is not an inference
at all, it is the account owner saying they did not initiate the prompt. Treat
a report as a report.
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.