T1535: 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.[1]
Analyst context for executives and security teams
Unused/Unsupported Cloud Regions matters because an attacker with access to cloud management accounts may create IaaS resources in regions the organization does not normally use or monitor. This can turn a cloud visibility gap into a stealth and cost problem, including unwanted compute spend such as cryptocurrency mining, and can also complicate compliance expectations around approved geographies.
Executive priority
Leaders should ask whether cloud governance defines approved regions, whether monitoring and billing review cover every available region, and whether identity controls for cloud administrators are strong enough to prevent or quickly investigate unauthorized resource creation. This is a practical cloud security and audit-readiness issue: regions outside normal operations can become blind spots for SOC visibility, incident scoping, cost control, and data residency assurance.
Technical view
For IaaS environments, validate whether resource inventory, control-plane activity, identity activity, and cost telemetry are collected across all regions, not only production regions. ATT&CK provides no official detection text for T1535, but the relationship to DET0247 indicates a detection strategy exists for adversary use of unused or unsupported cloud regions. SOC and detection teams should baseline expected regional usage, alert on resource creation or service activation in non-approved regions, and account for regions where advanced detection services may not be available.
Likely telemetry
- Cloud control-plane/API audit logs for resource creation, modification, and deletion across all IaaS regions
- Cloud IAM authentication and authorization activity for accounts that manage infrastructure
- Cloud asset inventory or configuration-state data showing resources by region
- Billing, usage, and cost anomaly data by region and service
- Cloud security service status or coverage data indicating which regions are monitored or unsupported
Detection direction
- Validate that log collection and alerting are region-inclusive; a common blind spot is monitoring only regions currently used by the business.
- Build or tune detections around creation of compute, storage, networking, or supporting resources in regions outside the approved operating baseline.
- Correlate unusual regional activity with cloud management account activity, since ATT&CK notes access is usually obtained through compromised infrastructure-management accounts.
- Use billing and usage anomalies as supporting evidence, especially for high-compute activity consistent with the ATT&CK-described resource hijacking example.
- Include an exception process for legitimate expansion, disaster recovery testing, compliance-driven regional use, or performance testing to reduce false positives.
Mitigation priorities
- Define and maintain an approved-region policy for IaaS use, including business, compliance, and resiliency exceptions.
- Use software/configuration controls consistent with M1054 to restrict or govern use of unused regions where the cloud platform supports it.
- Ensure cloud logging, inventory, billing review, and security monitoring cover all available regions, including regions not currently used for production.
- Harden and monitor cloud infrastructure management accounts because the technique commonly depends on compromised accounts with management access.
- Review regional differences in detection-service availability before approving workloads in a new region.
Analyst notes and limits
This technique is primarily a cloud governance and visibility problem mapped to the stealth tactic. The supplied ATT&CK object specifically covers IaaS and unused or unsupported geographic cloud regions. The relationship context adds DET0247 as a relevant detection strategy and M1054 Software Configuration as a mitigation direction, but local cloud architecture and policy determine the exact control implementation.
The official ATT&CK object does not provide detection text, named procedures, or vendor-specific implementation details beyond an AWS-related external reference example. This take does not assert active exploitation, attribution, or existing detection coverage. Organizations must verify their own region usage, monitoring scope, identity permissions, and cloud provider capabilities.
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.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 62b19d1d3caa… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
CloudSploit - Unused AWS Regions
CloudSploit. (2019, June 8). The Danger of Unused AWS Regions. Retrieved October 8, 2019.
Open source URL -
[2]
mitre-attack T1535Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.