Detecting T1535 unused/unsupported cloud regions

How T1535 unused cloud regions hide attacker activity

T1535 lets an adversary run infrastructure in cloud regions the organization does not normally use, so that activity falls outside the alerts, dashboards and log pipelines the SOC relies on. On IaaS, that means compute, storage and network resources created in a location where the business has no workloads, so routine anomaly detection has no baseline to compare against. For a SOC lead, the risk is not that the region is hidden from the cloud provider. The risk is that detection content, log forwarding and on-call attention were all scoped to the regions the business uses, and nobody owns the rest.

In intrusions, this behavior typically appears after an adversary has already obtained some cloud credentials, and it is used to stage tooling or hold resources where review is thin. Defenders see it as an unexpected resource creation event in a region with no prior history, often alongside new identities or access keys. Because the technique is described in ATT&CK as a Stealth behavior under TA0005, the question to answer is whether your telemetry would show a resource appearing in a dormant region at all. Confirm which regions your cloud provider's audit logs cover by default, which ones your SIEM ingests, and whether an alert fires on activity in a region with no recorded use.

This page maps detection to ATT&CK v20.0, released by MITRE on 2026-10-13, and the mappings should be re-checked against later releases, since ATT&CK can rename, deprecate or revoke techniques and sub-techniques between versions. Treat the region inventory as a decision, not a default: agree which regions are approved, who can approve a new one, and what happens when a resource appears outside that list. The outcome should be a documented baseline that the detection logic can test against, which is the starting point for the cyber range rehearsal covered later on this page.

Which telemetry reveals activity in unused cloud regions

This table maps the three telemetry types named for T1535 to the cloud log or flow sources that carry them and the open-source collectors that can ingest them. Read each row as a detection input: the signal describes what activity in a region with no approved workloads should look like, and the collector column shows where to pull it into your pipeline. Confirm data component IDs against the ATT&CK version you target before writing rules.

Telemetry	Cloud log or flow source	Signal to look for	Open-source collection path
Network Connection Creation (DC0082)	Virtual network flow logs for each subnet in every enabled region	New outbound or inbound connections originating from compute resources in a region with no approved workloads	Vendor flow log export to object storage, then Filebeat or Fluent Bit into Wazuh or Security Onion
User Account Metadata	Cloud identity audit log entries recording sign-ins, role assignments and account changes tagged with a region or location	Successful sign-in or API session from a region absent from the approved list, especially for privileged roles	Cloud audit log export to a queue, then a Logstash or Vector pipeline forwarding to Wazuh or a SIEM
Cloud Storage Creation	Control plane audit records for bucket, volume or snapshot creation events	Creation of storage resources in a region where the organization has no data residency approval or existing buckets	Audit trail export read by a cloud log collector, forwarded to Wazuh rules keyed on the creation API event name
Region enablement change	Account-level configuration history showing regions opened or closed	A region switched on without a matching change record or ticket	Configuration snapshot collected on a schedule and compared against an approved baseline file
Resource inventory by region	Scheduled inventory export listing every resource and its region	Resources present in a region outside the approved list, even if created before monitoring began	Inventory export parsed by a scheduled script into Wazuh or a dashboard in OpenSearch
Unsupported or unusual region API calls	Cloud audit log entries for calls that return region-not-enabled or region-not-supported errors	Repeated failed attempts against regions the organization does not use, which can indicate probing	Same audit pipeline as above, with a separate Sigma rule for error codes and source addresses

Detection logic for activity outside approved regions

Region-based detection works because T1535 Unused/Unsupported Cloud Regions depends on activity appearing where the organization does not normally operate. The cards below describe six ideas that combine an approved-region baseline with identity, resource and network signals, and each one needs tuning against the legitimate activity that also lands in unexpected regions.

Region allow-list baseline

Start by writing down which regions each account, subscription or project is approved to use, and who approved them. Compare control-plane events against that list and alert on any region that is not on it. The main tuning decision is the threshold for tolerated exceptions, such as a short window for a disaster recovery drill. Confirm with your cloud provider which events carry a region field, because some global services record their activity under a different region than the resource they manage.

First-seen region for an identity

Build a per-identity history of the regions each user, role or service principal has called before. Raise an alert when an identity makes its first call in a region it has never used, especially in a region the organization has never approved. Set a learning period long enough to cover normal work cycles, and review identities that run automation, since their first-seen regions often change when pipelines are updated.

Resource creation in a dormant region

Alert on creation of compute, database or container resources in regions where the organization has no running workloads. Dormant regions are the usual place for T1535 activity because few teams watch them. Set a tuning threshold on the number of creation events before paging, and suppress known infrastructure-as-code runs that intentionally create resources in a new region after an approved expansion.

Storage and network objects outside approved regions

Watch for new storage buckets, network connections and gateways created outside the approved list. Unexpected storage in a region is a common sign of data staging, and unexpected network paths show where traffic is routed. Tune by tagging approved resources at creation, so the rule can distinguish sanctioned objects from unknown ones, and expect false positives from managed services that create regional replicas automatically.

Sign-ins from new regions

Correlate identity provider sign-in logs with approved locations to find authentication from regions the workforce does not use. Set a threshold for how many distinct new regions in a short window should raise an alert, and exclude travel and remote-work patterns documented by HR or the identity team. Review service accounts separately, since they rarely sign in interactively and any new region is worth a check.

Disaster recovery and expansion false positives

Maintain a change calendar that records disaster recovery drills, approved regional expansions and migrations, and feed it into the suppression logic for every region-based rule. Drills often create resources, sign-ins and replicas in a secondary region within a short window. Ask each team to name the change ticket for their activity, and expire suppressions automatically so that an old exception does not hide later activity.

How region baselines and asset inventory make the detection work

A detection for T1535 Unused/Unsupported Cloud Regions only means something if the SOC knows which regions are approved for each account and workload. Without that reference, a resource created in a region nobody uses looks identical to a legitimate deployment in a new region the business has just approved. The region baseline is the list of approved regions per cloud account, subscription or project, and the asset inventory records which regions each workload is actually allowed to use. The approved list is an input the client owns. Business, data residency and legal teams should sign off on it, and DeployOpen helps document it so that the reasons for each approval are recorded alongside the list.

The baseline should feed the SIEM as an enrichment source, not as a static note in a wiki. In practice this means exporting the approved regions to a lookup table or reference index that the cloud audit events are joined against, so that a network connection creation, user account metadata change or cloud storage creation event carries an attribute such as an approved or unapproved region flag. Wazuh, Security Onion and similar open-source stacks can hold this data in lookup files or indexed reference records. Confirm with the chosen SIEM how lookups are refreshed, how often, and whether a failed refresh raises an alert, because a stale table quietly turns every new region into a false negative or a false positive.

Review the baseline on a fixed schedule and whenever the business changes, such as a new market, a new data residency commitment, an acquisition or a new managed service that is only offered in certain regions. Each change should add the region to the list with an owner, a reason and an expiry or review date. Cloud providers also add regions over time, and an approved list written for today will not include them. Decide in advance whether newly announced regions are approved by default, blocked by default or held for review, and record that decision as policy. The detection should alert on any region outside the list, so a new provider region is treated as unapproved until someone confirms it.

How to validate the T1535 detection in a lab

This sequence proves that a detection for resource creation in an unused cloud region fires reliably, with a known latency and a known false positive rate, before the rule is trusted in production. It turns a written detection idea into evidence a CISO or auditor can review.

Agree the validation scope in writing
The security lead, the cloud platform owner and DeployOpen agree in writing which cloud accounts, which approved and unused regions, which log sources and which alert destinations are in scope. The scope also names who may approve emulation activity and who receives alerts during the run. The step is done when the signed scope document lists these items and the rollback owner is named.
Build the test tenant with two regions
Build or allocate a test tenant or account that mirrors production logging, with one approved region the organization actively uses and one region it has no business reason to use. Confirm that the audit trail, identity metadata and storage creation events from both regions reach the Wazuh or Security Onion pipeline with the same field names as production. The step is done when a benign, pre-approved resource action in each region appears in the SIEM with complete fields.
Plan a controlled emulation with an approved identity
Document the emulation plan before execution: the test identity, the expected resource types, the target unused region, the time window and the expected telemetry from Network Connection Creation, User Account Metadata and Cloud Storage Creation. A cyber range operator approves the plan and confirms that the test identity is tagged so every event can be traced to this exercise. The step is done when the approved plan is filed with the scope document.
Run the emulation and confirm the alert
Execute the approved emulation under observation while an analyst watches the alert queue. Confirm that the rule raises an alert within the window defined in the detection design, and that the alert names the test identity, the region, and the account. The step is done when the alert is confirmed as fired, or when a missed detection is logged as a failed run for tuning.
Record timestamps, fields and enrichment
For each run, record the event timestamp, the alert timestamp, the detection latency, the fields present in the alert, and any enrichment such as account owner, asset tag or geolocation lookup. Compare the recorded fields against the detection specification to find gaps. The step is done when a run record exists with every field populated or marked as missing with a reason.
Measure false positives and analyst notes
Count the alerts from benign activity during the same window, such as scheduled jobs or approved deployments in the unused region, and classify each as a true or false positive. Capture analyst notes on triage time, unclear wording and missing context. The step is done when the run log shows the false positive count, the triage notes, and a reviewer sign-off.
Tune the rule and retest
Adjust the rule logic, enrichment or allow-list entries based on the recorded gaps and false positives, then repeat the emulation with the same plan. Compare results from the baseline run and the retest in a single table. The step is done when the retest meets the acceptance criteria agreed in the scope document, and the changed rule version is recorded against the ATT&CK version it targets.

Preventive controls that limit usable cloud regions

Most of the work against T1535 happens before an alert fires: deciding which regions are allowed and making that decision enforceable. The cards below cover the ATT&CK Software Configuration mitigation and the supporting controls that keep region restrictions from being quietly undone.

Restrict regions with provider policy

The ATT&CK mitigation Software Configuration covers settings in cloud platforms that limit what can be done and where. For T1535, the most direct form is a provider-level policy or organization-level guardrail that denies resource creation outside an approved region list. Confirm the exact mitigation ID for Software Configuration in the ATT&CK version you target, and confirm which of your provider's policy mechanisms apply to each account and subscription. Check that the approved list matches the regions your workloads actually need, and that regions your organization does not use are blocked by default.

Protect guardrails from change

A region restriction is only useful if the people and automation that can edit it are limited. Software Configuration controls should be paired with tight rights to modify organization policies, service control settings, and the identity roles that attach them. Review who can detach or override a guardrail, and alert on any change to it. Confirm with your provider which roles can alter these policies in your environment.

Audit region usage continuously

The ATT&CK mitigation Audit (M1047) supports T1535 by making region activity visible. Enable provider audit logs for resource creation and configuration changes in every account, and forward them to a central store. Review regions with activity that your inventory does not expect, and treat any new region appearing in logs as a finding to investigate. Confirm which audit log categories your provider records by default and which need explicit enablement.

Limit account privileges

The ATT&CK mitigation User Account Management (M1018) limits how many identities can create infrastructure in the first place. Assign build and deploy rights to named automation roles scoped to approved regions, and remove standing rights from unused or shared accounts. Review dormant accounts on a schedule, because an unused identity with broad rights can create resources in a region nobody monitors. Confirm how your provider scopes role conditions by region.

Guard privileged administrator access

The ATT&CK mitigation Privileged Account Management (M1026) applies to the accounts able to override region guardrails, which are usually the most privileged in the tenant. Require just-in-time elevation for those roles, record every session, and keep break-glass accounts out of routine use. Confirm whether your identity platform can record and alert on elevation to these roles, and document who approves a region exception.

Triage steps when a resource appears in an unused region

Start by confirming who created the resource and what it is. Pull the provider audit records for the creation event, including the calling identity, the source address, the user agent and the region, and match them against the region baseline and the change calendar. Treat the first question as whether the creating identity is one your team recognizes and expects to act in that region. If the identity is a service role, check which pipeline or automation assumed it and whether that pipeline has a documented reason to deploy outside approved regions. Record the resource type, resource identifier, creation time and any tags or owner fields, since those values anchor every later step. Confirm the event against the Network Connection Creation and Cloud Storage Creation records in your telemetry, because a new network path or storage bucket in an unused region is the usual evidence that something is running there.

Next, decide whether the activity was approved. Check the change record, the infrastructure-as-code repository and the planned change calendar for an entry that names the region, the account and the resource type. If nothing matches, do not assume an internal mistake until the creating identity's owner has been asked directly through a verified channel. Then establish what the resource could reach. Review whether the identity used credentials, keys or tokens that were issued for another region or workload, and whether any data was read, copied or written from the new resource. Use User Account Metadata records to see whether the identity was newly created, recently modified or granted new permissions shortly before the event. Each of these answers changes the severity, so write them down before containment.

Contain through the approved change path, not by ad hoc deletion. Where the identity is suspicious, restrict or disable it first, and revoke its active sessions and keys, so that the resource cannot be changed further while you investigate. Stop the resource only after you have captured its configuration, because deleting it removes evidence and can break a legitimate deployment. Preserve audit logs, flow logs and resource metadata into write-protected storage with a recorded chain of custody, and keep the copies outside the account being investigated. Escalate to incident response once unexpected data access, new credentials or a suspicious identity is confirmed. Afterward, record the identity, resource, region, timeline, approval status, data access findings, containment actions and root cause for the post-incident review. Feed the outcome back into the region baseline: approve the region if the change was legitimate, or add a detection rule and a preventive guardrail if it was not.

Rehearsing T1535 detection in a private cyber range

The range should behave like the client's cloud estate without touching it. A segmented cloud sandbox, with its own accounts or projects, lets the team create resources and sign in from different locations while keeping production logs separate. Mirrored logging matters most here: the control plane audit events, identity sign-in records and network flow records must reach the same SIEM the production team uses, so the detection is tested against the same data shape. The approved region list should be written down and loaded into the range as the baseline that every alert is measured against. Ask the range provider and your platform team to confirm which cloud audit, identity and flow logs are available for the chosen IaaS provider, and how long they are retained in the range.

Segmented sandbox: A dedicated account or project with no routes to production data.
Mirrored logging: Cloud audit, identity sign-in and flow logs forwarded to the range SIEM in their native format.
Approved region list: A written baseline of regions the organization uses, with the owner who can change it.
Open-source SIEM stack: Wazuh, Security Onion or a similar stack loaded with the Sigma rules under test.
Time synchronization: All sources aligned to one clock so event ordering is reliable.

Before the exercise, check that every source in the range produces the fields your detection logic needs, including region, identity and resource type.

Questions SOC leads ask about T1535 detection

How do we keep the approved region baseline current as the provider adds regions?

Treat the approved region list as a governed asset with a named owner, not a one-time setting. Store it in version control, tie each change to a request from the cloud platform or procurement team, and review it on a fixed schedule that your change process already uses. Ask the provider which regions are generally available, which are opt-in, and which services are restricted in each region, because a new region can appear in your account before anyone on the security side has reviewed it. Confirm in your own environment whether your cloud governance tooling can enforce region restrictions at the account or organization level, and whether those restrictions cover the global services your workloads depend on. Alerts should compare observed activity against this baseline, so a stale baseline produces either missed activity or noise.

How do we avoid alert fatigue from global cloud services?

Start by separating regional services from global ones and excluding the global control-plane activity that legitimately appears outside your primary regions. Identity, DNS, content delivery and some billing or support endpoints often report from locations that look unusual in a region-only view, so build an explicit allow list tied to named services rather than broad exclusions. Review each exclusion with the service owner and record why it exists and when it expires. Tune in stages: run the logic in a non-alerting mode first, measure how many events each rule raises, and only promote rules that point to something a human would act on. Confirm with your provider's documentation which services are global, since this varies by provider and changes over time.

How do we validate the detection without creating real risk?

Validate in a private cyber range or an isolated sandbox account that mirrors your logging and alerting pipeline, never in production. Use a scoped test identity with no access to live data, and pre-agree the test window, the expected alerts and the rollback steps with the cloud platform team. Record the telemetry each test produces, confirm the event reaches your SIEM with the expected fields, and check that the alert fires and routes to the right queue. Keep test evidence in a form an auditor could follow: the test plan, timestamps, detection rule version and the outcome. DeployOpen can plan and run this kind of exercise as part of a fixed-scope engagement, with the scope and rules of engagement agreed in writing before any activity begins.

How often should we re-check the T1535 mapping after an ATT&CK release?

Re-check the mapping after every ATT&CK release that your team adopts, because releases can rename, deprecate or revoke techniques and change the data components and detection strategies that a rule depends on. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so pin each detection to the version it was written against and record that version in the rule metadata. Compare the new version's technique page and the STIX bundle for your domain against your mapping, then note any changes in the detection log. Confirm your own release cadence with the team that owns your detection content, and decide in advance who approves a mapping change.

What should we do when the provider launches a new region?

Treat a new region as a change event with three steps. First, confirm whether the region is approved for your workloads and data classification; if it is not, make sure your preventive controls block resource creation there and that any attempt raises an alert. Second, confirm that your logging covers the new region, including whether your trail or flow log configuration is account-wide or per region, because some setups miss regions added later. Third, update the baseline and the rule allow lists so that legitimate activity in an approved region is not flagged. Ask the provider how it announces new regions and whether those announcements can feed your change tracking.

Which telemetry must we confirm before the T1535 rule can work?

Confirm that the three data sources the rule depends on are collected, normalized and retained for the regions you care about. Network connection creation records show where traffic originates and terminates. User account metadata shows which identities are active and what they are allowed to do. Cloud storage creation events show new buckets or containers that may be placed in unexpected regions. Check that each source reports a region field, that the field is parsed correctly in your SIEM, and that time synchronization across sources is reliable. Gaps in any one source weaken the rule, so run a coverage check before you rely on it. The exact event names differ by provider, so confirm them in your provider's audit log documentation.

Can our own team run this detection, or do we need outside help?

Many teams with an existing SIEM and cloud logging can build a first version of this detection in-house, provided they have someone who understands both the cloud provider's logs and the detection language they use. The work usually splits into four parts: building the baseline, writing and tuning the rules, validating them in a test environment, and keeping them current after releases. Gaps tend to appear in validation and in ongoing maintenance, because those steps need a safe test environment and a routine. Decide which parts you will own, and ask any partner to put the scope, deliverables and timeline in writing before work starts. DeployOpen works on a fixed-scope basis and offers retainers for continuous support if you want that help after the first version.

How DeployOpen builds T1535 detections and range scenarios

DeployOpen approaches T1535 Unused/Unsupported Cloud Regions as a fixed-scope engagement inside the client's own cloud accounts, starting from the telemetry the client already collects. The work turns that telemetry into tested detections and cyber range exercises that the client's own team can run and maintain.

How we scope

We confirm which IaaS accounts, regions and logging sources are in the written scope for T1535 coverage.
We record which cloud audit, network flow and storage creation events the client already collects and retains.
We agree in writing which ATT&CK version and mapped data components each detection will target before work starts.

How we build

We write detection logic for region activity in regions the client does not use, expressed as Sigma rules and Wazuh or Security Onion content.
We define baselines of approved regions so that alerts separate unexpected region use from normal provisioning.
We document the ATT&CK mitigation Software Configuration and the region controls that support it, including guardrails the client configures.

How we hand over

We deliver detection rules, tuning notes and test records mapped to the ATT&CK version named in the scope.
We provide cyber range scenarios that replay unused-region activity in a private environment so the client can rehearse response.
We train the client's security and platform staff to run the scenarios and review alerts without DeployOpen present.

How we support

Ongoing support, upgrades and continuous testing of the T1535 detections are available as a retainer.
We recheck detection mappings when MITRE publishes a new ATT&CK release, since releases can rename or revoke techniques.
We confirm with the client which evidence an independent auditor will need, since DeployOpen prepares evidence but does not issue assessments.

T1535 Unused/unsupported cloud regions