@blamejs/exceptd-skills 0.12.26 → 0.12.28

package/skills/cloud-iam-incident/skill.md

@@ -0,0 +1,419 @@
+---
+name: cloud-iam-incident
+version: "1.0.0"
+description: Cloud-IAM incident response for AWS / GCP / Azure — account takeover, IAM role assumption abuse, access-key compromise, cross-account assume-role chains, federated-trust attacks (IAM Identity Center / Workload Identity Federation / Azure managed identity), IMDS metadata exfiltration, and Snowflake-AA24-class IdP-to-cloud credential reuse
+triggers:
+  - cloud iam compromise
+  - aws account takeover
+  - gcp service account compromise
+  - azure managed identity replay
+  - cross account assume role
+  - federated trust abuse
+  - oidc trust policy
+  - workload identity federation
+  - iam access key leak
+  - cloudtrail anomaly
+  - imds metadata abuse
+  - imdsv1 ssrf
+  - scattered spider aws
+  - snowflake aa24
+  - aws sso compromise
+  - iam identity center
+  - crypto mining cloud
+  - access key public repo
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - attack-techniques.json
+  - framework-control-gaps.json
+  - global-frameworks.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+atlas_refs:
+  - AML.T0051
+attack_refs:
+  - T1078
+  - T1078.004
+  - T1098.001
+  - T1552.005
+  - T1580
+  - T1538
+framework_gaps:
+  - FedRAMP-IL5-IAM-Federated
+  - CISA-Snowflake-AA24-IdP-Cloud
+  - NIST-800-53-AC-2-Cross-Account
+  - ISO-27017-Cloud-IAM
+  - SOC2-CC6-Access-Key-Leak-Public-Repo
+  - AWS-Security-Hub-Coverage-Gap
+  - UK-CAF-B2-Cloud-IAM
+  - AU-ISM-1546-Cloud-Service-Account
+rfc_refs:
+  - RFC-8693
+  - RFC-7519
+  - RFC-8725
+  - RFC-9068
+cwe_refs:
+  - CWE-287
+  - CWE-522
+  - CWE-798
+  - CWE-863
+  - CWE-732
+  - CWE-269
+d3fend_refs:
+  - D3-MFA
+  - D3-CBAN
+  - D3-NTA
+  - D3-IOPR
+  - D3-CAA
+forward_watch:
+  - AWS IAM Identity Center session-policy refresh and step-up-on-admin enforcement (anticipated 2026-H2 release)
+  - GCP Workload Identity Federation principal-set attribute mapping tightening (post-2026 Q3 Federation hardening guide)
+  - Azure managed-identity continuous-access-evaluation rollout for cross-tenant trust scenarios
+  - CISA Snowflake AA24 follow-up advisories on IdP-to-cloud chained-compromise patterns (continuous 2025-2026)
+  - FedRAMP Rev 5 cloud-IAM control overlay; cross-IL trust patterns in IL6 sovereign cloud
+  - NIST 800-53 Rev 6 (anticipated 2027) Account Management chain-of-assumptions sub-control
+  - ISO/IEC 27017:2027 (anticipated) cloud-IAM hardening including managed-identity token-binding and IMDS hardening
+  - UK CAF v4 cloud-IAM specificity in B2 contributing outcomes
+  - AU ISM update enumerating cloud non-human-principal credential hygiene with explicit bearer-token TTL ceilings
+  - DORA TLPT (JC 2024/40 RTS) first-cycle aggregate findings on cloud-account-compromise scenarios
+  - AWS, GCP, and Azure shared-fate / shared-responsibility recalibration for federated-trust hygiene
+last_threat_review: "2026-05-15"
+---
+
+# Cloud IAM Incident Response (mid-2026)
+
+## Threat Context (mid-2026)
+
+Cloud-IAM compromise has been the dominant cloud-breach root cause across all three major hyperscalers (AWS, GCP, Azure) from 2024 through mid-2026. The threat surface has shifted materially since 2023 and the conventional defensive posture — Service Control Policies, root-account MFA, posture tools like AWS Security Hub / GCP Security Command Center / Azure Defender for Cloud, and quarterly access reviews — captures progressively less of the actual attack surface as adversary capability evolves.
+
+**Reference cases driving this skill.**
+
+1. **CISA Snowflake AA24-174A advisory (June 2024).** Stolen Okta / SSO credentials from a series of customer-environment infostealer infections were reused against the customers' Snowflake tenants. The same federated IdPs frequently held trust into the customer's AWS / Azure / GCP estate, enabling lateral movement from a Snowflake-scoped credential into the customer's cloud-IAM principal set. Reported impact: AT&T, Ticketmaster, Santander, Advance Auto Parts, Neiman Marcus, LendingTree, Pure Storage, plus dozens of unattributed downstream customers. The dominant cross-system vector — credential reuse across federated IdP downstream consumers — is not enumerated in any framework's evidence surface.
+
+2. **2024-2025 AWS-key-in-public-repo crypto-mining campaigns.** Scraper bots monitoring the GitHub firehose monetise within ~5 minutes of public exposure. Typical spend pattern: 50-500 USD/hour of GPU instances in an unused region (where the victim has no resources to alert on regional anomalies). Common compromise window: 30 minutes to 4 hours before the victim notices. Even after revocation, the attacker often establishes long-lived persistence by creating their own IAM user with AdministratorAccess inside the compromised account before the original key is revoked.
+
+3. **2026 Azure managed-identity token replay (CVE-2026-21370-adjacent class).** Attackers with limited code-execution on an Azure VM (often via SSRF in a hosted web application) steal the managed-identity token from the IMDS endpoint at 169.254.169.254. The token is valid for its TTL (default 24h on most managed-identity scopes) and can be replayed from the attacker's infrastructure. Azure Continuous Access Evaluation is the long-term mitigation; rollout is incomplete in most large estates.
+
+4. **Scattered Spider AWS-MFA-bypass via help-desk social engineering.** Continuous 2023-2026 pattern. Voice-cloned or socially-engineered help-desk agent resets MFA on a privileged user, attacker logs in, escalates via either (a) creating their own IAM user with AdministratorAccess for persistence, (b) directly assuming a privileged role into a production account, or (c) modifying the federated IdP trust policy to grant ongoing access. Help-desk OOB-callback policy + voice-channel deepfake-resistant verification is the operational mitigation; coverage is fragmentary.
+
+5. **IMDS v1 to v2 transition incidents.** AWS' guidance to migrate from IMDSv1 (unauthenticated) to IMDSv2 (session-token-required, hop-limit-bounded) has been published since 2019. Migration remains incomplete in most large estates as of mid-2026. SSRF-class vulnerabilities in instance-hosted web applications can read metadata-service tokens (T1552.005); IMDSv1 has no defence against this. GCP and Azure have analogous patterns but the threat surface is dominated by AWS due to install base.
+
+6. **Federated-trust attacks against IAM Identity Center / AWS SSO, GCP Workload Identity Federation, and Azure AD Conditional Access.** Three sub-patterns:
+   - **GitHub Actions OIDC wildcard subject claims** — an IAM role with a trust policy referencing `repo:owner/repo:*` (no branch/tag constraint) allows any fork-PR's workflow to assume the role. Documented as a class throughout 2024-2026; vendor-side mitigations (deploy-environment OIDC trust policies, AWS' suggested branch constraints) are unevenly adopted.
+   - **AWS SSO / IAM Identity Center misconfigured permission sets** granting Org-Admin via SAML assertion replay where the assertion is not cryptographically bound to the requesting session.
+   - **Azure AD application impersonation via expired-cert reuse** — applications with multiple certificates configured, where one cert has expired but is still trusted because rotation procedures didn't remove it.
+
+**Mid-2026 reality.** Any cloud-IAM compromise investigation must assume the following baseline by default:
+
+- Cross-account assume-role chains are the dominant lateral-movement primitive — not the historic case of compromised-host pivoting via SSH/RDP. AC-2-style account-lifecycle controls treat each assume-role event as a valid action; the compromise is the chain.
+- Federated trust is the dominant first-stage compromise vector when the customer has an IdP (Okta / Azure AD / Google Workspace / Auth0) integrated with the cloud account.
+- Managed identities and service-account access keys hold more operational privilege than human users in most IaC-managed estates. Human MFA is a 1-of-N control for the actual privilege surface.
+- Posture tools (Security Hub / SCC / Defender for Cloud) are coverage-based, not breach-detection. Their "all green" attestation has ~0 correlation with absence of behavioural anomalies.
+- IMDSv1 remains an active attack surface on instances that haven't migrated; IMDSv1 should be assumed reachable from any SSRF primitive.
+
+The playbook `cloud-iam-incident` operationalises this skill into a seven-phase investigation against a specific cloud account (or account-set), walking 90 days of audit log + current IAM principal inventory + federated trust configuration + SCP/Org-Policy/Management-Group state + recently-modified resource policies + billing-anomaly signal.
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Designed For | Fails Because |
+|---|---|---|---|
+| NIST 800-53 Rev 5 | AC-2 — Account Management | Establish, activate, modify, review, disable, and remove accounts | Lifecycle controls treat principals individually. Cross-account assume-role chains are valid AC-2-compliant actions individually; the compromise is the chain across boundaries, which AC-2 cannot see. Captured in `data/framework-control-gaps.json#NIST-800-53-AC-2-Cross-Account`. |
+| NIST 800-53 Rev 5 | AC-6 — Least Privilege | Principle-of-least-privilege application across roles and permissions | Static-analysis-shaped (Access Analyzer / Policy Analyzer flag overly-broad policies). Does not see principal-action behaviour that precedes a privileged action. |
+| ISO/IEC 27001:2022 | A.5.15 — Access Control | Rules for physical and logical access established and reviewed | Governs the access-rules baseline. Federated trust configurations (SAML / OIDC / Workload Identity Federation) are technically access rules but their security depends on claim-validation and trust-policy condition specificity that A.5.15 does not enumerate. |
+| ISO/IEC 27001:2022 | A.5.18 — Access Rights | Provision, review, and removal of access rights | Treats credentials as fungible. Federated IdP credentials and cloud-IAM credentials are reviewed independently. Cross-system credential-reuse compromise (CISA Snowflake AA24) is invisible. Captured in `data/framework-control-gaps.json#CISA-Snowflake-AA24-IdP-Cloud`. |
+| ISO/IEC 27001:2022 | A.5.23 — Cloud Services Information Security | Acquisition, use, management, and exit for cloud services | Generic cloud-services control. Provider-specific IAM constructs (cross-account role assumption, managed-identity tokens, IMDS access patterns) are not enumerated. Audit evidence is a cloud-provider risk assessment, not behavioural telemetry. |
+| ISO/IEC 27017 | Cloud-specific extension to A-controls | Cloud-services extension to ISO/IEC 27001 controls | Cloud-IAM extension lags on managed-identity token replay and IMDS hardening. Captured in `data/framework-control-gaps.json#ISO-27017-Cloud-IAM`. |
+| SOC 2 | CC6.1 — Logical Access Controls | Restrict logical access to data and system resources | Authentication-shaped. Treats the authenticated session as the access boundary. Leaked access keys produce fully-authenticated sessions; CC6.1 evidence is satisfied regardless of how the key reached the attacker. Captured in `data/framework-control-gaps.json#SOC2-CC6-Access-Key-Leak-Public-Repo`. |
+| SOC 2 | CC6.3 — Lifecycle Management | Manage access throughout the entire access lifecycle | Lifecycle-focused. Audit cadence is quarterly; the dominant cloud-IAM compromise window is hours-to-days. |
+| SOC 2 | CC7.2 — System Monitoring | Monitor system components for security events | Satisfied by posture-tool deployment. Does not verify that the monitoring system can see behavioural signals (cross-account chains, federated-trust anomalies). Captured in `data/framework-control-gaps.json#AWS-Security-Hub-Coverage-Gap`. |
+| FedRAMP IL5 | Baseline (AC-2, AC-3, AC-6, IA-2, IA-5) | US-Government Impact-Level 5 cloud workloads | Baseline assumes single-cloud-tenant deployment. IL6 sovereign-cloud federated-trust patterns and cross-IL trust policies are not contemplated. Captured in `data/framework-control-gaps.json#FedRAMP-IL5-IAM-Federated`. |
+| NIS2 | Art. 21(2)(d) — Supply Chain Security | Risk-management measures including supply-chain security and direct-supplier relationships | Names cloud-service providers as supply-chain dependencies but does not enumerate cloud-IAM trust-policy hygiene as a sub-control. |
+| DORA | Art. 6-9 — ICT Risk-Management Framework | Identify, protect, detect, respond, and recover for ICT risk | Principle-based. Cloud-IAM specifics are not enumerated in the binding articles; ESAs may publish Level-2/3 guidance over time. |
+| UK CAF | B2 — Identity and Access Control | Outcome that access to networks and information systems is controlled in line with the essential function's risk | Outcome-based on credential-lifecycle hygiene. Cloud-IAM specifics not enumerated against B2 evidence. Captured in `data/framework-control-gaps.json#UK-CAF-B2-Cloud-IAM`. |
+| AU Essential 8 | Strategy 4 — Multi-Factor Authentication (E8 M.4) | MFA on privileged and internet-facing accounts | Covers human-principal MFA. Cloud service-account access keys, OIDC federation tokens, and SAML assertions are bearer credentials that bypass MFA. |
+| AU ISM | ISM-1546 — MFA for privileged users and remote access | AU-government information-security baseline | Covers human-principal MFA. Cloud non-human principals out of scope. Captured in `data/framework-control-gaps.json#AU-ISM-1546-Cloud-Service-Account`. |
+| PCI DSS 4.0 | Req. 7-8 — Access Control + Identification | Access-control objectives generically | Cloud-IAM-specific requirements not enumerated. |
+| HIPAA | 164.312(a)(1) — Access Control | Technical safeguard for ePHI access | Generic access-control framing. Cloud-IAM specifics out of scope. |
+| AWS Security Hub | Foundational Security Best Practices | AWS-native posture tool | Coverage-based. Findings reflect configuration drift, not behavioural compromise. Captured in `data/framework-control-gaps.json#AWS-Security-Hub-Coverage-Gap`. |
+| GCP CIS | CIS GCP Foundations Benchmark | Posture baseline | Same shape as AWS Security Hub — coverage-based. |
+| Azure Security Benchmark | Azure-native posture baseline | Posture baseline | Same shape — coverage-based. |
+
+**Cross-jurisdiction posture.** Any multi-jurisdiction cloud-IAM incident must cite at minimum: EU GDPR Art. 33-34 (72h), NIS2 Art. 23 (24h early warning, 72h notification), DORA Art. 19 (4h initial, 72h follow-up) for financial entities; UK GDPR Art. 33 (72h) and UK CAF B2; US NYDFS 23 NYCRR 500.17 (72h cyber event); US-CA CCPA / CPRA (60 days) for California resident exposure; AU Privacy Act NDB scheme (30 days); JP APPI Art. 26 (24h immediate to PPC); SG PDPA s26D (72h); plus the CSP-specific incident-response engagement (AWS Health Dashboard support case, GCP support case at appropriate severity, Azure Service Health incident). US-only treatment (NYDFS, FFIEC, NIST CSF) is incomplete.
+
+---
+
+## TTP Mapping
+
+| Surface | TTP | Matrix | Variant in mid-2026 | Gap Flag |
+|---|---|---|---|---|
+| Stolen federated IdP credentials reused against cloud IAM | T1078 — Valid Accounts | ATT&CK Enterprise | Snowflake AA24 chain (Okta-to-Snowflake-to-AWS); infostealer-sourced session tokens | Captured in `data/framework-control-gaps.json#CISA-Snowflake-AA24-IdP-Cloud`. ISO A.5.18 treats credentials as fungible; cross-system reuse is invisible. CWE-287 + CWE-522. |
+| Cloud account credential abuse | T1078.004 — Valid Accounts: Cloud Accounts | ATT&CK Enterprise | Leaked access keys via public repository; managed-identity token replay; SAML assertion replay | Captured in `data/framework-control-gaps.json#SOC2-CC6-Access-Key-Leak-Public-Repo`. CC6.1 satisfied by authenticated session regardless of credential source. |
+| IAM-principal creation outside IaC for persistence | T1098.001 — Account Manipulation: Additional Cloud Credentials | ATT&CK Enterprise | CreateUser + CreateAccessKey in burst pattern; AssumeRole-and-grant-self-admin chain | NIST AC-2 records the event as compliant lifecycle action; AC-2 has no concept of "outside IaC" vs "inside IaC" baselining. Captured in `data/framework-control-gaps.json#NIST-800-53-AC-2-Cross-Account`. |
+| IMDS metadata-service exfiltration | T1552.005 — Unsecured Credentials: Cloud Instance Metadata API | ATT&CK Enterprise | IMDSv1 SSRF; Azure managed-identity token theft via IMDS; hop-limit bypass | Captured in `data/framework-control-gaps.json#ISO-27017-Cloud-IAM`. ISO/IEC 27017 cloud extension does not enumerate IMDS hardening. CWE-863. |
+| Cloud infrastructure discovery for follow-on action | T1580 — Cloud Infrastructure Discovery | ATT&CK Enterprise | Post-compromise listing of S3 buckets, KMS keys, EC2 instances, RDS instances; crypto-mining region selection | Visible in CloudTrail but typically high-noise. Behavioural anomaly (unused-region resource creation) is the high-signal variant. |
+| Cloud-service-dashboard discovery | T1538 — Cloud Service Dashboard | ATT&CK Enterprise | Post-compromise console-portal browsing to enumerate services + billing; cost-explorer queries to size the target | Console-login + dashboard-load events are recorded but rarely alerted. Combined with `root_login_from_new_asn` indicator. |
+| Cross-account assume-role chains | (No native TTP — closest T1078.004 chain) | ATT&CK Enterprise | Source principal compromise -> AssumeRole into target account -> further AssumeRole into prod -> KMS key policy self-grant | NIST AC-2 treats each link as compliant. Captured in `data/framework-control-gaps.json#NIST-800-53-AC-2-Cross-Account`. The chain is the compromise. |
+| Wildcard federated trust policy abuse | (No native TTP — closest T1078.004) | ATT&CK Enterprise | GitHub Actions OIDC role with `repo:*` subject claim; fork-PR-to-takeover | No framework enumerates trust-policy condition specificity as a sub-control. UK CAF B2 outcome treats this as "control specification"; AU ISM-1546 is silent. |
+| Crypto-mining workload deployment post-compromise | (No native TTP — closest T1580 + T1496) | ATT&CK Enterprise | GPU instance spike in unused region; outbound traffic to known mining-pool ASNs | Detectable via billing + region anomaly + GPU-instance-family selection. No framework enumerates billing anomaly as a security signal. |
+| Help-desk social engineering for MFA reset | (Social engineering — no MITRE TTP for the SE step itself; result T1078) | ATT&CK Enterprise | Voice-clone + impersonation of authorised user; SE'd help-desk agent resets MFA | OOB-callback policy + voice-channel deepfake-resistant verification is operational; coverage fragmentary. Companion skill `identity-assurance` for AAL/FAL framing. |
+| Audit-log disablement for defence evasion | (No precise mapping — closest T1562.008 Cloud Logs) | ATT&CK Enterprise | StopLogging / DeleteTrail / DiagnosticSettingsDelete; sink redirection to attacker-controlled bucket | Detected via meta-event firing on the disable action. Absence-is-evidence: any account with logging currently disabled is a finding regardless of an observable disable event. |
+
+**Note on TTP coverage.** ATT&CK Enterprise covers cloud-IAM compromise reasonably well at the technique level. The gap is the chain shape — multi-step cross-account chains are not represented as first-class objects in either ATT&CK or ATLAS. Detection-strategy support (ATT&CK DSxxxx) for cloud techniques improves with v18-v19 releases but lags behavioural-graph monitoring.
+
+---
+
+## Exploit Availability Matrix
+
+| Surface / CVE Class | CVSS | RWEP | CISA KEV | PoC Public | AI-Discovered | Active Exploitation | Patch / Mitigation Available | Sector-Aware Detection |
+|---|---|---|---|---|---|---|---|---|
+| CVE-2024-1709 ScreenConnect auth bypass (cloud-runtime adjacent) | 10.0 | 95 | Yes | Yes | n/a | Confirmed mass exploitation | Vendor patch | EDR + identity-protection |
+| CVE-2024-21626 runc container escape | 8.6 | 88 | Yes | Yes | n/a | Confirmed | Vendor patch | Container-runtime telemetry |
+| CVE-2024-3094 xz-utils supply-chain backdoor | 10.0 | 95 | Yes | Yes | Partially | Confirmed | Vendor patch | SBOM-driven detection |
+| CVE-2026-20182 Cisco SD-WAN cloud-edge | 9.1 | 90 | Yes | Yes | Yes | Confirmed | Vendor patch | Network telemetry |
+| CVE-2026-30623 Anthropic MCP STDIO (cloud-hosted MCP servers) | 8.4 | 87 | Pending | Yes | Yes | Suspected | Vendor patch + config hardening | MCP-aware telemetry |
+| Leaked access key in public repo (Snowflake-AA24-class) | n/a (config) | high (exploited within minutes) | n/a | Documented at scale | n/a | Confirmed mass exploitation | Configuration hardening + key rotation + scraper-bot countermeasures | GitGuardian / Trufflehog firehose; behavioural detection on CreateAccessKey + key-use anomaly |
+| IMDSv1 SSRF / metadata exfil | n/a (design class) | high | n/a | Documented at scale | n/a | Confirmed ongoing | IMDSv2 enforcement | VPC Flow Logs + CloudTrail Insights |
+| OIDC trust-policy wildcard subject claim (fork-PR-to-takeover) | n/a (config class) | high | n/a | Demonstrated 2024-2026 | n/a | Suspected ongoing | Trust-policy tightening + per-environment OIDC trust | Trust-policy static analysis + assume-role telemetry |
+| Cross-account assume-role chain | n/a (behavioural class) | risk-modelled, not CVSS | n/a | Demonstrated in red-team | n/a | Confirmed in IR data 2024-2026 | Mitigation only — cross-account chain monitoring, SCP tightening, external-id enforcement | CloudTrail graph analytics (rare) |
+| Azure managed-identity token replay | n/a (design class) | high | n/a | Demonstrated 2025-2026 | n/a | Confirmed | Continuous Access Evaluation rollout; token-binding | Azure Sentinel / Activity Log analytics |
+| Help-desk SE for MFA reset | n/a (social engineering) | high (Scattered Spider 2023-2026 reference) | n/a | Demonstrated at scale | n/a | Confirmed ongoing | OOB-callback + voice-channel deepfake-resistant verification | Identity-protection signals + help-desk audit log |
+| Crypto-mining post-compromise | n/a (consequence) | high (auto-monetised) | n/a | Documented at scale | n/a | Confirmed | Region SCP / Org Policy denies; billing alerting | Cost Explorer / Cost Anomaly Detection |
+| Audit-log disablement | n/a (defence evasion) | high | n/a | Documented | n/a | Confirmed | Org-level CloudTrail / Aggregated Sink that cannot be disabled by member accounts | Meta-event alerting |
+
+**Honest gap statement.** Vendor-specific CSP CVEs (AWS, GCP, Azure platform CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. CSP vulnerability disclosures are partial — providers historically remediate without CVE issuance under their shared-fate model. Authoritative sources: AWS Security Bulletins, GCP Vulnerability Reward Program publications, Azure Security Response Center, CSP-specific bug-bounty disclosures. Forward-watched.
+
+---
+
+## Analysis Procedure
+
+This procedure threads defense in depth, least privilege, and zero trust through every step. Pair it with the `cloud-iam-incident` playbook for the operational seven-phase walk.
+
+**Defense in depth.** Multi-layer authentication at every privilege boundary: AAL3 / FIDO2 device-bound passkey for human admins (skill `identity-assurance`); per-account SCP / Org Policy / Management Group denies; cross-account external-id on every assume-role trust; KMS / Cloud KMS / Key Vault key-policy least-privilege; resource-policy default-deny; network-layer segmentation (D3-NTA) between accounts and between zones; behavioural CloudTrail / Cloud Audit Log analytics (D3-IOPR) on top of posture tools; out-of-band confirmation on root-equivalent actions; help-desk OOB-callback for MFA resets.
+
+**Least privilege.** Per-principal scope; CWE-863 default-permissive role assignments are the dominant failing. External-id on every cross-account trust; non-wildcard subject claims on every federated OIDC trust; audience-pinned SAML; session-policy tightening on every AssumeRole / AssumeRoleWithSAML / AssumeRoleWithWebIdentity to scope-down beyond the role's permissions; KMS key-policy explicit-allow rather than IAM-policy-via-default-deny; managed-identity scope-token TTL ceilings (AGENTS.md cloud-IAM extension: <= 1 hour for non-CAE-enabled, <= 24 hours with CAE).
+
+**Zero trust.** Every action re-evaluated, not session-trusted; root / global-admin actions require step-up; cross-account assume-role chains monitored continuously; federated trust treated as untrusted-until-claim-validated; managed-identity tokens bound to instance identity where the CSP supports it; AI-channel egress (LLM API calls from instances) explicitly allowlisted on the administrative jump zone.
+
+### Step 1 — Baseline collection (always)
+
+Pull the 90-day audit log (CloudTrail / Cloud Audit Logs / Activity Logs) for every account in scope. Pull the current IAM principal inventory (users, roles, service accounts, managed identities, federated principals). Pull the federated IdP configuration. Pull SCP / Org Policy / Management Group state and recent change history. Pull recently-created access keys filtered to the last 90 days. Pull recently-modified resource policies. Pull 30-day billing data grouped by region + instance-family. Pull Access Analyzer / Policy Analyzer findings.
+
+If audit logging is disabled or short-retention on any account: emit `audit-log-coverage-gap` and the look phase is structurally incomplete on that account.
+
+### Step 2 — Indicator firing pass
+
+Run the ten indicators from the `cloud-iam-incident` playbook against the collected artifacts:
+
+- `root_login_from_new_asn`
+- `mass_iam_user_creation_outside_iac`
+- `unused_region_resource_creation`
+- `gpu_instance_creation_spike`
+- `iam_access_key_created_no_iac_ticket`
+- `cross_account_assume_role_anomaly`
+- `imds_v1_legacy_access`
+- `kms_key_policy_self_grant`
+- `s3_bucket_policy_public_grant`
+- `cloudtrail_logging_disabled_event`
+
+For each firing, run the indicator's `false_positive_checks_required` set. Do not let an indicator carry into the analyze phase without the FP checks completing.
+
+### Step 3 — Cross-account chain reconstruction
+
+If `cross_account_assume_role_anomaly` fires (or if any other indicator suggests cross-account reach), reconstruct the assume-role graph for the last 90 days. Walk from the suspected source principal through every successful AssumeRole / AssumeRoleWithSAML / AssumeRoleWithWebIdentity event. Identify chains traversing >= 2 account boundaries within a common 24h window. Cross-reference each hop's external-id against the documented integration inventory. Wildcard external-id or absent external-id on a multi-hop chain is the strongest distinguishing signal.
+
+### Step 4 — Federated-trust hygiene audit
+
+Audit every IAM role / service-account binding / Azure AD application with a federated trust policy. For each, validate:
+
+- Subject claim specificity (non-wildcard `repo:owner/repo:ref:refs/heads/main` rather than `repo:*`)
+- Audience constraint (pinned to per-integration value, not the default)
+- Signing-key rotation cadence (within documented policy)
+- MFA-required Conditional Access on federated admin sessions
+
+Document any role where the federated trust would allow a fork-PR / cross-tenant / unintended principal to assume.
+
+### Step 5 — IMDS posture audit
+
+Inventory all instances. For each, determine IMDS posture (v1-only, v2-available-but-v1-allowed, v2-required). Cross-reference against IMDS access patterns from VPC / NSG Flow Logs. Any instance with v2 available but v1 still allowed is a finding; any v1 access from a non-localhost source-IP is a higher-confidence finding.
+
+### Step 6 — Resource-policy diff against IaC baseline
+
+For every recently-modified resource policy (S3 bucket policy, KMS key policy, Lambda function policy, etc.), diff the modification against the IaC baseline (Terraform state / Pulumi state / CloudFormation drift / Bicep what-if). Any out-of-band change is a finding. KMS key-policy self-grant (the modifying principal is the same as the granted principal) is a high-confidence indicator.
+
+### Step 7 — Billing-anomaly cross-reference
+
+Cross-reference billing anomalies (GPU-instance spike, unused-region cost, egress spike) against the operator's documented workload inventory. Untagged spikes in regions outside the baseline are crypto-mining-shaped. Tag presence + ML-platform service-principal as creator demotes the indicator.
+
+### Step 8 — Snowflake-AA24-class cross-system check
+
+If the operator has any third-party IdP integrated with both downstream SaaS and the cloud (Okta, Azure AD, Google Workspace, Auth0): enumerate which SaaS systems honour the IdP AND which cloud-IAM trust policies honour the IdP. If a cross-system compromise of the IdP credential would reach both, document it as a chained-compromise exposure regardless of whether a current incident is in progress.
+
+### Step 9 — Compliance theater check
+
+Run the five theater tests in the dedicated section below.
+
+### Step 10 — Remediation orchestration
+
+Sequence remediation per the playbook's `remediation_paths`:
+
+1. Rotate root credentials and revoke sessions on every compromised account.
+2. Rotate every IAM access key reachable from the compromised principal.
+3. Audit IaC drift; quarantine compromised resources via deny-all SCP / Org Policy / deny-assignment.
+4. Review last 90 days of IAM events on every reachable account; revoke unrecognised cross-account trusts.
+5. Enforce IMDSv2 globally.
+6. Tighten federated trust (non-wildcard subject claims, audience pinning, MFA-required Conditional Access on admin).
+7. Rotate KMS keys with policy changes in the compromise window.
+
+### Step 11 — Multi-jurisdiction notification orchestration
+
+Time every regulator-notification clock from `detect_confirmed`: DORA Art. 19 (4h), NIS2 Art. 23 (24h), GDPR Art. 33 + UK GDPR Art. 33 (72h), NYDFS 23 NYCRR 500.17 (72h), APPI Art. 26 (24h), PDPA s26D (72h), AU NDB scheme (30 days), CCPA / CPRA (60 days for California residents). Pre-draft the notification text using the playbook's `notification_actions` templates and present them for operator review.
+
+### Step 12 — CSP-specific support engagement
+
+Open a CSP support case at the appropriate severity (AWS Health Dashboard support case at urgency Critical for confirmed compromise; GCP support case at P1; Azure Service Health incident). CSPs have IR-assist resources (AWS Customer Incident Response Team / GCP rapid response / Azure DART) that can be engaged for confirmed compromise.
+
+---
+
+## Output Format
+
+The output is the operator-facing cloud-IAM incident assessment. Every section is mandatory; missing data is reported as "no evidence" so absence is auditable. The audit-log coverage table anchors the entire assessment — gaps there propagate to every downstream finding as reduced confidence. Produce this structure verbatim:
+
+```
+## Cloud IAM Incident Assessment
+
+**Assessment Date:** YYYY-MM-DD
+**Account(s) in scope:** [list]
+**Cloud provider(s):** [AWS / GCP / Azure]
+**Regulatory exposure:** [EU GDPR / NIS2 / DORA / UK / NYDFS / AU / SG / JP / CA / ...]
+**Critical or important functions in scope:** [list per DORA / equivalent]
+
+### Audit-Log Coverage
+| Account | Audit-Log Enabled | Retention | Coverage Gap Notes |
+
+### IAM Principal Inventory
+| Account | Principal Class | Count | Long-Lived-Key Holders | MFA Coverage |
+
+### Federated Trust Posture
+| Trust Provider | Bound Account(s) | Subject-Claim Specificity | Audience Constraint | Signing-Key Rotation |
+
+### Indicator Firings (10-indicator pass)
+| Indicator | Account | Confidence | FP Checks Completed | Verdict |
+
+### Cross-Account Assume-Role Chains
+| Source Principal | Chain Length | Account Boundaries | External-ID Posture | Anomaly Verdict |
+
+### IMDS Posture
+| Account | Instance Count | IMDSv2-Required % | IMDSv1 Access Events |
+
+### Resource-Policy Modifications
+| Account | Resource | Modification Date | IaC-Baseline Match | Self-Grant |
+
+### Billing Anomalies
+| Account | Anomaly Type | Region | Magnitude | Tagged Workload |
+
+### Compliance Theater Findings
+[Outcome of the five tests in the Compliance Theater Check section]
+
+### Blast Radius Computation
+[Per-compromised-principal blast_radius score 1-5]
+
+### Defensive Countermeasure Plan (D3FEND)
+[D3-MFA, D3-CBAN, D3-NTA, D3-IOPR, D3-CAA — concrete control placements by account]
+
+### Priority Remediation Actions
+1. ...
+2. ...
+3. ...
+
+### Multi-Jurisdiction Notification SLA Matrix
+| Regulator | Window | Deadline | Notification Draft Status |
+
+### CSP Support Case Status
+| Provider | Case ID | Severity | Engaged IR Team |
+
+### RWEP-Prioritised CVE Exposure
+[Cloud-relevant CVEs ranked by RWEP from `data/cve-catalog.json`]
+```
+
+---
+
+## Compliance Theater Check
+
+Run all five tests. Any "fail" is a theater finding documented with the evidence (or absence thereof).
+
+**Theater Test 1 — "We have SCPs so compromise has bounded blast radius."**
+Ask: "Show me a 90-day inventory of cross-account assume-role events where the source principal was in an SCP-restricted account."
+
+- If the answer is "SCPs prevent any privilege escalation": SCPs constrain principals within an account but do not block cross-account assume-role chains initiated from a compromised principal in an account where the SCP allows broad role assumption. Count chains traversing >= 2 account boundaries within 24h of a single source principal — SCPs do not see this pattern.
+- Acceptable: SCPs combined with cross-account assume-role graph monitoring (rolling 24h windows), external-id enforcement on every cross-account trust, and behavioural CloudTrail analytics with the indicator set in this skill.
+
+**Theater Test 2 — "Root account has MFA so identity hygiene is complete."**
+Ask: "Inventory every IAM user, service account, managed identity, and federated principal with active long-lived access keys (last_used <= 90 days). For each, name the MFA posture on the underlying principal and the principal's last-used timestamp."
+
+- If the answer is "all root accounts have MFA": root MFA is a 1-of-N control. The dominant 2024-2026 compromise vectors target non-root principals (Snowflake-AA24-class), service accounts (no human MFA), federated principals (bearer-token-based, MFA already evaluated at the IdP), and managed identities (token-based, no human MFA). Root MFA covers 1 principal class out of many.
+- Acceptable: MFA posture documented across every human principal, bearer-token TTL ceilings on every non-human principal, federated-trust hygiene documented separately.
+
+**Theater Test 3 — "Security Hub / SCC / Defender for Cloud is all green so the account is secure."**
+Ask: "For each high-confidence indicator in the `cloud-iam-incident` playbook, name the Security Hub / SCC / Defender for Cloud control that would have fired had the indicator's behavioural signal been present."
+
+- If the answer is "Security Hub covers IAM hygiene with control set IAM.*": Security Hub controls are coverage-based (e.g. IAM.6 "Hardware MFA should be enabled for the root user"). They flag configuration drift, not behavioural compromise. A green posture score has ~0 correlation with absence of cross-account chains, federated-trust wildcard subject claims, or IMDSv1 SSRF.
+- Acceptable: posture tools deployed AND behavioural CloudTrail / audit-log analytics deployed AND coverage explicitly mapped against the indicator inventory in `cloud-iam-incident.detect.indicators`.
+
+**Theater Test 4 — "IAM Access Analyzer catches anomalous IAM grants."**
+Ask: "Compare 90 days of Access Analyzer / Policy Analyzer findings against 90 days of CloudTrail CreateAccessKey + AssumeRole + CreateUser events outside the documented IaC apply window. Any CreateAccessKey event that Access Analyzer did not surface — name it and explain why."
+
+- If the answer is "Access Analyzer covers IAM anomalies": Access Analyzer is a static-analysis tool that flags resource-policy reachability from external principals. It does not detect principal-action events (an attacker creating their own access key on a compromised user; an attacker assuming a role into a target account via legitimate SAML). The dominant 2024-2026 compromise vectors are principal-action-shaped, not resource-policy-shaped.
+- Acceptable: Access Analyzer plus a principal-action behavioural-anomaly layer (the indicator set in this skill), with documented evidence of coverage of both.
+
+**Theater Test 5 — "We use OIDC for CI so there are no static cloud credentials."**
+Ask: "Inventory every IAM role with a trust policy referencing token.actions.githubusercontent.com or the GitLab / CircleCI / Bitbucket equivalent. For each, name the subject claim, the audience constraint, and the action permissions."
+
+- If the answer is "OIDC federation means no static keys": OIDC eliminates static keys on the CI side but creates a federated-trust attack surface. Wildcard `repo:*` subject claims, missing branch / tag constraints, default `sts.amazonaws.com` audience — each is a fork-PR-to-takeover primitive that the "no static keys" attestation does not cover.
+- Acceptable: every federated trust policy uses non-wildcard subject claims with branch / tag constraints, audience pinned to per-integration value, and the policy reviewed at every Repository-add / CI-platform-migration event.
+
+---
+
+## Defensive Countermeasure Mapping
+
+Per AGENTS.md optional 8th section. Maps cloud-IAM offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
+
+| D3FEND ID | Technique | Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
+|---|---|---|---|---|---|
+| D3-MFA | Multi-Factor Authentication | Human-admin layer; help-desk MFA-reset gate | Per-principal MFA enrolment; phishing-resistant factors for any admin-equivalent principal | Step-up on root-equivalent action, AWS Organizations management actions, and AssumeRole into production accounts | Applicable to human principals. Service accounts / managed identities need scope-token + audience-binding constructs (not MFA). |
+| D3-CBAN | Credential-Based Authentication | API + management plane; access-key issuance and rotation | Per-credential scope (action + resource + time window); CWE-798 prohibition on hard-coded credentials | Credential issuance just-in-time where feasible (IAM Identity Center session policies, GCP impersonation tokens, Azure Just-In-Time access); rotation cadence per documented policy | Applicable. Bearer-token TTL ceilings on every non-human principal (<= 1h non-CAE, <= 24h with Continuous Access Evaluation). |
+| D3-NTA | Network Traffic Analysis | Inter-account / inter-zone boundary; IMDS metadata-service network; AI-API egress from administrative jump zones | Operator alerting scoped to operator's account / project / management group | Network-hostile-until-proven posture; IMDSv2 enforced; AI-API egress explicitly allowlisted | Applicable. AI-API egress monitoring from cloud-hosted workloads to LLM provider endpoints (OpenAI, Anthropic, Google) is a sub-control of DLP-aware NTA. |
+| D3-IOPR | Input / Output Pattern Recognition | CloudTrail / Cloud Audit Logs / Activity Logs analytics; behavioural-graph monitoring | Cross-account assume-role graphs over rolling 24h windows; IAM-mutation events outside IaC apply baselines; billing anomalies | Every behavioural pattern verified against historical norm and against adversary-known patterns | Critical. Behavioural-analytics on cloud-IAM is the primary defensive control gap in mid-2026. Posture tools do not provide this; D3-IOPR placement is required. |
+| D3-CAA | Credential and Access Analytics | Federated-trust-policy posture; cross-system credential-reuse mapping | Per-IdP downstream-consumer inventory; per-federated-role trust-policy condition specificity | Federated trust treated as untrusted-until-claim-validated; trust-policy condition specificity continuously attested | Applicable. Cross-system credential-reuse is the Snowflake-AA24-class vector; D3-CAA placement attests against this class. |
+
+**AI-pipeline-specific posture.** Cloud-hosted AI workloads (SageMaker, Vertex AI, Azure ML, plus self-hosted on EC2 / GCE / Azure VM) introduce three AI-specific attack surfaces:
+
+1. **AI-API egress from instances** — LLM API calls (OpenAI, Anthropic, Google) from cloud-hosted workloads provide a covert-channel C2 / exfil pathway. Skill `dlp-gap-analysis` covers the DLP framing; this skill covers the cloud-IAM framing — AI-API egress from administrative jump zones should be explicitly allowlisted or denied via SCP / Org Policy / NSG.
+
+2. **Managed-identity token use by AI workloads** — AI workloads that hold managed-identity tokens with broad access (data-access, ML-platform-write, etc.) are high-value targets for prompt-injection attacks that pivot through the workload's identity. Skill `ai-attack-surface` covers prompt-injection; this skill covers the cloud-IAM blast-radius framing.
+
+3. **AI-assistant generated IAM policies** — AI coding assistants increasingly generate IAM policies, often with overly-broad permissions (`Action: *` or `Resource: *`). This is a CWE-863 class issue at scale. Skill `mcp-agent-trust` covers MCP-side mitigation; this skill covers the cloud-IAM posture-tool detection requirement.
+
+---
+
+## Hand-Off / Related Skills
+
+After producing the cloud-IAM incident assessment, chain into the following skills.
+
+- **`cloud-security`** — for CSP-specific IAM construct inventory, posture-tool integration, and shared-responsibility framing. This skill scopes the IAM-incident-response workflow; `cloud-security` covers the broader cloud-posture surface.
+- **`cred-stores`** — for KMS / Cloud KMS / Key Vault posture, access-key rotation hygiene, and any compromised principal whose blast radius >= 4.
+- **`identity-assurance`** — for AAL / IAL / FAL framing on human-principal MFA posture, federated-identity assurance levels, and step-up authentication coverage on cloud admin actions.
+- **`framework-gap-analysis`** — for the per-jurisdiction reconciliation called for in Output Format "Cross-Jurisdiction Framework Gap Summary."
+- **`compliance-theater`** — to extend the five theater tests above with general-purpose theater detection across the wider GRC posture.
+- **`incident-response-playbook`** — for multi-jurisdiction notification orchestration and CSP-specific support-engagement workflow.
+- **`coordinated-vuln-disclosure`** — when the compromise involves a CSP-level vulnerability or an unpatched CVE in the compromised workload (e.g. ScreenConnect CVE-2024-1709 chained into cloud-IAM compromise).
+- **`policy-exception-gen`** — for defensible exceptions when cloud-IAM remediation cannot complete within obligation windows.
+- **`supply-chain-integrity`** — when the compromised account has published assets (npm / PyPI / Docker Hub / container registry write), the compromise chains into supply-chain blast assessment.
+- **`ai-attack-surface`** + **`mcp-agent-trust`** — when AI workloads or MCP servers are deployed in the compromised account.
+- **`dlp-gap-analysis`** — for AI-API egress controls and customer-data-exfil framing in cloud-hosted workloads.
+- **`sector-financial`** — for DORA Art. 19 (4h) notification orchestration when the compromise affects a financial entity's critical-or-important function.
+- **`sector-healthcare`** — for HIPAA breach notification when the compromise affects PHI.
+- **`sector-federal-government`** — for FedRAMP / FISMA framing when the compromise affects a US-government workload.
+
+**Forward watch.** AWS IAM Identity Center session-policy refresh and step-up-on-admin enforcement (anticipated 2026-H2); GCP Workload Identity Federation principal-set attribute mapping tightening (post-2026 Q3); Azure managed-identity continuous-access-evaluation rollout for cross-tenant trust; CISA Snowflake AA24 follow-up advisories; FedRAMP Rev 5 cloud-IAM control overlay; NIST 800-53 Rev 6 chain-of-assumptions sub-control (anticipated 2027); ISO/IEC 27017:2027 cloud-IAM hardening; UK CAF v4 cloud-IAM specificity in B2; AU ISM update enumerating cloud non-human-principal credential hygiene; DORA TLPT first-cycle aggregate findings on cloud-account-compromise scenarios; CSP shared-fate / shared-responsibility recalibration for federated-trust hygiene.