Detecting T1666 Modify cloud resource hierarchy

How T1666 modify cloud resource hierarchy weakens cloud defenses

An adversary who changes the cloud resource hierarchy can move an account or workload out from under the policies that were protecting it, and the change can look like routine administration. In MITRE ATT&CK, T1666 Modify Cloud Resource Hierarchy describes an adversary altering the structure that groups cloud accounts, projects, folders or subscriptions, so that inherited guardrails, logging rules or access policies no longer apply. For a SOC lead, the difficulty is that moving a resource between organizational containers resembles ordinary reorganization work, so the event often reaches a queue without any obvious security context. The practical question is whether your team can tell an approved restructuring from a move that removes protection.

At a high level, the adversary gains room to operate. Once a workload sits in a container without the security controls its former parent enforced, detection coverage, network restrictions and service control policies may stop applying to it. The technique appears in intrusions after an adversary already holds privileged cloud access, usually where it can reach the management plane. It sits under the Defense Impairment tactic (TA0112), which MITRE introduced in ATT&CK v19 when it split the Enterprise Defense Evasion tactic into Stealth (TA0005) and Defense Impairment. Defense Impairment covers actions that break the mechanisms defenders rely on to see and trust activity, so T1666 belongs with changes to logging, policy and tooling rather than with hiding individual files or processes.

Map your detections to ATT&CK version 20.0, which is the target version for the mappings on this page, and check the technique description, detection strategies and mitigations against that version before you rely on them. Confirm with your cloud provider which hierarchy operations are logged to your audit trail, how long those logs are retained and whether move events carry the actor identity and source you need. Decide in advance who may approve container moves, which roles can perform them and what evidence an approved change must carry, because those decisions define the baseline your analytics will compare against.

Which telemetry reveals T1666 on IaaS

This table maps each telemetry source that can reveal T1666 on IaaS to an open-source collection component and to the items the client must confirm in its own environment. Read it as a checklist: a signal is only useful if the audit trail is complete, the identity context is joined to it, and the provider event names are verified against vendor documentation before any rule is written.

Telemetry source	Open-source collection path	What to confirm in the client environment
Cloud service modification events from the provider audit trail	Cloud log forwarder into Wazuh or a SIEM pipeline, with Security Onion as an optional network-side correlation point	Audit logging is enabled in every account, subscription and project, and events for organizational structure changes reach the central store without gaps
Provider-specific event identifiers for hierarchy changes	Wazuh rules or Sigma rules mapped to the exported audit fields	Exact event names and parameters, confirmed with the IaaS vendor documentation rather than assumed from this page
Identity context for the acting principal	Identity provider logs forwarded to Wazuh, with the principal, session and source address retained	The acting identity can be traced to a named human, workload identity or automation role, and session identifiers are kept long enough for investigation
Administrative activity surrounding the change	Cloud control plane logs and configuration history collected alongside audit events	Related actions such as policy edits, role assignments or account moves can be ordered in time with the hierarchy change
Resource tagging and organizational metadata snapshots	Scheduled configuration export collected by a cloud log forwarder or inventory job	Snapshots exist at a known interval so that a before and after comparison of the account structure is possible
Endpoint or host telemetry on administrative workstations	Velociraptor or Wazuh agent collection on jump hosts and management endpoints	Administrative sessions used to make changes are logged, and the hosts performing them are covered by agents
Log integrity and retention controls	Wazuh archive storage or external object storage with write-once settings where available	Retention meets the client's own policy and any applicable compliance obligation, and log tampering alerts exist

Detection logic for hierarchy changes that bypass inherited controls

Hierarchy changes matter because policies, guardrails and access grants inherited from a parent container can disappear or change once a resource moves. The four detection ideas below work together: each catches a different part of the move, and the last one catches the follow-on changes that make the move useful to an attacker.

Alert on re-parenting operations

Every move of an account, project, subscription or folder to a new parent should produce a control plane audit event. Build a rule that fires on any move operation targeting production or security-scoped containers, and route it to the on-call queue rather than a weekly report. Confirm that your provider's audit log records the source and destination parent for each move, because the destination is what tells you whether inherited controls changed. Illustrative example: a move from a restricted folder to an open folder should always be reviewed.

Flag moves outside change windows

Approved reorganizations run inside a change calendar. Compare the timestamp of each move against the windows your change management process publishes, and treat any move outside them as high priority. Include weekends and holidays in the comparison, because attackers often choose quiet periods. Tune the window list with the change owners before enabling the alert so that the signal stays meaningful. Process data components such as File Modification are not needed here; the audit log timestamp and the change record are sufficient inputs.

Watch principals outside governance roles

Most accounts never move containers. Build a per-principal baseline of which identities have performed hierarchy operations over the last quarter, then alert on any identity outside that set. Pay special attention to service principals, CI roles and human accounts from business units that have no governance duty. Review the baseline with IAM owners, and remove standing rights that are not used. Confirm the role names that grant the move permission in your platform, since these differ between providers and versions.

Correlate moves with guardrail changes

A move becomes an impairment when it is followed by a policy, guardrail or permission change on the moved resource. Create a correlation rule that opens an incident when a hierarchy move is followed within a short, tuned window by changes to organization policy, service control settings, or role bindings on the same resource. Tune the window with your team, since the right value depends on how your pipelines run. Use Audit (M1047) to confirm that the policy-change events are logged at the same detail as the move events.

Baseline approved landing zone automation

Landing zone pipelines and infrastructure-as-code runs produce many legitimate moves, and they are the most common source of false positives. Register each pipeline's service identity, its expected source and destination parents, and its run schedule as an allow profile. Alerts should trigger when a pipeline moves a resource to a parent it has never used or outside its schedule. Ask your platform team to document each allow profile and review it after every landing zone change, so that the exception list does not quietly become a bypass.

Validate detections in a cyber range

Before relying on these rules, rehearse them in a private cyber range that mirrors your hierarchy design. Replay approved reorganizations, a pipeline run and a simulated unauthorized move, then record which alerts fired and how long triage took. Track the false positives produced by each allow profile and tune until the queue is manageable. Map each rule to the ATT&CK version you target, because releases can rename or deprecate techniques.

How to confirm the T1666 detection fires

This sequence proves, in a lab or private cyber range, that a hierarchy change on an IaaS account produces an audit event, that the event reaches the SIEM, and that the detection rule raises an alert with the fields an analyst needs. It also produces a written record of timings, gaps and tuning changes tied to the ATT&CK version under test.

Agree scope and rules of engagement
The security lead, the cloud platform owner and the SOC lead agree in writing which cloud accounts, organizational units or projects are in scope, which identities may make the approved change, when the exercise runs, and who can stop it. Confirm that the target is a non-production tenant or project, that no production identity or workload is reachable from it, and that the rollback path for the hierarchy change is documented before anyone touches the environment. The step is done when the signed scope sheet names the ATT&CK version under test, the owner of each account and the stop conditions.
Prepare the non-production tenant baseline
The cloud platform owner records the current resource hierarchy, including folders, organizational units or projects, parent relationships and the policies attached to them, and exports the audit configuration in place for the tenant. Logging for the relevant management plane is confirmed to be enabled and that the SIEM forwarder for that log source is healthy. The output is a dated baseline snapshot that the team can compare against after the exercise, so any drift is attributable to the test and not to normal administration.
Perform the approved hierarchy change
A named operator in the range, working under the agreed identity and change ticket, performs one approved modification to the resource hierarchy inside the non-production tenant, such as moving a test project under a different parent. The observer records the exact time, the identity used and the target object in the exercise log, without publishing any procedure beyond what the scope sheet allows. The step is complete when the change is confirmed in the cloud console or API inventory and the observer has written it down.
Confirm the audit event reaches the SIEM
The SOC analyst searches the SIEM for the management-plane audit record that corresponds to the change, matching on the timestamp, identity and target object from the exercise log. The check passes when the event is present, its ingestion latency is recorded, and the parsed fields match the raw record. If the event is missing or arrives with empty fields, the team stops, logs the gap and assigns a fix to the log pipeline owner before rerunning the step.
Check the detection rule fires
The detection engineer confirms that the rule mapped to Cloud Service Modification, along with any Sigma or native rule the team has adopted, evaluates the ingested event and generates an alert within the rule's schedule. The team records whether the rule fired on the first attempt, which logic branch matched and whether any other rule fired unexpectedly. Output is a rule-hit record that names the rule version and the ATT&CK version it targets.
Validate alert fields and analyst triage
The analyst reviews the generated alert and checks that it carries the actor identity, source address or session context where available, the target hierarchy object, the event time, the affected tenant or account and a link back to the raw record. The analyst then completes a triage note using the response runbook. The step is done when every required field is present or the missing ones are recorded as a tuning item, and the triage note is filed in the exercise record.
Record timings, gaps and tuning changes
The exercise lead compiles one report with the event time, ingestion time, rule evaluation time, alert time and triage time, plus every gap found and every tuning change made. Each finding is tagged with the ATT&CK version the team tested against, so later reruns after an ATT&CK release can be compared on equal terms. Because releases can rename, deprecate or revoke techniques, the report must state the version explicitly, and the rollback of the hierarchy change is confirmed and recorded before the report is closed.

Preventive controls that limit who can move cloud resources

Two ATT&CK mitigations carry most of the preventive load for T1666 Modify cloud resource hierarchy: Audit (M1047) and User Account Management (M1018). Audit makes hierarchy changes visible and attributable, while account management determines who can make them in the first place. Read together, they decide whether a change to folders, projects, subscriptions or organizational units is both blocked for most identities and recorded for the few that can make it.

Audit (M1047) keeps hierarchy changes visible

Audit means the cloud control plane records administrative events that move, create or re-parent resources, and that those records are retained and reviewed. For T1666, the questions are whether organization-level and tenant-level audit trails are enabled in every account, whether they cover the management plane where hierarchy changes happen, and whether logs are shipped to a store the workload administrators cannot edit. Confirm the event names, retention periods and log export options in your provider's audit documentation, since they differ by platform.

User Account Management (M1018) limits who can move

User Account Management covers how accounts and role assignments are created, granted and removed. For hierarchy changes, the key decision is which identities hold rights to create, move or delete folders, projects, subscriptions or organizational units, and whether those rights sit on people or on tightly scoped automation. Review governance roles at the top of the hierarchy, remove standing assignments that are no longer needed, and confirm that break-glass accounts are documented and monitored.

Separate hierarchy administration from workload roles

A common gap is an administrator who can both deploy workloads and reorganize the resource hierarchy. Splitting these duties means the team that runs applications cannot re-parent projects or detach them from policy inheritance. Map each governance role to a named owner, document who approves changes to the top-level structure, and test whether a workload administrator can still perform a hierarchy move. Any path that succeeds should be treated as a finding and recorded in the access review.

Protect the audit trail from the people it watches

An audit log only helps if an attacker who changes the hierarchy cannot also edit or disable the record of that change. Restrict who can modify logging configuration, send audit records to a separate account or tenant with write-once or restricted-delete settings where the platform supports it, and alert on any change to logging or export settings. Confirm with your platform documentation which roles can alter audit configuration, because some of those roles are broader than they first appear.

Review standing privilege on a fixed cadence

Standing privilege at the root of the hierarchy is the condition that makes T1666 most damaging. Schedule periodic reviews of who holds top-level administrative or governance roles, and require a documented reason and time limit for any elevated assignment. Where your platform offers just-in-time elevation, confirm that elevation events are also written to the audit trail. Record each review as evidence, including the removals it produced, so that a later assessor can see the control operating.

Triage and response when a hierarchy change alert fires

Start by deciding whether the hierarchy change was approved, because that decision drives everything after it. Compare the alert against your change records for the affected organization, folder or management group, and against the infrastructure-as-code plans that normally move accounts or projects. Identify the acting principal first: the human user, workload identity or automation role that issued the move, the source IP or network path, the user agent or client tool, and whether the session came from a known pipeline or an unfamiliar origin. Confirm the exact resource that moved, its previous parent and its new parent, and record the timestamps in the provider's audit log. Ask your cloud platform team to confirm which of these fields your provider exposes in its activity log, since field names and retention differ by provider.

Once the move is confirmed as unapproved, check what it changed beyond the moved resource. Hierarchies carry inherited policies, guardrails, tag-based access rules and billing or budget scopes, so review the effective policy set on the moved resource before and after the change. Look for newly attached or detached policies on the new parent, changes to organization-level guardrails, and any role assignments that now apply through inheritance. Then assess which workloads and data sit under different controls: a project moved out of a regulated folder may have lost logging, encryption or region restrictions even though its own settings look unchanged. Treat any inherited control loss as a separate incident item with its own owner. Containment should prioritize the principal and the evidence. Freeze the acting principal by disabling sign-in or revoking active sessions and tokens, and suspend its ability to move resources, while keeping its history intact. Revert unapproved moves only after you have captured the policy state, because reverting too early can erase the evidence needed to explain the change. Preserve the relevant audit logs in write-protected storage with a documented chain of custody, and export them to your SIEM. Escalate to the incident response lead and the data owner when regulated data is affected, and set a rule that compliance and legal are notified before any inherited control is restored or any account is deleted.

Rehearsing T1666 detection and response in a private cyber range

The range should mirror the cloud estate the organization actually runs, so that detections tuned in the lab carry over to production. For T1666 Modify Cloud Resource Hierarchy on IaaS, that means at least two isolated accounts or projects under a shared organizational structure, with the same logging, identity and policy controls that protect production. Logs from every account should flow into a central Wazuh, Security Onion or equivalent pipeline so that analysts see the same events they would see on a live incident. Exercise accounts should hold no production data and no live credentials.

Multi-account or multi-project topology: Build a small hierarchy with a root container, at least one child container and a second branch, so that moves between containers are possible and observable.
Mirrored audit logging: Enable the provider's organization-level audit trail and confirm that Cloud Service Modification events reach the central collector with the same field names used in production.
Identity separation: Give the exercise administrator, the platform engineer and the analyst separate identities, so that the source of each change is clear in the logs.
Known-good baseline: Record the hierarchy, attached policies and logging settings before the exercise, so that the team can measure what changed.
Isolation controls: Keep the range network separate from production and from any shared tooling that stores real credentials.

Confirm with the provider which hierarchy and audit features are available in your account tier, and agree the range build, exercise window and reset steps in the written scope.

Questions SOC leads ask about detecting T1666

How do we separate approved landing zone changes from suspicious hierarchy changes?

Separate them by who made the change, through which path, and whether it matches an approved change record. Approved landing zone changes normally come from a known infrastructure pipeline or service principal, run through reviewed code, and map to a ticket or pull request. Suspicious changes often come from an interactive identity, outside the pipeline, at an unusual hour, or against a folder, project or organization node that the platform team never touches. Build an allowlist of pipeline identities and approved change windows, then alert on anything that falls outside it. Confirm with your cloud provider exactly which audit events record moves, renames and policy-parent changes in your environment, because event names differ between platforms.

Are hierarchy events enough to detect T1666 without identity logs?

No. Hierarchy events tell you that a container was moved or restructured, but they rarely tell you who was behind the action on their own. Pair them with identity and sign-in telemetry so you can see the actor, the session origin, any recent role assignments and whether multi-factor authentication was satisfied. Without identity context, analysts can see the change but cannot judge intent quickly. Use the Cloud Service Modification data component as the anchor, then enrich each alert with the identity provider's sign-in logs and the cloud control plane's role assignment history. Confirm which identity logs your platform retains and for how long before you rely on them for investigations.

How do we keep detection mappings current across ATT&CK releases?

Pin every detection to the ATT&CK version it targets and record that version in the rule metadata. MITRE publishes ATT&CK content in STIX 2.1 format, one bundle per domain and version, so you can diff technique and mitigation references between releases. Recent releases include v18, v19 and v20, and releases can rename, deprecate or revoke techniques. Schedule a review after each release, compare the relevant technique entries against your Sigma rules and Wazuh or Security Onion mappings, and update the mapping only after the rule has been retested. Keep a changelog so auditors can see what changed and why.

How do we test for false positives before turning on hierarchy alerts?

Run the rule in alert-only mode against at least several weeks of historical audit logs, then review each hit with the platform team. Expect false positives from scheduled landing zone updates, account vending, migrations and disaster recovery drills. Tag each known activity with its pipeline identity, change ticket and expected window, then measure how many alerts remain unexplained. Only promote the rule to a paging alert when the unexplained volume is low enough that analysts can investigate each one. Document the tuning decisions so the rule's logic and exceptions can be reviewed during audits.

How often should we re-run the cyber range exercise for T1666?

Re-run it on a fixed schedule and after any material change to your cloud structure, identity model, logging pipeline or detection content. The schedule should match your change rate: an environment with frequent landing zone updates needs more frequent checks than a stable one. Each run should confirm that the expected audit events reach the SIEM, that the rule fires with the right fields, and that the response playbook is followed. Also re-run after each ATT&CK version update that touches this technique. Agree the cadence and scope in writing with your range provider so the exercise, its evidence and its owners are clear before work starts.

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

Your own team can run it if it has cloud platform administrators, a SOC analyst who knows the cloud audit logs, and someone who owns detection content. Most gaps appear in log coverage across accounts and projects, identity enrichment, and keeping the pipeline allowlist accurate as the hierarchy changes. DeployOpen implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, runs cyber ranges and security testing, and prepares evidence for compliance assessments. It does not issue audit reports or certifications. Ask for a fixed-scope written plan that names which detections, logs and exercises are included, and which remain with your team.

Where to verify T1666 and ATT&CK version details

Start by confirming how T1666 Modify cloud resource hierarchy is mapped in the ATT&CK version you are testing against. Open the official Defense Impairment tactic page for TA0112 and check whether the technique appears under that tactic in your target release. The tactic is new. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which uses ID TA0112. A detection or coverage report that still labels T1666 under Defense Evasion may carry the wrong tactic, and that matters when you report coverage by tactic to a board or an auditor.

Next, use the enterprise-attack 20.0 STIX bundle as the reference for what your detection depends on. The bundle holds one file per domain and version, so you can filter for the T1666 object and read its tactic references, its detection strategies, the data components those strategies cite, and its mitigation relationships. Confirm that the telemetry you plan to use, such as Cloud Service Modification, is named in that record, and confirm whether Audit (M1047) and User Account Management (M1018) are the mitigations linked to it. If the record cites data components that your cloud logging does not produce, log that gap before you build the rule.

Finally, tie every rule, test and range result to a named ATT&CK version. Record the version in the rule metadata, the cyber range runbook and the evidence pack, together with the exact bundle file you checked. Before each review, read the release notes for every version between the one you built against and the current one. The v18 notes describe the move to detection strategies with DET IDs and the deprecation of data sources, and the release notes for later versions can rename, deprecate or revoke techniques. Check the ATT&CK updates page for the current status of T1666 before you sign off.

How DeployOpen builds T1666 detections and cyber range scenarios

DeployOpen approaches T1666 Modify cloud resource hierarchy as a scoped engineering task inside the client's own cloud accounts or data centers. The work starts with the telemetry the client already collects, then builds and tests detections for IaaS hierarchy changes, and ends with documented handover and rehearsal in a private cyber range.

How we scope

Confirm which IaaS accounts, organizations and folders are in scope for hierarchy change monitoring.
Inventory which Cloud Service Modification events the client's cloud logging actually records today.
Agree in writing which ATT&CK version and mitigations, Audit and User Account Management, the detection targets.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Map the detection logic to the relevant ATT&CK detection strategy and analytics for the targeted version.
Build the rules in open-source tooling such as Wazuh or Sigma, deployed in the client's environment.
Test each rule against benign administrative changes to measure false positives before it is promoted.
Define the alert routing, enrichment fields and triage notes that analysts need for hierarchy changes.

How we hand over

Document the data sources, rule logic, known gaps and the ATT&CK version each detection targets.
Provide a validation procedure so the client can repeat the detection test after changes.
Deliver cyber range scenarios that rehearse detection and response for T1666 with the client's analysts.
Record evidence of controls for compliance readiness, noting that independent auditors issue any assessment.

How we support

Review detections when ATT&CK releases rename, deprecate or revoke techniques or detection strategies.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-run cyber range exercises after logging or cloud platform changes that affect hierarchy telemetry.
Confirm with the cloud provider which hierarchy change events are logged and retained in the client's tenancy.