Safeguard
Application Security•

Detecting Use of Unused Cloud Regions (T1535)

Attackers like regions you never look at. How unused or unsupported cloud regions hide activity, what to alert on and how to switch regions off.

Safeguard Security Team
3 min read

Unused/Unsupported Cloud Regions (T1535) is a Stealth technique for IaaS. Adversaries who have compromised an account that manages cloud infrastructure create resources in regions the victim does not use, hoping nobody is watching.

How attackers use it

Providers run infrastructure around the world for performance, redundancy and compliance. Most customers use only a few regions and may not monitor the rest. MITRE explains that an adversary who creates resources in an unused region may be able to work undetected.

There is a second variation. Regions differ in what they support, and an adversary may pick one that lacks advanced detection services to avoid being noticed. MITRE gives an example of adversary use of unused AWS regions: mining cryptocurrency through Resource Hijacking, which can cost an organization a great deal over time depending on the compute used.

How to detect it

MITRE's analytic describes detecting creation of instances, services or resources in normally unused or unsupported regions, especially after initial account access or credential use from known regions. Correlate resource provisioning across regions with an absence of earlier usage, and with alerting from standard logging services, for example a threat detection service that is not enabled in that region.

In practice:

  1. Alert on any resource creation event in a region outside your approved list.
  2. Review billing by region. Cost in a region you never use is a strong signal.
  3. Make sure audit logging and detection services cover every region, and not only the ones in daily use.
  4. Look for new credentials or access keys created shortly before the activity.

How to reduce the risk

MITRE lists one mitigation, Software Configuration: cloud providers may allow customers to deactivate unused regions. Where your provider allows it, turn off regions you do not need. You can also use organization level policies that deny actions in regions outside your approved list, if your provider supports them.

Check your own environment

Read only AWS CLI examples:

# Which regions are enabled for this account?
aws ec2 describe-regions --all-regions --query "Regions[].[RegionName,OptInStatus]" --output text

# Any instances in a region you do not use? (change the region)
aws ec2 describe-instances --region eu-north-1 --query "Reservations[].Instances[].InstanceId" --output text

Then ask:

  • Which regions does each team genuinely use?
  • Are unused opt in regions disabled?
  • Does logging and threat detection cover all regions?
  • Do you have a cost alert by region?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Why would an attacker choose a region your team never uses?

Nobody is likely to watch it, and some regions lack advanced detection services, so activity there may go unnoticed, as in the cryptocurrency mining example MITRE gives.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.