AN0018: Analytic 0018
Federated login using SSO or OAuth grant to cloud control plane, followed by directory or permissions enumeration
Analyst context for executives and security teams
This analytic points to a high-value identity pattern: a federated SSO or OAuth login into a cloud control plane followed by directory or permissions enumeration. For leaders, the business issue is not the login alone; it is whether the organization can distinguish normal administrative discovery from post-access reconnaissance that may precede privilege misuse, cloud control-plane changes, or broader identity compromise.
Executive priority
Prioritize this as an identity and cloud-control-plane visibility question. Executives and risk owners should ask whether SSO/OAuth activity, cloud console/API access, and directory or permission enumeration are centrally logged, retained, and reviewable during an incident. This is also useful audit evidence for access governance, privileged access oversight, and incident response readiness.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around Identity Provider telemetry for federated sign-ins and OAuth grants, then correlate that activity with subsequent cloud control-plane directory, role, group, policy, or permission listing activity. Because the ATT&CK object provides no official detection logic and no tactics or relationships, local baselining is required to separate expected administrator, automation, and audit activity from unusual enumeration after federated access.
Likely telemetry
- Identity Provider federated sign-in logs
- SSO authentication events
- OAuth grant or consent events
- Cloud control-plane access logs where available
- Directory enumeration events such as user, group, role, or application listing
Detection direction
- Validate that federated login and OAuth grant events can be correlated to later cloud control-plane enumeration by the same identity, session, client, or source context.
- Baseline expected administrative and automation-driven enumeration to reduce false positives.
- Look for enumeration shortly after new or unusual federated access, especially involving privileged identities or unfamiliar OAuth clients, where local policy supports that interpretation.
- Confirm logging captures both the identity-layer event and the follow-on directory or permissions discovery; many gaps occur when IdP logs and cloud control-plane logs are stored separately.
- Because no official detection is supplied, treat this as a detection design prompt rather than a ready-to-deploy rule.
Mitigation priorities
- Ensure Identity Provider and cloud control-plane audit logging are enabled, retained, and accessible to SOC and IR teams.
- Review SSO/OAuth governance, including app consent, grant review, and privileged identity monitoring.
- Apply least privilege to identities that can enumerate sensitive directory, role, or permission data.
- Document normal administrative enumeration workflows so detection teams can tune alerts without suppressing meaningful anomalies.
- Test incident response playbooks for federated identity compromise scenarios, including evidence collection from both IdP and cloud control-plane sources.
Analyst notes and limits
The object is a detection analytic, AN0018, for the Enterprise ATT&CK domain and Identity Provider platform. Its description is limited to federated login using SSO or OAuth grant to a cloud control plane followed by directory or permissions enumeration. No relationships, tactics, aliases, labels, or official detection logic were supplied.
This take is constrained to the supplied ATT&CK fields. It does not assert active exploitation, adversary attribution, specific cloud providers, guaranteed detection, or confirmed business impact. Local environment architecture, logging configuration, identity governance, and normal administrator behavior are required to operationalize the analytic.
Analytic 0018
Federated login using SSO or OAuth grant to cloud control plane, followed by directory or permissions enumeration
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 | 7bf85047a4a8… |
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 AN0018Open 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.