Collection
The adversary is trying to gather data of interest for their goal. Collection consists of techniques adversaries may use to gather information and the sources information is collected from that are relevant to following through on the adversary's objectives. Frequently, the next goal after collecting data is to steal (exfiltrate) the data. Common target sources within AWS include S3, DynamoDB, RDS, and Redshift.
Techniques
Techniques: 3
| ID | Name | Description | |
|---|---|---|---|
| T1530 | Data from Cloud Storage |
Adversaries may access data from cloud storage.
Many IaaS providers offer solutions for online data object storage such as Amazon S3, Azure Storage, and Google Cloud Storage. Similarly, SaaS enterprise platforms such as Office 365 and Google Workspace provide cloud-based document storage to users through services such as OneDrive and Google Drive, while SaaS application providers such as Slack, Confluence, Salesforce, and Dropbox may provide cloud storage solutions as a peripheral or primary use case of their platform. In some cases, as with IaaS-based cloud storage, there exists no overarching application (such as SQL or Elasticsearch) with which to interact with the stored objects: instead, data from these solutions is retrieved directly though the Cloud API [MITRE] . In SaaS applications, adversaries may be able to collect this data directly from APIs or backend cloud storage objects, rather than through their front-end application or interface (i.e., Data from Information Repositories [MITRE] ). Adversaries may collect sensitive data from these cloud storage solutions. Providers typically offer security guides to help end users configure systems, though misconfigurations are a common problem. There have been numerous incidents where cloud storage has been improperly secured, typically by unintentionally allowing public access to unauthenticated users, overly-broad access by all users, or even access for any anonymous person outside the control of the Identity Access Management system without even needing basic user permissions. This open access may expose various types of sensitive data, such as credit cards, personally identifiable information, or medical records. Adversaries may also obtain then abuse leaked credentials from source repositories, logs, or other means as a way to gain access to cloud storage objects. |
|
| ↳ | T1530.A001 | S3 Object Collection |
AWS Specific ContentA 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. |
| T1213 | Data from Information Repositories |
Adversaries may leverage information repositories to mine valuable information. Information repositories are tools that allow for storage of information, typically to facilitate collaboration or information sharing between users, and can store a wide variety of data that may aid adversaries in further objectives, such as Credential Access, Lateral Movement, or Defense Evasion, or direct access to the target information. Adversaries may also abuse external sharing features to share sensitive documents with recipients outside of the organization (i.e.,
Transfer Data to Cloud Account [MITRE]
).
The following is a brief list of example information that may hold potential value to an adversary and may also be found on an information repository: * Policies, procedures, and standards * Physical / logical network diagrams * System architecture diagrams * Technical system documentation * Testing / development credentials (i.e., Unsecured Credentials [MITRE] ) * Work / project schedules * Source code snippets * Links to network shares and other internal resources * Contact or other sensitive information about business partners and customers, including personally identifiable information (PII) Information stored in a repository may vary based on the specific instance or environment. Specific common information repositories include the following: * Storage services such as IaaS databases, enterprise databases, and more specialized platforms such as customer relationship management (CRM) databases * Collaboration platforms such as SharePoint, Confluence, and code repositories * Messaging platforms such as Slack and Microsoft Teams In some cases, information repositories have been improperly secured, typically by unintentionally allowing for overly-broad access by all users or even public access to unauthenticated users. This is particularly common with cloud-native or cloud-hosted services, such as AWS Relational Database Service (RDS), Redis, or ElasticSearch. |
|
| ↳ | T1213.A013 | RDS Instance Manipulation |
AWS Specific ContentA prerequisite for this technique is that an Amazon RDS instance has been configured to be publicly accessible from the internet and has unrestricted or overly permissive VPC Security Groups assigned A threat actor can access an Amazon RDS instance to view, modify, copy, or delete data from an RDS instance. Threat actors delete databases and tables as part of extortion attempts and have created ransom notes for the victims in RDS instances through data insertion. |