An adversary may add additional roles or permissions to an adversary-controlled cloud account to maintain persistent access to a tenant. For example, adversaries may update IAM policies in cloud-based environments or add a new global administrator in Office 365 environments.[1][2][3][4] With sufficient permissions, a compromised account can gain almost unlimited access to data and settings (including the ability to reset the passwords of other admins).[5] [4]
3 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has elevated their access to Azure resources using Microsoft.Authorization/elevateAccess/action and Microsoft.Authorization/roleAssignments/write operations to gain User Access Administrator and Owner Azure roles over the victims’ Azure subscriptions.1
Has assigned user access admin roles in order to gain Tenant Root Group management permissions in Azure.1
Has added the global admin role to accounts they have created in the targeted organization's cloud instances.1
All 3 groups for this technique
2 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
During C0027, Scattered Spider used IAM manipulation to gain persistence and to assume or elevate privileges.1
During the SolarWinds Compromise, APT29 granted company administrator privileges to a newly created service principle.1
All 2 campaigns for this technique
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
AN0771 · IaaS
Detection of new IAM roles or policies attached to a user/service in AWS/GCP/Azure outside normal patterns or hours, often following account compromise.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account ModificationDC0010 | AWS:CloudTrail | AttachUserPolicy, CreatePolicyVersion, PutRolePolicy |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| RoleScope | IAM Role type or privilege level assigned (e.g., Admin, Billing, Viewer) |
| UserContext | User, service account, or external federated identity context performing the action |
| PolicyChangeTimeWindow | How quickly multiple roles or policies are added after initial access |
| ExternalRoleOrigin | Cross-account roles from outside trusted tenant list |
AN0772 · Identity Provider
Behavioral chain of a user being granted elevated privileges or roles in Entra ID or Okta following suspicious login or account creation activity.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account ModificationDC0010 | m365:audit | Add member to role, Add app role assignment |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AdminRoleThreshold | Number of accounts allowed to hold sensitive roles like Global Admin |
| RoleAssignmentMethod | Mechanism by which role was added (PowerShell, API, UI) |
| GrantContext | Expected user-to-role mapping defined by org policy |
AN0773 · Office Suite
Detection of new admin or role assignment actions within Microsoft 365/O365 environments to elevate access for persistence or lateral movement.
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account ModificationDC0010 | m365:unified | Add member to role, Set-Mailbox |
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| OfficeRoleType | Admin role type or application role granted |
| TimeWindow | Time between initial login and privilege change |
| ActionOrigin | Was the role assignment local or via federated SSO account |
Use multi-factor authentication for user and privileged accounts.
Ensure that all accounts use the least privileges they require. In Azure AD environments, consider using Privileged Identity Management (PIM) to define roles that require two or more approvals before assignment to users.
Ensure that low-privileged user accounts do not have permissions to add permissions to accounts or update IAM policies.
Tests from Atomic Red Team (MIT licence) · technique definition
26 rules are mapped to this technique. Parent techniques also include their sub-techniques’ rules. Click a slice or key entry to filter the table.
Loading detections...
| Select | Title | Description | Category | Status | Event | Product | MITRE ATT&CK | CVEs | Severity | Author | Created | Updated | ID | Refs |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|