|
Modify Cloud Compute Infrastructure: Create Snapshot
Other sub-techniques of Modify Cloud Compute Infrastructure (5)
| ID | Name |
|---|---|
| T1578.002 | Create Cloud Instance |
| T1578.001 | Create Snapshot |
| T1578.003 | Delete Cloud Instance |
| T1578.005 | Modify Cloud Compute Configurations |
An adversary may create a snapshot or data backup within a cloud account to evade defenses. A snapshot is a point-in-time copy of an existing cloud compute component such as a virtual machine (VM), virtual hard drive, or volume. An adversary may leverage permissions to create a snapshot in order to bypass restrictions that prevent access to existing compute service infrastructure, unlike in
Revert Cloud Instance [MITRE]
where an adversary may revert to a snapshot to evade detection and remove evidence of their presence.
An adversary may
Create Cloud Instance [MITRE]
, mount one or more created snapshots to that instance, and then apply a policy that allows the adversary access to the created instance, such as a firewall policy that allows them inbound and outbound SSH access.
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 perform the actions in the AWS CloudTrail Event Name(s) section.
With access to an AWS identity that has the appropriate permissions, threat actors may create an Amazon EBS snapshot of an Amazon EBS volume to create a point-in-time backup of that volume as a way to exfiltrate the snapshot. Threat actors can also create a snapshot of an EC2 instance, use the EC2 instance to perform unauthorized actions, then revert to a snapshot to evade detection and remove evidence of previously performed unauthorized actions on the EC2 instance.
Detection
The creation of a snapshot is a common part of operations within many cloud environments. Events should then not be viewed in isolation, but as part of a chain of behavior that could lead to other activities such as the creation of one or more snapshots and the restoration of these snapshots by a new user account. In AWS, CloudTrail logs capture the creation of snapshots and all API calls for AWS Backup as events. Using the information collected by CloudTrail, you can determine the request that was made, the IP address from which the request was made, which user made the request, when it was made, and additional details.(Citation: AWS Cloud Trail Backup API). In Azure, the creation of a snapshot may be captured in Azure activity logs. Backup restoration events can also be detected through Azure Monitor Log Data by creating a custom alert for completed restore jobs.(Citation: Azure - Monitor Logs) Google's Admin Activity audit logs within their Cloud Audit logs can be used to detect the usage of thegcloud compute instances create command to create a new VM disk from a snapshot.(Citation: Cloud Audit Logs) It is also possible to detect the usage of the GCP API with the "sourceSnapshot": parameter pointed to "global/snapshots/[BOOT_SNAPSHOT_NAME].(Citation: GCP - Creating and Starting a VM)AWS Specific Content
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
ec2:CreateSnapshot.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.
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.
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.