Additional Cloud Roles (T1098.003) is the sub-technique of Account Manipulation where an attacker gives an account more power. It maps to persistence and privilege escalation and applies to IaaS, Identity Provider, Office Suite and SaaS.
How attackers use it
MITRE says an adversary may add roles or permissions to an adversary controlled cloud account to maintain persistent access to a tenant. Examples include updating IAM policies in cloud environments or adding a new global administrator in Office 365. With sufficient permissions, a compromised account can gain almost unlimited access to data and settings, including the ability to reset other admins' passwords.
Other details from the page:
- The change may immediately follow Create Account or other malicious account activity, or target existing valid accounts that the adversary has compromised.
- In AWS, an adversary with appropriate permissions may use the CreatePolicyVersion API to define a new version of an IAM policy, or AttachUserPolicy to attach a policy with extra permissions to a compromised user.
- Adversaries may add roles to accounts that live outside the victim tenant. Those external accounts can then act inside the tenant without the adversary having to create or modify a victim owned account.
How to detect it
MITRE's strategy (DET0277) has three analytics:
- New IAM roles or policies attached to a user or service in AWS, GCP or Azure outside normal patterns or hours, often after account compromise.
- A user granted elevated privileges or roles in Entra ID or Okta after suspicious login or account creation activity.
- New admin or role assignment actions in Microsoft 365, used to raise access for persistence or lateral movement.
The cloud audit trail records these events. Alert on policy version creation, policy attachment and admin role assignment, and look for role grants to principals outside your organization.
How to reduce the risk
MITRE lists three mitigations:
- Use multi-factor authentication for user and privileged accounts.
- Make sure all accounts use only the privileges they need. In Azure AD environments, consider Privileged Identity Management (PIM) to define roles that need two or more approvals before assignment (Privileged Account Management).
- Make sure low privileged accounts cannot add permissions to accounts or update IAM policies (User Account Management).
Check your own environment
- Who can attach or edit IAM policies? Is it a short, reviewed list?
- Are there role assignments to identities from other tenants or accounts that nobody can explain?
- Which roles are permanent that could be time limited?
With the AWS command line, a read-only check of what is attached to one user:
aws iam list-attached-user-policies --user-name EXAMPLE_USER
Quick check
Why does MITRE mention roles granted to accounts outside the victim tenant?
Such external accounts can act inside the tenant without the adversary creating or modifying a victim owned account.
Sources
- MITRE ATT&CK, T1098.003 Additional Cloud Roles: https://attack.mitre.org/techniques/T1098/003/
