AN0459: Analytic 0459
Chain: (1) IdP policy/read operations by a principal (e.g., Microsoft Entra/Graph requests to read password or authentication policies); (2) adjacent risky changes (role assignment, app consent) by same principal. Use IdP audit logs.
Analyst context for executives and security teams
AN0459 is an identity-provider detection analytic focused on a suspicious sequence: a principal reads authentication or password policy information and then performs nearby risky identity changes such as role assignment or application consent. For leaders, the value is not the policy read alone; it is the combination of reconnaissance-like policy access followed by identity control changes that could affect access governance and incident scope.
Executive priority
Prioritize this analytic where identity provider control plane activity is business-critical. It can help validate whether the organization has audit evidence to connect policy discovery with privileged or consent-related changes by the same principal. This is relevant to incident triage, access governance, compliance evidence, and decisions about tightening monitoring around role assignment and app consent workflows.
Technical view
SOC and detection teams should validate whether IdP audit logs can correlate policy/read operations with adjacent risky changes by the same principal. The supplied analytic specifically references Microsoft Entra/Graph-style requests to read password or authentication policies and subsequent role assignment or app consent activity, but the supported platform is broadly Identity Provider. Because no official detection logic or relationships are supplied, teams should implement this as a correlation pattern rather than a single-event alert.
Likely telemetry
- Identity provider audit logs
- Authentication or password policy read events
- Role assignment change events
- Application consent or permission grant events
- Principal identity, timestamp, source application/client, and target resource fields
Detection direction
- Confirm IdP audit logs retain both read operations and administrative change events with a common principal identifier.
- Correlate policy/read operations with role assignment or app consent changes by the same principal within a locally appropriate time window.
- Tune for expected administrative workflows, automation accounts, and approved change windows to reduce false positives.
- Review blind spots where Graph/API reads, service principals, or app consent events are not fully logged or normalized.
- Treat matches as identity-control-plane investigation leads, not proof of compromise, because ATT&CK provides no official detection logic or outcome claims for this analytic.
Mitigation priorities
- Ensure IdP audit logging is enabled, retained, and accessible for investigation.
- Limit who can read sensitive policy configuration and who can perform role assignment or application consent actions.
- Use least privilege and change-control review for identity administration principals and automation accounts.
- Require periodic review of app consent, role assignments, and privileged identity workflows.
- Document detection assumptions and evidence sources for audit and incident response readiness.
Analyst notes and limits
This object is a detection analytic, not a technique. Its decision value is in validating whether identity telemetry can link policy discovery to high-risk identity changes by the same principal. No ATT&CK tactics, aliases, labels, official detection logic, or relationship context were supplied.
The source fields do not provide a concrete query, severity, prevalence, adversary attribution, active exploitation claim, or related ATT&CK techniques. Local IdP event schemas, retention, and administrative processes are required to operationalize and tune this analytic.
Analytic 0459
Chain: (1) IdP policy/read operations by a principal (e.g., Microsoft Entra/Graph requests to read password or authentication policies); (2) adjacent risky changes (role assignment, app consent) by same principal. Use IdP audit logs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7e6e766ff16c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0459Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.