Entra confirmed compromise

An identity is marked confirmedCompromised in Microsoft Entra ID Protection.

This is not a heuristic and not a score. confirmedCompromised is set when an administrator explicitly confirms the account is compromised, or when Microsoft confirms it from its own threat intelligence. Somebody with authority has already reached the conclusion the rest of the detection pack is trying to reach.

It is worth its own rule at critical severity for a practical reason: the state usually gets set during an incident that started somewhere else — a helpdesk call, a Microsoft notification, an admin acting in the Entra portal. If the case being analysed contains that record, the analyst should not have to notice it among the medium-severity risk detections.

Confidence is deliberately at the top of the scale. The only way this fires without a real compromise is a human marking the wrong account, and that is not a detection error.

• T1078.004Valid Accounts: Cloud Accounts· Initial Access

Effectively none in the usual sense — the state is a human or vendor verdict, not an inference. The realistic mistakes are administrative: an admin confirming compromise on the wrong account during a busy incident, or an old confirmation from a previously handled incident being re-imported with a historical log pull and read as current. Check the detection's timestamp against the case window before treating it as new.

Note that a confirmed compromise also TEACHES Identity Protection: Microsoft feeds these confirmations back into its risk model. That makes the record worth preserving as evidence even after the incident is closed.

Declarative YAML read by the detection engine — data, never executed. Confidence 95%. Source: rules/cloud/entra_confirmed_compromise.yaml, licensed under the Apache License 2.0.

id: cloud.identity.entra_confirmed_compromise
version: 1.0.0
status: stable
severity: critical
confidence: 0.95
platforms: [application]
mitre_techniques: [T1078.004]
description: |
  An identity is marked `confirmedCompromised` in Microsoft Entra ID Protection.

  This is not a heuristic and not a score. `confirmedCompromised` is set when an
  administrator explicitly confirms the account is compromised, or when Microsoft
  confirms it from its own threat intelligence. Somebody with authority has
  already reached the conclusion the rest of the detection pack is trying to
  reach.

  It is worth its own rule at critical severity for a practical reason: the state
  usually gets set during an incident that started somewhere else — a helpdesk
  call, a Microsoft notification, an admin acting in the Entra portal. If the
  case being analysed contains that record, the analyst should not have to notice
  it among the medium-severity risk detections.

  Confidence is deliberately at the top of the scale. The only way this fires
  without a real compromise is a human marking the wrong account, and that is not
  a detection error.
match:
  provider: AzureAD
  ext:azuread.risk_state_any:
    - confirmedCompromised
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
  Effectively none in the usual sense — the state is a human or vendor verdict,
  not an inference. The realistic mistakes are administrative: an admin
  confirming compromise on the wrong account during a busy incident, or an old
  confirmation from a previously handled incident being re-imported with a
  historical log pull and read as current. Check the detection's timestamp
  against the case window before treating it as new.

  Note that a confirmed compromise also TEACHES Identity Protection: Microsoft
  feeds these confirmations back into its risk model. That makes the record
  worth preserving as evidence even after the incident is closed.

• AWS console login failure burstSeverity high
• AWS EC2 password retrievalSeverity medium
• AWS root account usageSeverity high
• Azure automation persistenceSeverity high
• Azure Key Vault secret harvestSeverity critical
• Entra custom role definition changeSeverity high