Entra immutable ID set
A user's IMMUTABLE ID / SourceAnchor was set or changed — the value that binds a cloud account to an on-premises identity.
What it detects
A user's IMMUTABLE ID / SourceAnchor was set or changed — the value that binds a cloud account to an on-premises identity.
This is the account-takeover primitive behind the well-known AADInternals technique. The immutable ID is what directory synchronization and federated sign-in use to decide "this on-prem identity IS that cloud identity". An attacker with directory-write access sets the immutable ID of an account they control to match a victim's on-prem anchor; the federated trust then authenticates them AS the victim. No password is changed, no MFA method is registered, and no sign-in looks anomalous — the victim's own account is never touched, so password resets and MFA re-enrolment do not undo it.
It is a one-event technique on Update user, which is why nothing threshold- based can see it, and the property name (SourceAnchor / ImmutableId) is the only thing that distinguishes it from routine attribute maintenance.
MITRE ATT&CK mapping
False positives and triage
Legitimate causes exist and are almost always project work, not steady state: onboarding Entra Connect, a domain migration, re-anchoring accounts after an AD forest consolidation, or hard-matching a cloud-only account to a new on-prem object. Expect these in a burst, from a sync or migration account, during a known change window.
Escalate on: a change to a SINGLE account outside any migration, an actor that is not the sync account or a directory administrator, a target that is a guest or a consumer identity (#EXT#), or an anchor set to a value belonging to a privileged on-prem user. Confirm against the account the anchor now points to — that account, not the edited one, is the likely intended victim.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/entra_immutable_id_set.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_immutable_id_set
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1098, T1078.004, T1556]
description: |
A user's IMMUTABLE ID / SourceAnchor was set or changed — the value that binds
a cloud account to an on-premises identity.
This is the account-takeover primitive behind the well-known AADInternals
technique. The immutable ID is what directory synchronization and federated
sign-in use to decide "this on-prem identity IS that cloud identity". An
attacker with directory-write access sets the immutable ID of an account they
control to match a victim's on-prem anchor; the federated trust then
authenticates them AS the victim. No password is changed, no MFA method is
registered, and no sign-in looks anomalous — the victim's own account is never
touched, so password resets and MFA re-enrolment do not undo it.
It is a one-event technique on `Update user`, which is why nothing threshold-
based can see it, and the property name (`SourceAnchor` / `ImmutableId`) is the
only thing that distinguishes it from routine attribute maintenance.
match:
provider_any: [AzureAD, Office365]
event_action_contains_any:
- "Update user"
raw_message_contains_any:
- "SourceAnchor="
- "ImmutableId="
- "immutableId="
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Legitimate causes exist and are almost always project work, not steady state:
onboarding Entra Connect, a domain migration, re-anchoring accounts after an
AD forest consolidation, or hard-matching a cloud-only account to a new on-prem
object. Expect these in a burst, from a sync or migration account, during a
known change window.
Escalate on: a change to a SINGLE account outside any migration, an actor that
is not the sync account or a directory administrator, a target that is a guest
or a consumer identity (`#EXT#`), or an anchor set to a value belonging to a
privileged on-prem user. Confirm against the account the anchor now points to —
that account, not the edited one, is the likely intended victim.
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.