|
Modify Cloud Compute Infrastructure: Modify Cloud Compute Configurations
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 |
Adversaries may modify settings that directly affect the size, locations, and resources available to cloud compute infrastructure in order to evade defenses. These settings may include service quotas, subscription associations, tenant-wide policies, or other configurations that impact available compute. Such modifications may allow adversaries to abuse the victims compute resources to achieve their goals, potentially without affecting the execution of running instances and/or revealing their activities to the victim.
For example, cloud providers often limit customer usage of compute resources via quotas. Customers may request adjustments to these quotas to support increased computing needs, though these adjustments may require approval from the cloud provider. Adversaries who compromise a cloud environment may similarly request quota adjustments in order to support their activities, such as enabling additional
Resource Hijacking [MITRE]
without raising suspicion by using up a victims entire quota. Adversaries may also increase allowed resource usage by modifying any tenant-wide policies that limit the sizes of deployed virtual machines.
Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling
Unused/Unsupported Cloud Regions [MITRE]
. In Azure environments, an adversary who has gained access to a Global Administrator account may create new subscriptions in which to deploy resources, or engage in subscription hijacking by transferring an existing pay-as-you-go subscription from a victim tenant to an adversary-controlled tenant. This will allow the adversary to use the victims compute resources without generating logs on the victim tenant.
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 can modify settings that directly affect the size and resources available to cloud compute infrastructure in order to evade defenses or increase their ability to consume resources, such as changing the instance type or CPU and memory configuration. These settings may include service quotas, subscription associations, tenant-wide policies, or other configurations that impact available compute. Such modifications may allow threat actors to abuse the victims compute resources to achieve their goals.
Detection
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
servicequotas:RequestServiceQuotaIncrease.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.