Cloud accounts are cheap to make and easy to miss. T1136.003, Cloud Account, covers adversaries creating accounts in cloud services to keep access. MITRE files it under persistence for IaaS, SaaS, Office Suite and Identity Provider platforms.
The reasoning matches other account creation techniques. An extra account gives secondary credentialed access that does not need a persistent remote access tool on a system. In the cloud there is nothing to install, just an API call.
How attackers use it
With sufficient access, an adversary can add accounts, and MITRE stresses that these are not only human users. Cloud providers handle service accounts in different ways:
- Azure. Service accounts include service principals and managed identities, which can be linked to resources such as OAuth applications, serverless functions and virtual machines, so those resources can act in the environment.
- GCP. Service accounts can be linked to specific resources, and other accounts can impersonate them.
- AWS. There is no specific service account concept. Resources can be directly granted permission to assume roles.
MITRE also notes that adversaries may create accounts with access only to specific cloud services, which can reduce the chance of detection.
Creation is usually just step one. Once the account exists, it can be strengthened, for example by adding additional cloud credentials (T1098.001) or additional cloud roles (T1098.003). The page lists AADInternals, APT29 and LAPSUS$ in connection with this technique.
How to detect it
MITRE's detection strategy has a variant for each kind of service.
- Identity providers. Accounts created through provider APIs or admin portals, such as Azure AD or Okta, possibly with elevated privileges. Monitor Add User activity from suspicious IPs or automation sources, followed by role or permission escalation.
- IaaS. Users or roles made through the cloud API, CLI or console. Watch for a temporal chain:
CreateUser, then policy or role attachment such asAttachUserPolicy, then credential generation, especially from automation or foreign IP ranges. - SaaS. Accounts created through admin dashboards or integrations in apps like Zoom, Salesforce or Slack. Monitor lifecycle create or provisioning events from nonstandard sources or times.
- Office suites. Microsoft 365 or Google Workspace APIs used to create users, service accounts or guest accounts. Follow-on behavior includes logins, role escalation or service principal token generation.
The sequence matters more than the single event. A user created and immediately given a powerful role and a new access key is a different story from a user created by your HR integration.
How to reduce the risk
MITRE lists three mitigations.
- Use multi-factor authentication for user and privileged accounts.
- Limit who can create accounts. Few identities should hold the permission to create other accounts, and privileged accounts should not do day to day work that could expose them.
- Segment. Limit access to critical systems and domain controllers. Most cloud environments support separate virtual private cloud instances for further segmentation.
Treat service identities with the same care as people. List them, give each an owner, and review them on a schedule.
Check your own environment
AWS, list IAM users with creation dates and then look for who created recent ones:
aws iam list-users --query 'Users[].[UserName,CreateDate]' --output table
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser
Ask the same of the other platforms you use: in your identity provider, review the audit log for user creation events, and in each SaaS admin console, review the user list against your HR roster.
A short checklist:
- Is every identity in your cloud accounts tied to an owner or a system?
- Are creation events from every account and region sent to one log store?
- Do alerts fire when a new user is followed by a role attachment within the hour?
Try it yourself
Cloud account checks start with connecting your accounts so the evidence is in one place. This demo shows how cloud connectors work.
Click through it at your own pace, or open it full screen.
Quick check
Why are service principals and managed identities part of this technique?
They are cloud accounts too. They can be linked to resources and granted permissions, so a new one can give an attacker access without a human user.
Which sequence of IAM events does MITRE highlight?
CreateUser, then policy attachment such as AttachUserPolicy, then credential generation, especially from automation or foreign IP ranges.
Sources
- MITRE ATT&CK, T1136.003 Cloud Account
