AN0460: Analytic 0460
Chain: (1) SaaS admin API or PowerShell remote session reads tenant password/authentication settings (e.g., M365 Unified Audit Log ‘Cmdlet’ with `Get-MsolPasswordPolicy`/`Get-OrganizationConfig` parameters that expose password settings); (2) same session proceeds to mailbox or tenant changes.
Analyst context for executives and security teams
AN0460 highlights a SaaS administrative pattern where a session first reads tenant password or authentication settings and then continues into mailbox or tenant changes. For leaders, the practical issue is not just the read action; it is whether administrative discovery of identity policy is being used immediately before configuration changes that could affect tenant security, mail operations, or audit posture.
Executive priority
Prioritize this as a SaaS identity and administration monitoring question: can the organization prove who reviewed password/authentication settings, from where, and what changes followed in the same session? This matters for incident triage, privileged access governance, compliance evidence, and confidence that mailbox or tenant changes are reviewed in context rather than as isolated events.
Technical view
SOC and detection teams should validate whether SaaS admin activity logs capture both parts of the chain: reads of tenant password/authentication settings through admin APIs or PowerShell remote sessions, and subsequent mailbox or tenant changes in the same session. The supplied example references M365 Unified Audit Log Cmdlet activity with parameters such as Get-MsolPasswordPolicy and Get-OrganizationConfig that expose password settings. Because no official detection logic is provided, teams should build or review correlation based on session identity, time proximity, administrative command/API activity, and follow-on tenant or mailbox modifications.
Likely telemetry
- SaaS administrative audit logs
- M365 Unified Audit Log Cmdlet records where applicable
- PowerShell remote session activity for SaaS administration
- Admin API activity logs
- Tenant configuration change events
Detection direction
- Confirm that reads of password/authentication settings are logged with enough detail to identify command/API name, parameters, actor, session, and source.
- Correlate policy-read activity with subsequent mailbox or tenant changes by the same session or administrator within a defensible time window.
- Tune for legitimate administrative workflows, such as planned tenant maintenance or policy review, to reduce false positives.
- Look for blind spots where SaaS audit retention, PowerShell logging, admin API visibility, or session identifiers are incomplete.
- Use this analytic as context enrichment for administrative-change alerts rather than treating any single settings read as automatically malicious.
Mitigation priorities
- Ensure privileged SaaS administration is restricted to approved administrators and governed through documented change processes.
- Validate that SaaS audit logging is enabled, retained, and accessible for investigation of admin API, PowerShell, tenant, and mailbox activity.
- Require review or approval for sensitive tenant and mailbox changes where operationally appropriate.
- Periodically test whether incident responders can reconstruct an administrative session from password/authentication settings access through follow-on changes.
- Use compliance and access reviews to verify that administrative discovery and configuration changes are attributable to authorized personnel.
Analyst notes and limits
The value of AN0460 is relationship-based: it points defenders toward a sequence of administrative behavior, not a standalone indicator. In practice, the strongest detections will depend on local SaaS logging fidelity, session correlation quality, and knowledge of approved administrative workflows.
The ATT&CK object provides a description and SaaS platform scope but no official detection text, tactics, relationships, aliases, or labels. This take does not assert active exploitation, attribution, impact, or guaranteed detection coverage. Local tenant architecture and logging configuration are required to operationalize it.
Analytic 0460
Chain: (1) SaaS admin API or PowerShell remote session reads tenant password/authentication settings (e.g., M365 Unified Audit Log ‘Cmdlet’ with `Get-MsolPasswordPolicy`/`Get-OrganizationConfig` parameters that expose password settings); (2) same session proceeds to mailbox or tenant changes.
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 | 1b79695e62a8… |
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 AN0460Open 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.