|
Data from Cloud Storage: S3 Object Collection
AWS Specific Sub-Technique
Other sub-techniques of Data from Cloud Storage (4)
| ID | Name |
|---|---|
| T1530.A001 | S3 Object Collection |
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of an AWS identity with the permissions to retrieve objects from an Amazon S3 bucket.
Using this technique, a threat actor can get objects from an Amazon S3 bucket within an AWS account. The threat actor can then use knowledge about these resources in attempts to further their objectives.
This technique is related to Cloud Storage Discovery > S3 Objects and Buckets, as a threat actor will typically view information about buckets in the AWS account (
s3:ListBuckets) and view objects in the buckets (s3:ListObjects) prior to retrieving the objects. This technique is typically used by threat actors as part of a ransomware campaign.In addition to direct
s3:GetObject API calls, threat actors may generate pre-signed S3 URLs to access or exfiltrate data. Presigned URLs grant time-limited access to objects in Amazon S3 using the credentials of the IAM principal that generated the URL. The generation of a pre-signed URL does not produce an AWS CloudTrail management event. The subsequent use of the URL to access the S3 object is logged, and only if S3 data event logging is enabled. This makes pre-signed URL generation a potentially effective exfiltration method from within compromised containers, as URLs can be generated using the workload's IAM permissions and shared externally without triggering standard CloudTrail-based detections.Detection
AWS Specific Content
If objects and buckets in your environment are viewed in an anomalous way, and Amazon GuardDuty S3 Protection is configured within the AWS account, a GuardDuty finding may be created when this occurs. For example, the Exfiltration:S3/MaliciousIPCaller finding may be triggered when an S3 API commonly used to collect data from an AWS environment was invoked from a known malicious IP address. To view additional information on the GuardDuty S3 Protection finding types, click here.
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained will be logged in CloudTrail. You can use the Event History page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for the events listed in the AWS CloudTrail Event Name(s) section, such as
s3:GetObject. To view object-level API activity such as s3:ListObjects, you will need to log data events with a separate CloudTrail trail as object-level API activity will not show up in CloudTrail Event history.A separate CloudTrail trail will give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions. You can also review events using the console as well as the AWS CLI.When looking through Event history for events related to this technique, you should note that the actions are non-mutable and are therefore listed as
readOnly, which means that the Events will not be visible if there are filters set to show only mutable actions.It is also possible to create a CloudWatch metric filter to watch for when specific AWS API calls are used and perform notification actions if logged, and additionally configure CloudWatch to automatically perform an action in response to an alarm.
S3 data event logging in AWS CloudTrail is essential for detecting data collection via pre-signed URLs. When enabled,
s3:GetObject calls made via pre-signed URLs will appear in CloudTrail with the requester's source IP address. Monitor for s3:GetObject calls originating from IP addresses outside the expected network range for the workload. Without S3 data event logging enabled, there are no records available by default for s3:GetObject operations.Mitigation
AWS Specific Content
You can make sure that principals are scoped with the least-privileged permissions necessary to perform duties, limiting the ability to perform unauthorized actions in an AWS account when not required. One possible method of applying the principle of least-privileged permissions is to use Service Control Policies to restrict the maximum available permissions for the IAM users and IAM roles within your AWS Organizations accounts (note - you should test SCPs in a development environment before deploying them in production).
You can also use IAM Access Analyzer to regularly review and verify access and manage permissions across your AWS environment, which will highlight AWS identities with excessive permissions and the actions performed by those identities.
This technique is typically used by threat actors as part of a ransomware campaign. AWS has published several resources on how to protect against ransomware and mitigate some of the actions described by this technique.
Enable S3 data event logging in AWS CloudTrail for all buckets containing sensitive data. Implement IAM Roles for Service Accounts (IRSA) or EKS Pod Identity to scope S3 permissions to the specific buckets and prefixes each workload requires. Avoid granting broad
s3:GetObject permissions via node-level IAM roles. Use S3 bucket policies to restrict access to specific VPC endpoints or source IP ranges where possible.