AWS Organizations Compromise: Hunting the Multi-Account Federation Attack

An attacker who compromises the right role in your AWS management account can pivot into every member account in the organisation — and most cloud SOCs do not have the cross-account telemetry stitching to see it happen.

AWS Organizations is the structural answer to multi-account governance at scale. It is also the structural target for an attacker seeking maximum blast radius from a single intrusion. One compromised management-account role can grant access to every member account.

Part 7 of the AWS Threat Hunting series, the final part of the series before the hub index, covers the four most-exploited multi-account compromise patterns and the cross-account hunt patterns that surface them.

01 · Why this hunt matters

Organization-level compromise is rare but catastrophic. The default management-account roles, the delegated-administrator pattern, and the cross-account AssumeRole chain are all designed for efficient operations — and the same efficiency makes them dangerous when an attacker steps onto the wrong identity.

02 · Adversary tradecraft

Pattern 01 — AssumeRole chain pivot

The attacker compromises an identity in account A. From A they assume a role in account B that account A has trust for. From B they continue to account C. The chain provides identity laundering — by the time activity is visible in C, the source IP and original identity have been obscured.

Pattern 02 — SCP bypass via management-account access

Service Control Policies restrict member accounts. If the attacker reaches the management account, they can modify or disable SCPs entirely — removing the governance layer for all member accounts.

Pattern 03 — Delegated administrator abuse

Member accounts can be delegated as administrators for specific services (GuardDuty, Security Hub, etc.). An attacker who compromises a delegated-admin account gains organisation-wide control over that service across all members.

Pattern 04 — SSO and identity-store abuse

If the organisation uses AWS SSO, the SSO identity store is a high-value target. An attacker who reaches it can create new SSO users with broad permissions and access every account through the SSO assignment graph.

03 · Telemetry needed

• Organization trail aggregating CloudTrail across all accounts.
• AssumeRole event correlation by request ID across accounts.
• SCP change events from the management account.
• SSO administrative event stream.

04 · Hunt queries

Hunt query 01 — Long AssumeRole chain

WITH role_chains AS (
  SELECT requestId, principal, sourceIPAddress, eventTime, awsRegion,
         responseElements.assumedRoleUser.arn AS assumed_arn
  FROM cloudtrail_logs
  WHERE eventName = 'AssumeRole'
    AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
)
SELECT a.principal, a.assumed_arn AS first_hop,
       b.assumed_arn AS second_hop,
       c.assumed_arn AS third_hop
FROM role_chains a
JOIN role_chains b ON b.principal = a.assumed_arn
                  AND b.eventTime BETWEEN a.eventTime AND a.eventTime + INTERVAL '30 minutes'
JOIN role_chains c ON c.principal = b.assumed_arn
                  AND c.eventTime BETWEEN b.eventTime AND b.eventTime + INTERVAL '30 minutes';

Hunt query 02 — SCP modification from management account

SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress,
       eventName, requestParameters
FROM cloudtrail_logs
WHERE eventSource = 'organizations.amazonaws.com'
  AND eventName IN ('UpdatePolicy', 'AttachPolicy', 'DetachPolicy',
                    'DisablePolicyType', 'DeletePolicy')
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14';

Hunt query 03 — SSO administrative actions outside change window

SELECT eventTime, userIdentity.arn AS principal, eventName
FROM cloudtrail_logs
WHERE eventSource = 'sso.amazonaws.com'
  AND eventName IN ('CreateUser', 'CreatePermissionSet', 'CreateAccountAssignment',
                    'AttachManagedPolicyToPermissionSet')
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
  AND (HOUR(CAST(eventTime AS TIMESTAMP)) < 6 OR HOUR(CAST(eventTime AS TIMESTAMP)) > 22);

05 · Sigma rule

title: AWS Service Control Policy Modification
id: b18c9d00-cd3e-4f45-da4b-5c6d7e8f9a0b
status: experimental
description: |
  Detects modification of AWS Organizations Service Control Policies —
  the governance layer that constrains member accounts.
author: HackForLab
date: 2026/06/16
references:
  - https://hackforlab.com/aws-multi-account-federation-attack-hunt-2026/
tags:
  - attack.defense_evasion
  - attack.t1562
  - attack.privilege_escalation
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: 'organizations.amazonaws.com'
    eventName:
      - 'UpdatePolicy'
      - 'AttachPolicy'
      - 'DetachPolicy'
      - 'DisablePolicyType'
      - 'DeletePolicy'
  filter_change_window:
    userIdentity.arn|expand: '%APPROVED_SCP_MODIFIERS%'
  condition: selection and not filter_change_window
fields:
  - userIdentity.arn
  - eventName
  - requestParameters
level: critical

06 · Ship as a production detection

The hard engineering step is the AssumeRole chain correlation. Use the requestId field to stitch events across accounts. Maintain a per-principal allowlist of authorised SCP modifiers and SSO administrators. Map detections to T1562 (Impair Defenses) and T1078.004 (Valid Accounts: Cloud Accounts). — or pull pre-mapped clusters from HuntIntel

07 · False-positive considerations

Legitimate cross-account operations (CI/CD deployment roles, audit roles) produce AssumeRole chains. Tune by allowlist. SCP modifications during change windows can be auto-suppressed if linked to approved tickets.

08 · Response actions

Response is organisation-wide. Immediately rotate session credentials for the affected principal across every account they have touched. Audit SCP and SSO changes in the last 30 days for unauthorised modifications. Engage cloud security leadership — organisation-level incidents require executive-level coordination. — Sign in to huntintel.hackforlab.com to pull the live catalogue and pivot on the cluster directly.

09 · FAQ