Entra security attribute change
A custom security attribute was set or changed on a directory object.
What it detects
A custom security attribute was set or changed on a directory object.
Custom security attributes drive attribute-based access control: policies and role assignments can grant access to whoever carries a given attribute value. That makes the attribute an access-granting mechanism which does not appear in any group or role membership, so an account can gain reach without a single membership change to review.
Kept at medium and single-event on purpose. Attributes are also ordinary metadata in tenants that use them for classification, so this is a lead that matters when the attribute is one an access policy reads — which the analyst can determine and the log cannot.
MITRE ATT&CK mapping
False positives and triage
Tenants using ABAC set these attributes as part of joiner-mover-leaver automation, which produces steady low-level volume from a service principal — allowlist that identity once confirmed rather than tuning the rule. What should be escalated is an INTERACTIVE change to an attribute that an access policy reads, particularly one an actor applies to their own account or to a service principal they control. Determining which attributes are load-bearing is a one-off piece of tenant knowledge worth writing down during onboarding.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 50%. Source: rules/cloud/entra_security_attribute_change.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_security_attribute_change
version: 1.0.0
status: stable
severity: medium
confidence: 0.5
platforms: [application]
mitre_techniques: [T1098, T1078.004]
description: |
A custom security attribute was set or changed on a directory object.
Custom security attributes drive attribute-based access control: policies and
role assignments can grant access to whoever carries a given attribute value.
That makes the attribute an access-granting mechanism which does not appear in
any group or role membership, so an account can gain reach without a single
membership change to review.
Kept at medium and single-event on purpose. Attributes are also ordinary metadata
in tenants that use them for classification, so this is a lead that matters when
the attribute is one an access policy reads — which the analyst can determine and
the log cannot.
match:
event_action_any:
- "Update user."
- "Update service principal."
- "Update application."
raw_message_contains_any:
- "CustomSecurityAttribute"
- "customSecurityAttributes"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Tenants using ABAC set these attributes as part of joiner-mover-leaver automation,
which produces steady low-level volume from a service principal — allowlist that
identity once confirmed rather than tuning the rule. What should be escalated is
an INTERACTIVE change to an attribute that an access policy reads, particularly
one an actor applies to their own account or to a service principal they control.
Determining which attributes are load-bearing is a one-off piece of tenant
knowledge worth writing down during onboarding.
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.