Detecting and Preventing Data Theft from Cloud Storage (T1530)

Data from Cloud Storage (T1530) is a Collection technique. Adversaries read data from cloud storage services. MITRE lists IaaS, Office Suite and SaaS as platforms, which covers object storage such as Amazon S3, Azure Storage and Google Cloud Storage, document stores such as OneDrive and Google Drive, and platforms such as Slack, Confluence, Salesforce and Dropbox that hold files as a main or side feature.

How attackers use it

For IaaS object storage there is often no application in front of the data. MITRE explains that objects are retrieved directly through the cloud API. In SaaS products, adversaries may collect data directly from APIs or backend storage objects rather than through the front end.

Two causes dominate:

• Misconfiguration. MITRE says there have been many incidents where storage was improperly secured, typically by unintentionally allowing public access to unauthenticated users, overly broad access for all users, or access for anyone outside the identity and access management system. That can expose credit card data, personal information or medical records.
• Leaked credentials. Adversaries may obtain and abuse credentials leaked in source repositories, logs or other places to reach storage objects.

MITRE's page also lists cases where adversaries used stolen credentials to download data from cloud services such as SharePoint, Teams and OneDrive, enumerated and downloaded objects from AWS storage, and changed an Azure Storage account's settings to expose it for data theft. The pattern is the same each time: valid access, used to read a lot of data.

How to detect it

MITRE's detection strategy describes three behavior chains:

1. A spike in object access from a new IAM user or role, followed by data leaving to external IPs.
2. An OAuth token granted to an external app, followed by a high volume download from OneDrive or Google Drive.
3. An internal account opening shared links that sit outside the organization, followed by a mass file download.

Data sources to turn on: object level access logging for storage (for example S3 server access logs or data events in your cloud audit trail), SaaS audit logs, and identity logs showing new tokens and consents. Alert on:

• First time access by an identity to a sensitive bucket.
• Large listing and download volume in a short time.
• Changes to bucket policies, public access settings and sharing settings.
• Access from addresses outside your expected ranges.

How to reduce the risk

MITRE lists six mitigations:

1. Audit. Check permissions on cloud storage often so open or unprivileged access is denied.
2. Encrypt Sensitive Information. Encrypt data at rest. Managed keys can be rotated by most providers. Make sure your incident plan for a storage breach includes rotating keys and testing impact on client applications.
3. Filter Network Traffic. Use IP based restrictions together with account management, so access is limited to valid users from expected ranges, which blunts use of stolen credentials.
4. Multi-factor Authentication. Use it to restrict access to resources and storage APIs.
5. Restrict File and Directory Permissions. Use access control lists on storage systems and objects.
6. User Account Management. Set permission groups and roles for storage access. Apply strict IAM controls so only the applications, users and services that need access have it. Issue temporary access tokens rather than permanent credentials, especially for entities outside your internal boundary.

Since leaked credentials are a named route, also scan repositories and build logs for secrets before they ship, and rotate any that were exposed.

Check your own environment

Read only AWS CLI examples (replace the bucket name and account ID with yours):

aws s3api get-public-access-block --bucket my-bucket
aws s3api get-bucket-policy-status --bucket my-bucket
aws s3control get-public-access-block --account-id 123456789012

Then consider:

• Is block public access on at account level and for each bucket?
• Which identities and roles can read each sensitive bucket, and why?
• Are object level reads logged, and where do the logs go?
• Is external sharing in your document platforms limited to approved domains?
• Do any long lived access keys exist that could be replaced with temporary credentials?

Try it yourself

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

Quick check

Sources

• MITRE ATT&CK T1530, Data from Cloud Storage