Hijacked Cloud Accounts: Defending Against T1586.003

Compromise Accounts: Cloud Accounts (T1586.003) is a resource development technique tagged PRE. The adversary takes over existing cloud accounts and uses them during targeting.

The account might be a storage account, a cloud console login, or a service that sends mail and text messages. In each case the adversary gets capability without running servers of their own, and the bill goes to someone else.

How attackers use it

MITRE says adversaries can use compromised cloud accounts for several purposes.

• Cloud storage services such as Dropbox, Microsoft OneDrive or AWS S3 buckets, for exfiltration to cloud storage or to upload tools.
• Infrastructure, such as virtual private servers or serverless infrastructure.
• Cloud messaging services such as Twilio, SendGrid, AWS End User Messaging, AWS SNS and AWS SES, for spam or phishing.

MITRE notes that this lets adversaries develop sophisticated capabilities without managing their own servers. In some cases they may target privileged service provider accounts, aiming to use the trusted relationship between providers and their customers.

The methods for compromising the account are the ones you would expect from the page: gathering credentials through phishing for information, purchasing credentials from third-party sites, password spraying, and attempts to steal application access tokens. Before compromise, adversaries may do reconnaissance to choose which accounts to go after.

Two points follow for the owner. First, cloud credentials are worth money even if your data is not. Second, the account that sends 50,000 messages overnight is yours as far as the provider and the recipients are concerned.

How to detect it

MITRE says much of the activity is outside the visibility of the target organization, and points detection efforts toward related stages such as exfiltration, for example transferring data to a cloud account.

As the account owner you can see what the adversary does with your account. These are general practices.

• Sign-in logs: new locations, new devices, repeated failures across many accounts, and successful logins that follow a spray pattern.
• Audit logs for changes that grant access: new access keys, new roles, new OAuth app consents, new federation settings.
• Billing and usage alerts. A sudden jump in compute, storage or message sending is often the first visible sign.
• Messaging services: alert on send volume, new sender identities and new verified domains.
• Storage: alert on public access changes and on large downloads or uploads by principals that do not normally do so.

Most providers can send these alerts to a monitored channel. The hard part is making sure somebody owns the channel.

Credentials are another source. A key committed to a repository or pasted into a ticket is a credential an adversary can buy or find. Secret scanning on repositories finds those before someone else does.

Click through it at your own pace, or open it full screen.

How to reduce the risk

MITRE lists Pre-compromise as the mitigation: preventive controls cannot easily stop behavior outside enterprise defenses. The protection you can build is on the account side.

• Require multi-factor authentication for every human user, with stronger methods for administrators.
• Prefer short-lived credentials and role assumption over long-lived access keys. Where keys are unavoidable, rotate them and scope them tightly.
• Block or limit legacy authentication, which can bypass multi-factor controls.
• Defend against password spraying with lockout or throttling and by checking for common passwords.
• Control third-party app consent so that users cannot grant broad permissions to unknown apps. MITRE names application access token theft as one route.
• Scan repositories, build logs and chat exports for secrets, and revoke anything found.
• Set budget alarms on every account, including small test accounts.
• Review privileged access given to service providers and consultants, and remove it when work ends.

One more practical point concerns cost. Because adversaries use hijacked accounts for compute and messaging, the first signal is often a bill. Set the thresholds low on every account, including the sandbox that one engineer created two years ago. Small accounts tend to have weak controls and no alerts, and they are cheap for an adversary to run up.

Also check what your messaging accounts are allowed to do. A mail sending account that can send to any address, from any sender identity, is a bigger risk than one locked to a verified domain and a daily limit. Lowering the ceiling reduces what a thief can do before someone notices.

Finally, plan the response before you need it. If an access key leaks, you should be able to disable it within minutes, list what it did in the audit log and rotate any secret it could read. Practice once with a test key so that the steps are familiar.

Check your own environment

• List all access keys in your cloud accounts with their age and last use. Disable those unused for 90 days.
• Check that every console user has multi-factor authentication.
• Review OAuth app consents and remove those you do not recognize.
• Confirm that budget and usage alerts exist, and who receives them.
• Search a repository for strings that look like keys, with a scanner you trust, before an outsider does.
• AWS CLI, read-only: aws iam list-access-keys --user-name USER lists keys for a user, and aws iam get-access-key-last-used --access-key-id KEYID shows when one was last used (replace the placeholders with your values).
• AWS CLI, read-only: aws iam generate-credential-report followed by aws iam get-credential-report gives a per-user summary of keys, passwords and MFA status.

Quick check

Sources

• MITRE ATT&CK T1586.003: Cloud Accounts