ATT&CK T1535 Unused/Unsupported Cloud Regions Guide

Most organisations run workloads in two or three cloud regions but hold credentials that work in thirty, and an attacker who launches resources in a region you never open in the console can run for weeks before the bill gives them away. MITRE ATT&CK T1535 Unused/Unsupported Cloud Regions describes adversaries creating cloud instances in geographic regions the victim does not use, or in regions that lack advanced detection services, in order to evade detection. In ATT&CK v20 it sits in the Stealth tactic (TA0005) and applies to IaaS. Access almost always comes through a compromised account that manages cloud infrastructure, so this is a technique of stolen keys and roles rather than exploits. This guide explains why regions become blind spots, how to detect activity in them, and the guardrails that close them on AWS, Azure and Google Cloud. It is for cloud security, platform and detection engineering teams. For the related compute changes see the MITRE ATT&CK T1578 Modify Cloud Compute Infrastructure guide.

Key takeaways

Region scope is a control gap, not a geography issue. Many security services are configured per region, so coverage stops where your deployment templates stopped.
Deny is better than watch. A region restriction in an SCP, Azure Policy or Google Cloud organisation policy removes the technique; detection only shortens it.
Disabling an AWS opt-in region does not delete what is there. AWS states resources keep running and incurring charges, so clean up first.
The first call in a new region is the signal. ATT&CK's v20 detection strategy correlates resource creation in regions with no historical usage, especially where GuardDuty is not enabled.
Cryptomining is the usual payload. ATT&CK's own example is mining through Resource Hijacking in unused AWS regions, which can cost substantial sums before anyone looks.

ATT&CK explains that providers offer infrastructure throughout the world for performance, redundancy and compliance, that customers often use a subset of regions, and that they may not actively monitor the others. A variation exploits differences in functionality: regions that do not support a detection service let the adversary avoid it. In practice the gap opens in several places at once:

Layer	Typical gap	What to check
Threat detection	Detectors such as Amazon GuardDuty are enabled per region; AWS recommends enabling GuardDuty in all supported regions, including those you do not use, so findings are generated there	Detector status per account and region; delegated administrator auto-enable settings
Audit logging	A single-region trail misses other regions; a multi-region trail logs all enabled regions	`IsMultiRegionTrail` true on the organisation trail
Posture and configuration	Configuration recorders, posture standards and conformance packs deployed only where workloads run	Recorder and standard status per region
Dashboards and alerts	Saved queries, cost dashboards and runbooks filtered to the home region	Query filters on region fields; cost anomaly monitors covering all regions
Human attention	Console defaults to the home region, so resources elsewhere are rarely seen	Periodic all-region inventory reports
Service availability	Some security features launch later in newer regions	Provider regional service lists before allowing a region

How the AWS region model affects exposure

AWS distinguishes default regions, launched before 20 March 2019, which are enabled automatically and cannot be disabled, from opt-in regions launched after that date, which are disabled by default. Only opt-in regions can be enabled or disabled, through EnableRegion and DisableRegion with the permissions account:EnableRegion and account:DisableRegion. Two consequences follow. First, every account starts with more than a dozen default regions an attacker can use and which you cannot switch off, so a policy guardrail is the only way to close them. Second, enabling an opt-in region is itself a control-plane event, which ATT&CK lists under T1578.005 Modify Cloud Compute Configurations as a way to open new deployment locations. Azure and Google Cloud have no equivalent region switch for customers; restriction is done by policy.

How the technique is used

Resource hijacking: ATT&CK's example is mining cryptocurrency in unused AWS regions (T1496.001 Compute Hijacking). Mining operators maximise run time, and an unwatched region gives it to them.
Credential-led campaigns: in the AWS crypto-mining campaign of 2025, compromised IAM credentials with admin-like permissions had miners running within 10 minutes, and AWS's guidance afterwards was to enable GuardDuty across all accounts and regions. In the Storm-1283 OAuth apps abuse, Microsoft describes mining VMs named after the tenant domain and zone to look routine, which shows why region and naming alone are weak signals without identity context.
Staging and persistence: the same blind spot hides storage buckets, functions or instances used to stage data or keep a foothold. ATT&CK's detection strategy lists bucket creation alongside instance launches.

The access that enables this is covered in the MITRE ATT&CK T1078 Valid Accounts Guide, and the mining payload in the Cryptojacking Guide.

Detection

ATT&CK v20 detection strategy DET0247 detects creation of instances, services or resources in normally unused or unsupported regions, especially after credential use from known regions, and correlates provisioning with the absence of historical usage and with standard alerting not being present in that region. Its log sources are CloudTrail RunInstances, CreateBucket and GetCallerIdentity, and VPC Flow Logs for high outbound traffic from new-region resources. A practical rule set:

Rule	Source and field	Logic
First activity in a region	CloudTrail `awsRegion` on management events; Azure activity log resource location; GCP audit log resource location	Any create or write event in a region not in the approved list, or with no events in the previous 90 days
Region enablement	CloudTrail `EnableRegion` from the Account Management service	Any call outside a change ticket; high severity from a workload identity
Denied region attempts	CloudTrail `errorCode` AccessDenied where the deny came from a region guardrail; Azure policy deny events	Repeated denials from one principal across several regions suggest probing
Region sweep	CloudTrail `Describe*` calls such as `DescribeInstances` and `DescribeRegions` across many regions in minutes	One principal enumerating most regions, a common precursor to launches
Detector gaps	GuardDuty, posture and configuration recorder status per region	Any enabled region without a detector, reported daily
Spend signal	Cost and usage data grouped by region	Non-zero compute spend in a region with no approved workloads
Egress from new resources	VPC Flow Logs in all regions	High outbound traffic or mining pool connections from a recently created resource

Centralise the logs: a multi-region organisation trail delivered to a dedicated log archive account is the foundation. AWS documents that when an opt-in region is enabled, CloudTrail creates a copy of each multi-region trail there. See the AWS CloudTrail Guide.
Detectors everywhere: enable GuardDuty in every supported region through the delegated administrator with auto-enable for new accounts. See the Amazon GuardDuty Guide and the AWS Security Hub Guide.
Identity context: raise severity when the caller is a long-lived access key, a role assumed from an unfamiliar network, or a service principal with no history in that region. See the Detection Engineering for Non-Human Identities Guide.

Metrics

Region guardrail coverage: percentage of accounts, subscriptions and projects under an enforced region restriction.
Detector coverage: percentage of enabled regions with threat detection and configuration recording active, target 100.
Unapproved region resources: count of resources outside approved regions, target zero after clean-up.
Time to detect: minutes from the first create event in an unapproved region to an alert.
Enabled opt-in regions: number of AWS opt-in regions enabled without a documented business need.

Prevention: closing regions by provider

ATT&CK's mitigation is M1054 Software Configuration, noting that providers may allow customers to deactivate unused regions. Deactivation alone is not enough on AWS, because default regions cannot be disabled, so use a policy guardrail on every provider:

Provider	Guardrail	What it covers	Caveats
AWS	Service control policy denying requests where `aws:RequestedRegion` is not in the approved list, or the Control Tower Region deny control (`AWS-GR_REGION_DENY` for the landing zone, `CT.MULTISERVICE.PV.1` per OU)	All regional API calls in member accounts	Global services such as IAM and Organizations are exempted; the Control Tower home region cannot be denied; check for existing resources first, because access to them is lost
AWS	Keep opt-in regions disabled; restrict `account:EnableRegion`	Opt-in regions only	Disabling does not delete resources and charges continue
Azure	Built-in policies "Allowed locations" (`e56962a6-4747-49cd-b67b-bf8b01975c4c`) and "Allowed locations for resource groups" (`e765b5de-1225-4ba3-bd56-1ac6695af988`) assigned at management group scope	New resources and resource groups	"Allowed locations" excludes resource groups and resources that use the global region, so assign both
Google Cloud	Organisation policy `constraints/gcp.resourceLocations` with value groups such as `in:eu-locations`	New resources in supported services that let you choose a location	Existing resources and global resources are not affected; Security Health Analytics reports existing violations; it is not a data residency commitment

See the AWS Organizations and SCPs Guide, the Azure Policy and Management Groups Guide and the Cloud Landing Zone Security Guide.

Decision guidance

Small organisation, one region: deny every other region by policy and skip per-region tuning entirely; keep detectors on everywhere anyway as a backstop.
Multinational or regulated: approve regions per organisational unit or management group to match residency needs, rather than one global list, so a European OU cannot launch in the US and vice versa.
Disaster recovery regions: include them in the approved list and in full detector coverage; a recovery region that is only monitored during failover is an unused region in disguise.
Exceptions: grant a region exception by tagging or by moving an account to a dedicated OU, never by exempting a role from the guardrail, because exempt roles are the ones attackers want.

Phased rollout

Inventory: run an all-region inventory of resources and spend in every account, subscription and project, and agree the approved region list with platform owners.
Turn on coverage: enable multi-region logging and detectors in all regions before restricting anything, so you can see what the guardrail will break.
Clean up: remove or migrate resources in regions you will deny; on AWS do this before disabling opt-in regions.
Pilot: apply the region restriction to a sandbox OU, management group or folder in audit or test mode, review denied calls for two weeks, and fix global-service exemptions.
Enforce: attach to production units in waves. Rollback is detaching the policy from one unit, which restores access immediately.
Verify: in an authorised test, attempt to create a small resource in a denied region with a test identity and confirm both the deny and the alert.

Where identity fits

T1535 needs an identity with create permissions and no region boundary. Most of those identities are non-human: deployment roles, Terraform service principals and long-lived access keys created years ago with * permissions. Scope workload identities to the regions they deploy to through permission boundaries or conditions on aws:RequestedRegion, replace static keys with federated short-lived credentials, and remove unused keys. See the How to find unused AWS IAM roles and access keys guide and the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.

Common failure patterns

Home-region-only security baselines: infrastructure as code that deploys detectors and recorders only where workloads run leaves every other region dark.
Disabling instead of cleaning: disabling an AWS opt-in region while resources remain leaves them running and billing, out of reach of your own IAM.
Azure location policy without the resource group policy: "Allowed locations" alone does not restrict resource group location or global resources.
Exempting automation roles: excluding the pipeline role from the region deny means a stolen pipeline key ignores it.
Relying on the bill: cost alerts arrive daily at best; the 2025 AWS campaign had miners running in 10 minutes.

Framework mapping

Framework	References
ATT&CK v20	T1535 (TA0005 Stealth); related T1578.005, T1496.001, T1078.004; mitigation M1054 Software Configuration
NIST SP 800-53 Rev. 5	CM-7 Least Functionality, CM-8 System Component Inventory, AC-6 Least Privilege, AU-12 Audit Record Generation, SI-4 System Monitoring
NIST CSF 2.0	ID.AM-02 (inventories of services and systems), PR.PS-01 (configuration management), PR.PS-04 (log records), DE.CM-09 (computing monitored)
CIS Controls v8.1	Control 1 Inventory of Enterprise Assets, Control 4 Secure Configuration, Control 8 Audit Log Management
MITRE D3FEND	D3-RAPA Resource Access Pattern Analysis

Practitioner checklist

Agree and document the approved region list per organisational unit or management group.
Run an all-region resource and spend inventory and remove anything outside the list.
Enable a multi-region organisation trail and threat detection in every supported region.
Deny unapproved regions with an SCP or Control Tower control, Azure location policies and the GCP resource locations constraint.
Keep AWS opt-in regions disabled unless needed and restrict who can enable them.
Alert on the first create event in an unapproved region and on region enablement.
Scope workload identities to their regions and retire long-lived access keys.
Test the deny and the alert with a controlled identity at least twice a year.

MITRE ATT&CK T1535 Unused/Unsupported Cloud Regions: Closing the Regions Nobody Watches

Key takeaways

Why unused regions become blind spots