Entra ID Protection Admin Confirmed Compromise

Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/10/06"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/10/06"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID
 11Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or
 12sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be
 13investigated immediately.
 14"""
 15false_positives = [
 16    """
 17    Administrators may mark accounts as compromised during security testing or incident response exercises. If this is
 18    expected behavior in your environment, consider adjusting the rule or adding exceptions for specific test accounts.
 19    """,
 20]
 21from = "now-9m"
 22index = ["logs-azure.identity_protection-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "Entra ID Protection Admin Confirmed Compromise"
 26note = """## Triage and analysis
 27
 28This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response.
 29
 30### Possible investigation steps
 31
 32- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`).
 33- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account.
 34- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information.
 35- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event.
 36- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised).
 37- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation.
 38- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user.
 39- Check for any suspicious activities associated with the user account, including:
 40    - Unusual sign-in locations or IP addresses
 41    - Access to sensitive resources or applications
 42    - Changes to user profile, permissions, or MFA settings
 43    - Bulk email sending or data exfiltration activities
 44- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection.
 45- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes.
 46
 47### False positive analysis
 48
 49- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter.
 50- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises.
 51
 52### Response and remediation
 53
 54- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in.
 55- Revoke all active sessions and authentication tokens for the compromised account, including:
 56    - Primary refresh tokens (PRTs)
 57    - OAuth tokens
 58    - Session cookies
 59    - Application-specific passwords
 60- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account.
 61- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled.
 62- Review all activities performed by the compromised account, including:
 63    - Email forwarding rules or inbox rules
 64    - File access and downloads
 65    - Changes to security settings or permissions
 66    - Creation of new users or service principals
 67- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities.
 68- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified.
 69- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication.
 70- Review and strengthen identity protection policies and risk-based conditional access rules.
 71- Document the incident, including the timeline, scope of compromise, and remediation actions taken.
 72- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents.
 73"""
 74references = [
 75    "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-investigate-risk",
 76    "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks",
 77    "https://learn.microsoft.com/en-us/graph/api/resources/riskdetection",
 78]
 79risk_score = 99
 80rule_id = "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890"
 81setup = """#### Required Microsoft Entra ID Protection Logs
 82To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration.
 83"""
 84severity = "critical"
 85tags = [
 86    "Domain: Cloud",
 87    "Domain: Identity",
 88    "Data Source: Azure",
 89    "Data Source: Entra ID",
 90    "Data Source: Entra ID Protection Logs",
 91    "Use Case: Identity and Access Audit",
 92    "Use Case: Threat Detection",
 93    "Tactic: Initial Access",
 94    "Resources: Investigation Guide",
 95]
 96timestamp_override = "event.ingested"
 97type = "query"
 98
 99query = '''
100event.dataset: azure.identity_protection and
101    azure.identityprotection.properties.risk_detail: (
102        "adminConfirmedSigninCompromised" or
103        "adminConfirmedUserCompromised"
104    )
105'''
106
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1078"
112name = "Valid Accounts"
113reference = "https://attack.mitre.org/techniques/T1078/"
114[[rule.threat.technique.subtechnique]]
115id = "T1078.004"
116name = "Cloud Accounts"
117reference = "https://attack.mitre.org/techniques/T1078/004/"
118
119
120
121[rule.threat.tactic]
122id = "TA0001"
123name = "Initial Access"
124reference = "https://attack.mitre.org/tactics/TA0001/"
125
126[rule.investigation_fields]
127field_names = [
128    "@timestamp",
129    "event.action",
130    "azure.identityprotection.properties.risk_detail",
131    "azure.identityprotection.properties.risk_level",
132    "azure.identityprotection.properties.risk_state",
133    "azure.identityprotection.properties.risk_event_type",
134    "azure.identityprotection.properties.risk_type",
135    "azure.identityprotection.properties.user_principal_name",
136    "azure.identityprotection.properties.user_display_name",
137    "azure.identityprotection.properties.user_id",
138    "azure.identityprotection.properties.ip_address",
139    "azure.identityprotection.properties.activity",
140    "azure.identityprotection.properties.additional_info",
141    "azure.identityprotection.properties.correlation_id",
142    "azure.correlation_id",
143    "source.ip",
144]

Triage and analysis

This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response.

Possible investigation steps

  • Review the azure.identityprotection.properties.risk_detail field to determine if the compromise was confirmed at the sign-in level (adminConfirmedSigninCompromised) or user level (adminConfirmedUserCompromised).
  • Check the azure.identityprotection.properties.user_principal_name field to identify the compromised user account.
  • Review the azure.identityprotection.properties.user_display_name field for additional user identification information.
  • Examine the azure.identityprotection.properties.risk_level field to understand the severity level assigned to the risk event.
  • Check the azure.identityprotection.properties.risk_state field to verify the current state of the risk (should be confirmed as compromised).
  • Review the azure.correlation_id field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation.
  • Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user.
  • Check for any suspicious activities associated with the user account, including:
    • Unusual sign-in locations or IP addresses
    • Access to sensitive resources or applications
    • Changes to user profile, permissions, or MFA settings
    • Bulk email sending or data exfiltration activities
  • Review the azure.identityprotection.properties.additional_info field for any additional context provided by the administrator or Entra ID Protection.
  • Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes.

False positive analysis

  • Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter.
  • Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises.

Response and remediation

  • Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in.
  • Revoke all active sessions and authentication tokens for the compromised account, including:
    • Primary refresh tokens (PRTs)
    • OAuth tokens
    • Session cookies
    • Application-specific passwords
  • Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account.
  • Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled.
  • Review all activities performed by the compromised account, including:
    • Email forwarding rules or inbox rules
    • File access and downloads
    • Changes to security settings or permissions
    • Creation of new users or service principals
  • Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities.
  • Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified.
  • Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication.
  • Review and strengthen identity protection policies and risk-based conditional access rules.
  • Document the incident, including the timeline, scope of compromise, and remediation actions taken.
  • Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents.

References

Related rules

to-top