|
Unused/Unsupported Cloud Regions
Adversaries may create cloud instances in unused geographic service regions in order to evade detection. Access is usually obtained through compromising accounts used to manage cloud infrastructure.
Cloud service providers often provide infrastructure throughout the world in order to improve performance, provide redundancy, and allow customers to meet compliance requirements. Oftentimes, a customer will only use a subset of the available regions and may not actively monitor other regions. If an adversary creates resources in an unused region, they may be able to operate undetected.
A variation on this behavior takes advantage of differences in functionality across cloud regions. An adversary could utilize regions which do not support advanced detection services in order to avoid detection of their activity.
An example of adversary use of unused AWS regions is to mine cryptocurrency through
Resource Hijacking
, which can cost organizations substantial amounts of money over time depending on the processing power used.
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 create resources in a region not previously utilized by the AWS account holder, or, has the appropriate permissions to enable or opt-in to regions not previously available.
This technique identifies when cloud resources are created in unused geographic service regions in order to evade detection. A threat actor may need to enable additional regions to use this technique, or simply use regions that a customer is not already using.
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
account:EnableRegion, however, Event history is limited to a single AWS region so any actions taken by a threat actor outside of the region where Event history is being reviewed will not be displayed.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.
You can use AWS Resource Explorer to search and discover AWS resources across Regions and accounts, and specifically for Amazon EC2 resources, you can use EC2 Global View to identify EC2 and VPC resources across multiple Regions in a single console.
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). Alternatively, you can also use SCPs to restrict requests to specific regions within an AWS account. The example policy below denies access to actions outside of the Regions specified - eu-central-1 and eu-west-1.
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.