AN0899: Analytic 0899
Adversaries create user accounts via identity provider APIs or admin portals (e.g., Azure AD, Okta). These accounts may be assigned elevated privileges or used in chained authentication. Detection monitors Add User activity from suspicious IPs or automation sources, followed by role/permission escalation.
Analyst context for executives and security teams
This analytic is about detecting suspicious creation of user accounts in an identity provider, especially when new accounts are created from unusual IP addresses or automation-like sources and then receive elevated roles or permissions. For leaders, the business issue is identity control: a newly created and privileged account can undermine access governance, incident containment, and audit confidence even if endpoint controls never see malware.
Executive priority
Prioritize this as an identity security and resilience validation item. Executives should ask whether the organization can prove who created new identity-provider accounts, from where, by what method, and whether those accounts were quickly granted privileged access. This supports incident decision-making, compliance evidence for account provisioning controls, and budget prioritization for identity logging, privileged access governance, and SOC monitoring.
Technical view
SOC and IR teams should validate monitoring for identity-provider Add User events across supported identity platforms, including admin portal and API-driven creation. The key analytic pattern is account creation from suspicious IPs or automation sources followed by role or permission escalation. Because ATT&CK provides no separate detection logic and no relationship context for this object, teams should map the analytic to local identity audit logs, administrator activity logs, API activity, role assignment events, and source-network context.
Likely telemetry
- Identity provider audit logs for user creation events
- Administrator portal activity logs
- Identity provider API activity logs
- Role assignment and permission change events
- Source IP address, geolocation, ASN, VPN/proxy, or network reputation context where available
Detection direction
- Confirm that Add User events are collected from the identity provider and retained long enough for investigation.
- Correlate new account creation with near-term role or permission escalation.
- Tune for suspicious source context, such as unusual IPs or automation sources, while accounting for legitimate provisioning systems.
- Baseline expected account-provisioning paths so HR, IAM, and approved automation do not create excessive false positives.
- Review blind spots around API-created accounts, service-account-driven provisioning, and identity logs not forwarded to the SOC.
Mitigation priorities
- Establish clear ownership and approval workflow for identity-provider account creation.
- Restrict who and what automation can create accounts or assign privileged roles.
- Separate account creation from privilege assignment where possible, with review or additional approval for elevated access.
- Ensure identity-provider audit logging is enabled and monitored for both portal and API actions.
- Maintain evidence for audits showing account creation, approver, source, and privilege changes.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and it has no supplied relationship context. The description specifically references identity provider APIs and admin portals, with examples including Azure AD and Okta, and focuses on Add User activity followed by role or permission escalation.
Official detection content is not provided, tactics are unspecified, and no related techniques, data sources, mitigations, or groups were supplied. Local identity architecture, logging configuration, provisioning workflows, and approved automation must be reviewed before determining detection quality or risk exposure.
Analytic 0899
Adversaries create user accounts via identity provider APIs or admin portals (e.g., Azure AD, Okta). These accounts may be assigned elevated privileges or used in chained authentication. Detection monitors Add User activity from suspicious IPs or automation sources, followed by role/permission escalation.
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 | e8cc243d234c… |
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 AN0899Open 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.