ATT&CK T1666 Modify Cloud Resource Hierarchy Guide

Cloud guardrails are inherited from the top of the resource hierarchy, so an attacker who can move, create or detach an account, subscription or project can step outside every guardrail without touching a single policy. MITRE ATT&CK T1666 Modify Cloud Resource Hierarchy describes adversaries adding, deleting or modifying resource groupings in IaaS environments to evade defences. In ATT&CK v20 it sits in the Defense Impairment tactic and applies to IaaS. ATT&CK gives three concrete forms: an AWS member account calling LeaveOrganization to shed its service control policies (SCPs), a new account created inside an organisation that is not yet covered by detections, and Azure subscription hijacking, where a subscription is transferred to an attacker-controlled tenant so its activity logs leave the victim's view. This guide covers the hierarchy operations that matter on AWS, Azure and Google Cloud, how to block them, how to detect them and how to respond. It is for cloud platform, cloud security and detection engineering teams. The policy engines themselves are covered in the AWS Organizations and SCPs Guide, the Azure Policy and Management Groups Guide and the Google Cloud Organization Policy Guide; this page focuses on the hierarchy itself as an attack surface. Platforms are listed alphabetically.

Key takeaways

The hierarchy is the control plane for your controls. SCPs, Azure Policy assignments and Google Cloud organisation policies all follow the hierarchy, so whoever can change the hierarchy can change which controls apply.
Leaving is worse than moving. AWS documents that an account that leaves an organisation is no longer subject to any organisation policies; an Azure subscription transferred to another tenant sends its activity logs to that tenant.
Prevention exists on all three platforms. An SCP denying organizations:LeaveOrganization, the Azure subscription policies for leaving and entering a directory, and the Google Cloud export and import constraints all block the common paths.
Hierarchy events are rare, so alert on every one. Account creation, moves, removals and subscription transfers happen a few times a month in most estates; each should match a change ticket.
The real precondition is a highly privileged identity. Global Administrator, the AWS management account and organisation-level Google Cloud roles are what make T1666 possible, so protect and monitor those first.

How the technique works across providers

Each provider groups resources into a tree and attaches policy, logging and billing to nodes in that tree. ATT&CK notes that hierarchical structures differ among providers: AWS groups accounts under an organisation, Azure groups subscriptions under management groups. The table summarises the hierarchy operations that change which controls apply.

Platform	Hierarchy unit	Operations that change control coverage	Effect on defenders
AWS	Organisation, root, organisational units (OUs), member accounts	`LeaveOrganization` (from the member), `RemoveAccountFromOrganization`, `MoveAccount` and `CreateAccount` (from the management account)	Leaving removes all organisation policies, including SCPs; a move to a less restricted OU changes inherited SCPs; a new account starts outside account-level detections until baselined
Azure	Tenant root group, management groups, subscriptions, resource groups	Subscription transfer to another Microsoft Entra directory, moving a subscription between management groups, creating subscriptions and management groups	A transferred subscription loses its role assignments and its activity logs route to the new tenant; a move between management groups changes inherited Azure Policy and role assignments
Google Cloud	Organisation, folders, projects	Moving a project between folders or migrating it to another organisation	Google documents that source constraints are replaced by destination constraints after migration, so inherited organisation policies change

Three patterns seen in the wild

Guardrail shedding (AWS): a principal in a member account with organizations:LeaveOrganization detaches the account. AWS states the account is then no longer subject to organisation policies, SCP restrictions are gone and users and roles may gain permissions. Prerequisites such as a support plan, verified contact details and a payment method slow this down for accounts created through Organizations, but they are not a control.
Shadow capacity (AWS and Azure): ATT&CK describes adversaries creating a new AWS account inside the organisation, which uses the organisation's payment method but may not be covered by existing detections, and a compromised Global Administrator creating new Azure subscriptions to deploy resources. The usual payload is compute for mining, which links this technique to the Cryptojacking Guide.
Subscription hijacking (Azure): Microsoft's threat hunting write-up describes attackers compromising a privileged user, inviting a guest from an attacker-controlled tenant, granting it rights on a pay-as-you-go subscription and transferring the subscription out. Transfer deletes the subscription's role assignments, billing can stay with the victim and the activity logs move to the attacker's tenant.

Prevention controls by platform

ATT&CK lists three mitigations for T1666: M1054 Software Configuration (block subscription transfers in Azure, deny LeaveOrganization with an SCP in AWS), M1018 User Account Management (limit who can add, delete or modify resource groups) and M1047 Audit (review the top of the hierarchy and keep workloads out of top-level accounts such as the AWS management account). The table turns those into platform settings.

Platform	Control	Setting or policy	Notes
AWS	Block self-removal	SCP with `"Effect": "Deny"` on `organizations:LeaveOrganization`, attached at the root	SCPs do not restrict the management account, and `RemoveAccountFromOrganization` is governed by management account permissions, so protect that account separately
AWS	Contain account creation and moves	Restrict `organizations:CreateAccount`, `MoveAccount` and `RemoveAccountFromOrganization` to a small set of break-glass and automation roles in the management account	AWS states `MoveAccount` can only be called from the management account and only between entities in the same root
AWS	Keep the management account empty	No workloads, no long-lived access keys, phishing-resistant MFA on the root user	Matches ATT&CK M1047; see the AWS Root Account Compromise Playbook
Azure	Block transfers out and in	Subscription policies Subscriptions leaving a Microsoft Entra ID directory and Subscriptions entering a Microsoft Entra ID directory set to Allow no users, with a short Exempted Users list	Microsoft documents that the default changed on 1 May 2026 to block transfers unless a global administrator allows them; tenants that set an explicit value earlier keep it, so check the current value
Azure	Control new management groups and default placement	Hierarchy settings `requireAuthorizationForGroupCreation` set to true and `defaultManagementGroup` pointing at a restricted landing group	Changing these needs `Microsoft.Management/managementgroups/settings/write` on the root management group (built-in role Hierarchy Settings Administrator)
Azure	Limit tenant-wide elevation	Monitor and remove Access management for Azure resources elevation, which assigns User Access Administrator at root scope	Only directly assigned global administrators can edit subscription policies, and only after elevating
Google Cloud	Block unapproved migration	`constraints/resourcemanager.allowedExportDestinations` on the source and `constraints/resourcemanager.allowedImportSources` on the destination	Both must allow the move, so leave them unset or tightly scoped outside approved migrations
Google Cloud	Limit movers	Grant `roles/resourcemanager.projectMover` only on specific folders, never at organisation level, and treat `roles/orgpolicy.policyAdmin` as privileged	Google's migration checklist lists these roles as required on source and destination

Detection: the events to watch

ATT&CK's v20 detection strategy for T1666 recommends monitoring calls such as LeaveOrganization, CreateAccount, MoveAccount and Azure subscription transfers, and correlating role elevation followed by hierarchy modification within a short window. Two log placement details decide whether you see anything at all.

AWS logs where the actor acts: AWS states that Organizations events appear only in US East (N. Virginia), and that CloudTrail logs an event in the account that took the action. A member account leaving is logged in the member account's trail, not the management account's, so an organisation trail that includes all member accounts is required. See the AWS CloudTrail Guide.
Azure logs may leave with the subscription: once a subscription is transferred, its activity logs route to the new tenant. Alert on the steps before the transfer (guest invitation, role grants, elevation) and keep a copy of activity and Microsoft Entra audit logs in a workspace the subscription does not control.

Signal	Source	Alert logic (our recommendation)	Severity
`LeaveOrganization` attempted (success or AccessDenied)	AWS CloudTrail, member account trail, us-east-1	Any occurrence; a denied attempt means the SCP worked and a principal is probing	Critical
`RemoveAccountFromOrganization`, `MoveAccount`, `CreateAccount`	AWS CloudTrail, management account trail	No matching change ticket, caller outside the automation role list, or a move toward a less restricted OU	High
Elevated access granted	Microsoft Entra audit logs, service Azure RBAC (Elevated Access)	Any elevation outside a planned window; Microsoft provides a Sentinel analytics rule template for this	High
Guest invited then promoted, then resource groups or VMs created	Microsoft Entra audit logs, Azure activity log, Defender for Cloud Apps	Sequence within hours, as in Microsoft's subscription hijacking hunting guidance	High
Subscription policy changed to Allow all users	Subscription policy settings and audit trail	Weekly configuration check plus alert on change	High
Project moved or migrated, or export/import constraint changed	Google Cloud Audit Logs (Admin Activity) at organisation level	Any project leaving the organisation; any change to the two resourcemanager constraints	High
Account, subscription or project missing from inventory	Daily hierarchy snapshot compared with yesterday	Count or membership drop without a ticket	Medium

Hierarchy changes rarely happen alone. ATT&CK groups T1666 with T1484 Domain or Tenant Policy Modification and T1578 Modify Cloud Compute Infrastructure in the cloud control-plane part of the ATT&CK Stealth and Defense Impairment Tactics Guide, and the follow-on is often instance launches or unusual spend. Pair hierarchy alerts with the signals in Cloud Cost Anomalies as Security Signals.

Implementing the controls safely

Inventory the hierarchy: export the full tree on each platform (OUs and accounts, management groups and subscriptions, folders and projects) with owners. Record which policies are inherited at each node.
Find who can change it: list every principal with organizations:* in the AWS management account, every directly assigned Global Administrator and holder of Hierarchy Settings Administrator in Azure, and every holder of projectMover, projectCreator or orgpolicy.policyAdmin in Google Cloud. Move standing access to just-in-time elevation; see the Privileged Identity Management (PIM) Guide.
Turn on detection first: deploy the alerts in the table above in alert-only mode for two weeks and confirm each fires in a sandbox (a test account move, a test elevation).
Apply preventive settings in a pilot: attach the deny LeaveOrganization SCP to a test OU, set the Azure subscription policies on a test tenant if you have one, and set the Google Cloud constraints on a test folder. Confirm approved automation still works.
Roll out at the top: attach at the AWS root, set the Azure policies tenant-wide, and set the Google Cloud constraints at organisation level.
Define the exception path: legitimate divestments and migrations need a ticket, a named approver, a time-boxed exemption (an Azure Exempted Users entry, a temporary SCP exception or a scoped constraint value) and removal afterwards.
Rollback: each control is a single policy object or setting. Detach the SCP, revert the subscription policy or restore the previous constraint value; keep the prior JSON or setting values in version control so rollback is a reviewed change.

Responding to a hierarchy change

Confirm intent within the hour: match the event to a change record and the named approver. No match means treat the caller identity as compromised.
Contain the identity: revoke sessions, remove role assignments and keys for the calling principal, and remove any Azure root-scope elevation. See the Protecting Cloud Control-Plane Recovery Accounts and Credentials guide for the break-glass accounts you will need.
Reverse the move where possible: re-invite a departed AWS account or move it back to its OU; for Azure, work with Microsoft support on a transferred subscription while preserving your Entra audit evidence; for Google Cloud, Google documents that the migration API can roll back a migration.
Look for what ran while controls were off: new regions, instances, IAM principals and access keys in the affected unit, using the MITRE ATT&CK T1535 Unused/Unsupported Cloud Regions checks.
Preserve evidence: CloudTrail records from both the member and management accounts, Entra audit and activity logs exported before transfer, and Google Cloud Admin Activity logs, with hashes and retention holds.

Decision guidance

Situation	Recommended approach (ours)	Trade-off
Small estate, one cloud, few accounts	Apply the preventive settings tenant-wide on day one and alert on every hierarchy event to one inbox	Occasional legitimate transfers need a manual exemption
Large multi-cloud estate with frequent account vending	Route account and project creation through a single vending pipeline identity; alert on any hierarchy call from any other caller	The vending identity becomes a high-value NHI: vault its credentials and monitor it closely
Mergers, acquisitions and divestments	Time-boxed exemptions per transfer, approved by two people, removed by an automated job	Slower deals, but every transfer leaves an approval record
Sandbox or student subscriptions in Azure	Place them under a dedicated management group with the strictest policy and monitor for transfers	Developers may need a request path for new sandboxes

Where identity fits

Every T1666 path starts with an identity that already holds hierarchy rights: a Global Administrator, a principal in the AWS management account, an automation role used for account vending, or a service account with projectMover. Automation roles are often the most privileged and least watched, so give each an owner, short-lived credentials and its own alert baseline. Guest accounts are the other route, as Microsoft's subscription hijacking analysis shows: restrict guest invitations and alert when a guest receives a subscription or directory role.

Measuring it

Coverage: share of AWS accounts under an OU with the deny LeaveOrganization SCP (target 100 per cent), Azure subscription policies set to Allow no users, Google Cloud organisations with export and import constraints set.
Privilege: number of standing identities able to change the hierarchy, per platform (target: a named handful, all just-in-time).
Ticket match rate: share of hierarchy events with a matching change record (target 100 per cent; every miss is investigated).
Time to triage: minutes from a hierarchy event to confirmed intent (target under 60).
Inventory drift: accounts, subscriptions or projects found outside the expected tree in the daily snapshot (target zero).

Common failure patterns

Organisation trail without member events: monitoring only the management account misses LeaveOrganization, which AWS logs in the member account.
Querying the wrong region: Organizations events appear only in US East (N. Virginia), so region-filtered dashboards show nothing.
Assuming the old Azure default: tenants that set Allow all users before May 2026 keep it; check the actual value rather than relying on the new default.
Workloads in the management account: SCPs do not apply there, so any foothold in it bypasses the deny SCP and can remove accounts directly.
Logs stored inside the unit that moves: an Azure subscription that keeps its only copy of activity logs leaves with them.
Broad mover roles: granting projectMover at organisation level so one compromised service account can move any project.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK v20	T1666 Modify Cloud Resource Hierarchy; mitigations M1054, M1018, M1047; v20 detection strategy	The technique, its mitigations and its detection analytic
MITRE ATT&CK v20	T1484, T1578, T1535, T1496	Neighbouring control-plane techniques and the usual impact
NIST SP 800-53 Rev. 5	AC-6 Least Privilege, CM-5 Access Restrictions for Change, CM-3 Configuration Change Control, AU-6 Audit Record Review, Analysis, and Reporting, SI-4 System Monitoring	Who can change the hierarchy, change approval, and monitoring of hierarchy events
NIST CSF 2.0	PR.AA-05, DE.CM-09	Access permissions managed with least privilege; computing environments monitored for adverse events

Practitioner checklist

Attach an SCP denying organizations:LeaveOrganization at the AWS organisation root.
Keep the AWS management account free of workloads and restrict CreateAccount, MoveAccount and RemoveAccountFromOrganization to named roles.
Confirm both Azure subscription policies read Allow no users, and review the Exempted Users list quarterly.
Set requireAuthorizationForGroupCreation and a restricted defaultManagementGroup in Azure.
Restrict Google Cloud project export and import with the two resourcemanager constraints and scope projectMover to folders.
Collect Organizations events from all member accounts in us-east-1 and alert on every hierarchy call.
Alert on Azure elevated access and on guest-to-privileged-role sequences; store Azure logs outside the subscriptions they describe.
Run a daily hierarchy snapshot diff and match every change to a ticket.

MITRE ATT&CK T1666 Modify Cloud Resource Hierarchy: Detecting and Blocking Guardrail Escapes