In cloud environments the account is the perimeter. MITRE ATT&CK tracks the misuse of valid cloud identities as Cloud Accounts (T1078.004), a sub-technique of Valid Accounts. It maps to stealth, persistence, privilege escalation and initial access, and applies to IaaS, Identity Provider, Office Suite and SaaS.
How attackers use it
MITRE defines cloud accounts as those created and configured by an organization for users, remote support, services, or administration of resources in a cloud provider or SaaS application. They can exist only in the cloud, or be hybrid joined with on-premises systems through syncing or federation with a source such as Windows Active Directory.
From the MITRE page:
- Service or user accounts may be targeted through brute force, phishing or other means.
- Federated or synced accounts may be a pathway into both on-premises systems and the cloud, for example through shared credentials used to log onto remote services.
- Highly privileged cloud accounts, whether federated, synced or cloud only, may allow pivoting to on-premises environments by using SaaS based software deployment tools to run commands on hybrid joined devices.
- An adversary may create long lasting additional cloud credentials on a compromised account to keep access. Such credentials may also be used to bypass security controls such as MFA.
- Cloud accounts may be able to assume temporary elevated cloud access or other privileges within the environment.
The thread running through all of this is that a cloud identity can reach very far, and that it often has no malware footprint at all.
How to detect it
MITRE's strategy (DET0546) describes four analytics:
- Anomalous authentication activity, such as sign-ins from impossible geolocations, or legacy protocols used by high privileged accounts.
- Cloud account use for API calls beyond normal scope, such as IAM changes or access to services the account never used before.
- Unexpected use of cloud productivity tools, such as downloading large numbers of files or creating external shares.
- Login and usage patterns that deviate from the typical profile of a Microsoft 365 or Google Workspace user.
What to collect: identity provider sign-in logs, cloud control plane audit logs such as the activity logs of your IaaS provider, and SaaS audit logs. Keep them in a place where an analyst can search across all three. Cloud incidents are usually reconstructed from the sequence of sign-in, then API calls, then data access, and that sequence needs all three sources.
Useful alert ideas that follow from MITRE's analytics:
- A privileged role is activated by an account that has not used it for a long time.
- A new access key is created on an existing user.
- A sign-in uses a legacy protocol.
- A mailbox or drive suddenly produces many downloads or new external shares.
How to reduce the risk
MITRE lists these mitigations:
- Use multi-factor authentication for cloud accounts, especially privileged ones. Administrative reporting can audit who has it (Multi-factor Authentication).
- Disable legacy authentication, which does not support MFA (Active Directory Configuration).
- Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges (Account Use Policies).
- Use complex, unique passwords for cloud accounts, and rotate passwords and access keys regularly. Cloud providers may track access key age, which helps find keys that need rotation (Password Policies).
- Review privileged cloud account permissions routinely, for roles such as Global Administrator and Privileged Role Administrator in Azure AD. Check for new privileged accounts that were not authorized, alert on privileged roles unused for many days, and consider temporary, just in time privileged access in place of permanent assignment (Privileged Account Management).
- Review user accounts periodically, remove inactive or unnecessary ones, and limit the ability of ordinary accounts to create additional accounts (User Account Management).
- Train users to accept only valid MFA push notifications and report suspicious ones (User Training).
Check your own environment
- List every identity with administrative rights in each cloud account and SaaS tenant. Does each have MFA?
- How old are your oldest access keys? Which have never been used?
- Are legacy protocols blocked at your identity provider?
- Are cloud audit logs enabled in every account and region, and shipped somewhere central?
- Who can create new users or credentials?
With the AWS command line, these read-only calls help with the key questions:
aws iam list-users
aws iam list-access-keys --user-name EXAMPLE_USER
aws iam get-access-key-last-used --access-key-id EXAMPLE_KEY_ID
Replace the example values with names from your own account. The last call shows when and where a key was last used, which is the quickest way to spot a forgotten one.
Try it yourself
Cloud accounts spread across many providers are hard to see in one place. This demo shows cloud connectors bringing the picture together.
Click through it at your own pace, or open it full screen.
Quick check
Why can a hybrid joined cloud account threaten on-premises systems?
MITRE says high privileged federated, synced or cloud only accounts may let an adversary pivot on premises by using SaaS based software deployment tools to run commands on hybrid joined devices.
Why might an adversary add extra credentials to a compromised cloud account?
To keep long lasting access. MITRE notes such credentials may also bypass security controls such as MFA.
Sources
- MITRE ATT&CK, T1078.004 Cloud Accounts: https://attack.mitre.org/techniques/T1078/004/
