Diagrams — Module S10: Cloud Red Team Harnesses

All Mermaid validated in Mermaid Live Editor. n8n JSON is structurally valid and importable.

Diagram 1 — Cloud Offensive Harness (n8n)

Type: n8n workflow (importable JSON) Purpose: The primary visual — the full cloud red team harness from scope configuration through kill-chain execution to client deliverable.

{
  "name": "S10 — Cloud Red Team Harness",
  "nodes": [
    { "name": "Scope Config", "type": "n8n-nodes-base.manualTrigger", "position": [200, 300], "notes": "Engagement scope file: account boundaries, region constraints, service exclusions" },
    { "name": "Scope Middleware", "type": "n8n-nodes-base.set", "position": [440, 300], "notes": "Every API call checked against scope before execution" },
    { "name": "Reconnaissance", "type": "n8n-nodes-base.executeCommand", "position": [680, 150], "notes": "Enumerate assets, identities, permissions via provider APIs. Prowler, ScoutSuite." },
    { "name": "Initial Access", "type": "n8n-nodes-base.set", "position": [680, 300], "notes": "Exposed service or compromised credential. Foothold identity." },
    { "name": "Privilege Escalation", "type": "n8n-nodes-base.set", "position": [920, 300], "notes": "Pacu iam__privesc_scan. Graph-based PE path finding (S10.2)." },
    { "name": "Lateral Movement", "type": "n8n-nodes-base.set", "position": [1160, 300], "notes": "Cross-account/cross-service via trust relationships" },
    { "name": "Impact (Demonstrated)", "type": "n8n-nodes-base.set", "position": [1400, 300], "notes": "Data access demonstrated (read-only proof), NOT exfiltration" },
    { "name": "Evidence Logger", "type": "n8n-nodes-base.set", "position": [920, 450], "notes": "Hash-chained evidence records. API call, response, timestamp, ARN." },
    { "name": "Client Report", "type": "n8n-nodes-base.set", "position": [1640, 300], "notes": "Exec summary, finding table, attack narrative, compliance mapping" }
  ],
  "connections": {
    "Scope Config": { "main": [[{ "node": "Scope Middleware", "type": "main", "index": 0 }]] },
    "Scope Middleware": { "main": [[{ "node": "Reconnaissance", "type": "main", "index": 0 }], [{ "node": "Initial Access", "type": "main", "index": 0 }]] },
    "Reconnaissance": { "main": [[{ "node": "Privilege Escalation", "type": "main", "index": 0 }]] },
    "Initial Access": { "main": [[{ "node": "Privilege Escalation", "type": "main", "index": 0 }]] },
    "Privilege Escalation": { "main": [[{ "node": "Lateral Movement", "type": "main", "index": 0 }]] },
    "Lateral Movement": { "main": [[{ "node": "Impact (Demonstrated)", "type": "main", "index": 0 }]] },
    "Impact (Demonstrated)": { "main": [[{ "node": "Client Report", "type": "main", "index": 0 }]] },
    "Reconnaissance": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] },
    "Privilege Escalation": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] },
    "Lateral Movement": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] },
    "Evidence Logger": { "main": [[{ "node": "Client Report", "type": "main", "index": 0 }]] }
  }
}

Reading the diagram: The engagement starts with the scope config — account boundaries, region constraints, service exclusions. Scope middleware intercepts every API call and checks it against the scope before execution; out-of-scope calls are blocked. The kill chain proceeds through Reconnaissance (enumerate assets and identities via API, using Prowler and ScoutSuite), Initial Access (foothold via exposed service or credential), Privilege Escalation (Pacu's privesc scan and graph-based path finding), Lateral Movement (cross-account/cross-service pivots), and demonstrated Impact (read-only proof of access, not actual exfiltration). Every phase logs to the evidence logger — hash-chained records of API calls, responses, timestamps, and resource ARNs. The client report is generated from the evidence store: executive summary, finding table with compliance mapping, attack narrative backed by evidence, and remediation roadmap.

Diagram 2 — Network Pentest vs Cloud Red Team Architecture

Type: Mermaid (flowchart) Purpose: Shows the structural difference between a network pentest harness and a cloud red team harness — why port scanning is irrelevant in the cloud.

flowchart LR
    subgraph NET["Network pentest (old)"]
        N1["Port scan<br/>nmap"] --> N2["Service enum<br/>httpx, nuclei"]
        N2 --> N3["Vuln exploit<br/>software weakness"]
        N3 --> N4["Shell / foothold"]
    end
    subgraph CLOUD["Cloud red team (new)"]
        C1["API enumeration<br/>ListBuckets, GetRole<br/>Prowler, ScoutSuite"]
        C2["Identity mapping<br/>IAM policies, trust<br/>relationships"]
        C3["IAM escalation<br/>PassRole chains<br/>Pacu privesc"]
        C4["Privileged access<br/>data, resources"]
        C1 --> C2 --> C3 --> C4
    end

    BOUNDARY_N["Attack surface:<br/>network (ports, hosts)"]
    BOUNDARY_C["Attack surface:<br>identity layer (IAM)"]

    BOUNDARY_N -.-> NET
    BOUNDARY_C -.-> CLOUD

    style NET fill:#2a0d0d,stroke:#a00000,color:#f08080
    style CLOUD fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style C1 fill:#14141f,stroke:#5eead4,color:#5eead4
    style C2 fill:#14141f,stroke:#5eead4,color:#5eead4
    style C3 fill:#14141f,stroke:#5eead4,color:#5eead4
    style C4 fill:#14141f,stroke:#5eead4,color:#5eead4
    style BOUNDARY_N fill:#2a1810,stroke:#a04000,color:#f0a868
    style BOUNDARY_C fill:#2a1810,stroke:#a04000,color:#f0a868

Reading the diagram: The network pentest (red, left) attacks the network boundary — port scan with nmap, service enumeration with httpx and nuclei, exploit a software vulnerability, get a shell. The attack surface is ports and hosts. The cloud red team (green, right) attacks the identity boundary — enumerate resources and identities via provider APIs (ListBuckets, GetRole), map IAM policies and trust relationships, escalate via PassRole chains and Pacu privesc, gain privileged access to data. The attack surface is IAM, not ports. Port scanning is irrelevant — an AWS account has no ports to scan. It has IAM policies to enumerate. The tool suite changes entirely: nmap/httpx/nuclei become Prowler/ScoutSuite/Pacu/Stormspotter.

Diagram 3 — The Cloud Kill Chain

Type: Mermaid (flowchart) Purpose: Shows the five phases of the cloud kill chain, each executed via API, with the tools and techniques at each phase.

flowchart TD
    RECON["RECONNAISSANCE<br/>Enumerate public assets,<br/>identities, permissions<br/>via provider APIs"]
    ACCESS["INITIAL ACCESS<br/>Exposed service vuln<br/>or compromised credential<br/>(leaked access key)"]
    PE["PRIVILEGE ESCALATION<br/>IAM abuse:<br/>PassRole, CreatePolicy,<br/>AttachRolePolicy, AssumeRole"]
    LATERAL["LATERAL MOVEMENT<br/>Cross-account via trust<br/>Cross-service via shared VPC<br/>Over-broad security groups"]
    IMPACT["IMPACT<br/>Data access (demonstrated)<br/>Resource exposure proof<br/>Persistence mapping"]

    RECON --> ACCESS --> PE --> LATERAL --> IMPACT

    TOOLS_R["Prowler, ScoutSuite<br/>ListBuckets, GetRole<br/>ListAttachedRolePolicies"]
    TOOLS_A["Credential validation<br/>Public endpoint probing"]
    TOOLS_P["Pacu iam__privesc_scan<br/>Stormspotter graph<br/>Graph-based path finding"]
    TOOLS_L["AssumeRole chains<br/>Trust policy enumeration"]
    TOOLS_I["GetObject proof<br/>(read-only, evidence-logged)"]

    RECON -.-> TOOLS_R
    ACCESS -.-> TOOLS_A
    PE -.-> TOOLS_P
    LATERAL -.-> TOOLS_L
    IMPACT -.-> TOOLS_I

    style RECON fill:#2a1810,stroke:#a04000,color:#f0a868
    style ACCESS fill:#2a1810,stroke:#a04000,color:#f0a868
    style PE fill:#14141f,stroke:#5eead4,color:#5eead4
    style LATERAL fill:#2a1810,stroke:#a04000,color:#f0a868
    style IMPACT fill:#2a0d0d,stroke:#a00000,color:#f08080
    style TOOLS_P fill:#0d1418,stroke:#1e8449,color:#82e0aa

Reading the diagram: The cloud kill chain proceeds through five phases. Reconnaissance: enumerate the target's public assets, identities, and permissions entirely through provider APIs — ListBuckets, GetRole, ListAttachedRolePolicies — using Prowler and ScoutSuite. No network scanning. Initial Access: gain a foothold via an exposed service vulnerability or a compromised credential (leaked access key, over-permissive service account token). Privilege Escalation (the core, highlighted teal): IAM abuse using Pacu's privesc scan and graph-based path finding — PassRole chains, CreatePolicy, AttachRolePolicy, AssumeRole. Lateral Movement: pivot cross-account via trust relationships and cross-service via shared VPCs or over-broad security groups. Impact: demonstrate data access (read-only proof, evidence-logged — NOT actual exfiltration), map resource exposure, identify persistence vectors. Each phase is API-driven and every call is scope-checked and evidence-logged.

Diagram 4 — IAM Privilege Escalation Graph

Type: Mermaid (flowchart) Purpose: Shows privilege escalation as graph traversal — from a starting identity's permissions to a target permission set, through escalation technique edges.

flowchart TD
    START["Starting Identity<br/>permissions: {lambda:CreateFunction,<br/>iam:PassRole, lambda:InvokeFunction}"]

    T1["Technique: PassRole + Lambda<br/>requires: PassRole,<br/>CreateFunction, InvokeFunction<br/>grants: execution-role-perms"]
    T2["Technique: CreatePolicy+Attach<br/>requires: CreatePolicy,<br/>AttachRolePolicy<br/>grants: full admin (*:*)"]
    T3["Technique: UpdateAssumeRolePolicy<br/>requires: UpdateAssumeRolePolicy<br/>grants: target-role-perms"]

    STATE1["State: has Lambda<br/>execution role perms<br/>(s3:GetObject, etc.)"]
    STATE2["State: full admin<br/>(*:*)"]
    STATE3["State: target role<br/>perms assumed"]

    TARGET["TARGET REACHED<br/>s3:GetObject on<br/>sensitive bucket<br/>OR *:* admin"]

    START --> T1 --> STATE1
    START --> T2 --> STATE2
    START --> T3 --> STATE3
    STATE1 --> TARGET
    STATE2 --> TARGET
    STATE3 --> TARGET

    style START fill:#2a1810,stroke:#a04000,color:#f0a868
    style T1 fill:#14141f,stroke:#5eead4,color:#5eead4
    style T2 fill:#14141f,stroke:#5eead4,color:#5eead4
    style T3 fill:#14141f,stroke:#5eead4,color:#5eead4
    style TARGET fill:#2a0d0d,stroke:#a00000,color:#f08080
    style STATE1 fill:#0d1418,stroke:#1e8449,color:#82e0aa
    style STATE2 fill:#0d1418,stroke:#1e8449,color:#82e0aa
    style STATE3 fill:#0d1418,stroke:#1e8449,color:#82e0aa

Reading the diagram: Privilege escalation is graph traversal. The starting identity (orange, top) has a set of permissions. The harness checks which escalation techniques are available — a technique is available when its required permissions are a subset of the current permissions. PassRole + Lambda requires PassRole, CreateFunction, and InvokeFunction; if the starting identity has all three, the technique is available and transitions to a state with the Lambda execution role's permissions. CreatePolicy + AttachRolePolicy grants full admin. UpdateAssumeRolePolicy grants the target role's permissions. Each transition is an edge in the privilege graph. The harness runs BFS from the starting permissions to the target (s3:GetObject on a sensitive bucket, or full admin). The output is the list of escalation chains — the exact sequence of techniques that would take an adversary from initial access to the target. The same graph-based reasoning as S09.2's attack-path analysis, applied to the IAM layer.

Diagram 5 — Evidence Schema to Compliance Mapping

Type: Mermaid (flowchart) Purpose: Shows how a cloud evidence record flows through the finding pipeline to a compliance-mapped client deliverable.

flowchart LR
    subgraph EVIDENCE["Cloud evidence record (hash-chained)"]
        E1["timestamp, account_id<br/>region, api_call"]
        E2["resource_arn, actor_arn<br/>request, response"]
        E3["scope_ref (authorization)<br/>previous_hash, record_hash"]
    end

    FINDING["Structured Finding<br/>type: iam_over_privilege<br/>severity: critical<br/>affected: Role-A"]
    MAPPING["Compliance Mapping"]
    REPORT["Client Deliverable"]

    subgraph MAPS["Framework controls"]
        SOC2["SOC 2: CC6.3<br/>access authorization"]
        ISO["ISO 27001: A.9.2.5<br/>access rights review"]
        PCI["PCI DSS: 7.2.1<br/>access control system"]
    end

    subgraph REPORTS["Report sections"]
        EXEC["Executive summary<br/>(risk + business impact)"]
        TABLE["Finding table<br/>(ID, severity, control)"]
        NARR["Attack narrative<br/>(backed by evidence)"]
        ROAD["Remediation roadmap<br/>(prioritized actions)"]
    end

    EVIDENCE --> FINDING --> MAPPING
    MAPPING --> SOC2
    MAPPING --> ISO
    MAPPING --> PCI
    SOC2 --> REPORT
    ISO --> REPORT
    PCI --> REPORT
    EVIDENCE --> NARR
    REPORT --> EXEC
    REPORT --> TABLE
    REPORT --> NARR
    REPORT --> ROAD

    style EVIDENCE fill:#14141f,stroke:#5eead4,color:#5eead4
    style MAPPING fill:#14141f,stroke:#5eead4,color:#5eead4
    style SOC2 fill:#0d1418,stroke:#1e8449,color:#82e0aa
    style ISO fill:#0d1418,stroke:#1e8449,color:#82e0aa
    style PCI fill:#0d1418,stroke:#1e8449,color:#82e0aa
    style REPORT fill:#0d2818,stroke:#1e8449,color:#82e0aa

Reading the diagram: The cloud evidence record (teal, left) captures every API action — timestamp, account, region, the exact API call, the resource ARN, who acted, the request and response, the scope reference that authorized it, and the hash chain that makes it tamper-evident. Evidence records roll up into structured findings: type (iam_over_privilege, public_exposure, escalation_path), severity, affected resource. The compliance mapping translates each finding type to framework controls — SOC 2 CC6.3 (access authorization), ISO 27001 A.9.2.5 (access rights review), PCI DSS 7.2.1 (access control system). The client deliverable (green, right) has four sections: executive summary (risk and business impact for the CISO), finding table (ID, severity, control mapping for tracking), attack narrative (step-by-step story backed by the evidence chain), and remediation roadmap (prioritized actions). The auditor does not need to understand iam:PassRole — they see SOC 2 CC6.3 at risk. That is what makes the deliverable client-ready.

# Diagrams — Module S10: Cloud Red Team Harnesses > All Mermaid validated in Mermaid Live Editor. n8n JSON is structurally valid and importable. --- ## Diagram 1 — Cloud Offensive Harness (n8n) **Type**: n8n workflow (importable JSON) **Purpose**: The primary visual — the full cloud red team harness from scope configuration through kill-chain execution to client deliverable. ```json { "name": "S10 — Cloud Red Team Harness", "nodes": [ { "name": "Scope Config", "type": "n8n-nodes-base.manualTrigger", "position": [200, 300], "notes": "Engagement scope file: account boundaries, region constraints, service exclusions" }, { "name": "Scope Middleware", "type": "n8n-nodes-base.set", "position": [440, 300], "notes": "Every API call checked against scope before execution" }, { "name": "Reconnaissance", "type": "n8n-nodes-base.executeCommand", "position": [680, 150], "notes": "Enumerate assets, identities, permissions via provider APIs. Prowler, ScoutSuite." }, { "name": "Initial Access", "type": "n8n-nodes-base.set", "position": [680, 300], "notes": "Exposed service or compromised credential. Foothold identity." }, { "name": "Privilege Escalation", "type": "n8n-nodes-base.set", "position": [920, 300], "notes": "Pacu iam__privesc_scan. Graph-based PE path finding (S10.2)." }, { "name": "Lateral Movement", "type": "n8n-nodes-base.set", "position": [1160, 300], "notes": "Cross-account/cross-service via trust relationships" }, { "name": "Impact (Demonstrated)", "type": "n8n-nodes-base.set", "position": [1400, 300], "notes": "Data access demonstrated (read-only proof), NOT exfiltration" }, { "name": "Evidence Logger", "type": "n8n-nodes-base.set", "position": [920, 450], "notes": "Hash-chained evidence records. API call, response, timestamp, ARN." }, { "name": "Client Report", "type": "n8n-nodes-base.set", "position": [1640, 300], "notes": "Exec summary, finding table, attack narrative, compliance mapping" } ], "connections": { "Scope Config": { "main": [[{ "node": "Scope Middleware", "type": "main", "index": 0 }]] }, "Scope Middleware": { "main": [[{ "node": "Reconnaissance", "type": "main", "index": 0 }], [{ "node": "Initial Access", "type": "main", "index": 0 }]] }, "Reconnaissance": { "main": [[{ "node": "Privilege Escalation", "type": "main", "index": 0 }]] }, "Initial Access": { "main": [[{ "node": "Privilege Escalation", "type": "main", "index": 0 }]] }, "Privilege Escalation": { "main": [[{ "node": "Lateral Movement", "type": "main", "index": 0 }]] }, "Lateral Movement": { "main": [[{ "node": "Impact (Demonstrated)", "type": "main", "index": 0 }]] }, "Impact (Demonstrated)": { "main": [[{ "node": "Client Report", "type": "main", "index": 0 }]] }, "Reconnaissance": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] }, "Privilege Escalation": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] }, "Lateral Movement": { "main": [[{ "node": "Evidence Logger", "type": "main", "index": 0 }]] }, "Evidence Logger": { "main": [[{ "node": "Client Report", "type": "main", "index": 0 }]] } } } ``` **Reading the diagram**: The engagement starts with the scope config — account boundaries, region constraints, service exclusions. Scope middleware intercepts every API call and checks it against the scope before execution; out-of-scope calls are blocked. The kill chain proceeds through Reconnaissance (enumerate assets and identities via API, using Prowler and ScoutSuite), Initial Access (foothold via exposed service or credential), Privilege Escalation (Pacu's privesc scan and graph-based path finding), Lateral Movement (cross-account/cross-service pivots), and demonstrated Impact (read-only proof of access, not actual exfiltration). Every phase logs to the evidence logger — hash-chained records of API calls, responses, timestamps, and resource ARNs. The client report is generated from the evidence store: executive summary, finding table with compliance mapping, attack narrative backed by evidence, and remediation roadmap. --- ## Diagram 2 — Network Pentest vs Cloud Red Team Architecture **Type**: Mermaid (flowchart) **Purpose**: Shows the structural difference between a network pentest harness and a cloud red team harness — why port scanning is irrelevant in the cloud. ```mermaid flowchart LR subgraph NET["Network pentest (old)"] N1["Port scan nmap"] --> N2["Service enum httpx, nuclei"] N2 --> N3["Vuln exploit software weakness"] N3 --> N4["Shell / foothold"] end subgraph CLOUD["Cloud red team (new)"] C1["API enumeration ListBuckets, GetRole Prowler, ScoutSuite"] C2["Identity mapping IAM policies, trust relationships"] C3["IAM escalation PassRole chains Pacu privesc"] C4["Privileged access data, resources"] C1 --> C2 --> C3 --> C4 end BOUNDARY_N["Attack surface: network (ports, hosts)"] BOUNDARY_C["Attack surface: identity layer (IAM)"] BOUNDARY_N -.-> NET BOUNDARY_C -.-> CLOUD style NET fill:#2a0d0d,stroke:#a00000,color:#f08080 style CLOUD fill:#0d2818,stroke:#1e8449,color:#82e0aa style C1 fill:#14141f,stroke:#5eead4,color:#5eead4 style C2 fill:#14141f,stroke:#5eead4,color:#5eead4 style C3 fill:#14141f,stroke:#5eead4,color:#5eead4 style C4 fill:#14141f,stroke:#5eead4,color:#5eead4 style BOUNDARY_N fill:#2a1810,stroke:#a04000,color:#f0a868 style BOUNDARY_C fill:#2a1810,stroke:#a04000,color:#f0a868 ``` **Reading the diagram**: The network pentest (red, left) attacks the network boundary — port scan with nmap, service enumeration with httpx and nuclei, exploit a software vulnerability, get a shell. The attack surface is ports and hosts. The cloud red team (green, right) attacks the identity boundary — enumerate resources and identities via provider APIs (ListBuckets, GetRole), map IAM policies and trust relationships, escalate via PassRole chains and Pacu privesc, gain privileged access to data. The attack surface is IAM, not ports. Port scanning is irrelevant — an AWS account has no ports to scan. It has IAM policies to enumerate. The tool suite changes entirely: nmap/httpx/nuclei become Prowler/ScoutSuite/Pacu/Stormspotter. --- ## Diagram 3 — The Cloud Kill Chain **Type**: Mermaid (flowchart) **Purpose**: Shows the five phases of the cloud kill chain, each executed via API, with the tools and techniques at each phase. ```mermaid flowchart TD RECON["RECONNAISSANCE Enumerate public assets, identities, permissions via provider APIs"] ACCESS["INITIAL ACCESS Exposed service vuln or compromised credential (leaked access key)"] PE["PRIVILEGE ESCALATION IAM abuse: PassRole, CreatePolicy, AttachRolePolicy, AssumeRole"] LATERAL["LATERAL MOVEMENT Cross-account via trust Cross-service via shared VPC Over-broad security groups"] IMPACT["IMPACT Data access (demonstrated) Resource exposure proof Persistence mapping"] RECON --> ACCESS --> PE --> LATERAL --> IMPACT TOOLS_R["Prowler, ScoutSuite ListBuckets, GetRole ListAttachedRolePolicies"] TOOLS_A["Credential validation Public endpoint probing"] TOOLS_P["Pacu iam__privesc_scan Stormspotter graph Graph-based path finding"] TOOLS_L["AssumeRole chains Trust policy enumeration"] TOOLS_I["GetObject proof (read-only, evidence-logged)"] RECON -.-> TOOLS_R ACCESS -.-> TOOLS_A PE -.-> TOOLS_P LATERAL -.-> TOOLS_L IMPACT -.-> TOOLS_I style RECON fill:#2a1810,stroke:#a04000,color:#f0a868 style ACCESS fill:#2a1810,stroke:#a04000,color:#f0a868 style PE fill:#14141f,stroke:#5eead4,color:#5eead4 style LATERAL fill:#2a1810,stroke:#a04000,color:#f0a868 style IMPACT fill:#2a0d0d,stroke:#a00000,color:#f08080 style TOOLS_P fill:#0d1418,stroke:#1e8449,color:#82e0aa ``` **Reading the diagram**: The cloud kill chain proceeds through five phases. Reconnaissance: enumerate the target's public assets, identities, and permissions entirely through provider APIs — ListBuckets, GetRole, ListAttachedRolePolicies — using Prowler and ScoutSuite. No network scanning. Initial Access: gain a foothold via an exposed service vulnerability or a compromised credential (leaked access key, over-permissive service account token). Privilege Escalation (the core, highlighted teal): IAM abuse using Pacu's privesc scan and graph-based path finding — PassRole chains, CreatePolicy, AttachRolePolicy, AssumeRole. Lateral Movement: pivot cross-account via trust relationships and cross-service via shared VPCs or over-broad security groups. Impact: demonstrate data access (read-only proof, evidence-logged — NOT actual exfiltration), map resource exposure, identify persistence vectors. Each phase is API-driven and every call is scope-checked and evidence-logged. --- ## Diagram 4 — IAM Privilege Escalation Graph **Type**: Mermaid (flowchart) **Purpose**: Shows privilege escalation as graph traversal — from a starting identity's permissions to a target permission set, through escalation technique edges. ```mermaid flowchart TD START["Starting Identity permissions: {lambda:CreateFunction, iam:PassRole, lambda:InvokeFunction}"] T1["Technique: PassRole + Lambda requires: PassRole, CreateFunction, InvokeFunction grants: execution-role-perms"] T2["Technique: CreatePolicy+Attach requires: CreatePolicy, AttachRolePolicy grants: full admin (*:*)"] T3["Technique: UpdateAssumeRolePolicy requires: UpdateAssumeRolePolicy grants: target-role-perms"] STATE1["State: has Lambda execution role perms (s3:GetObject, etc.)"] STATE2["State: full admin (*:*)"] STATE3["State: target role perms assumed"] TARGET["TARGET REACHED s3:GetObject on sensitive bucket OR *:* admin"] START --> T1 --> STATE1 START --> T2 --> STATE2 START --> T3 --> STATE3 STATE1 --> TARGET STATE2 --> TARGET STATE3 --> TARGET style START fill:#2a1810,stroke:#a04000,color:#f0a868 style T1 fill:#14141f,stroke:#5eead4,color:#5eead4 style T2 fill:#14141f,stroke:#5eead4,color:#5eead4 style T3 fill:#14141f,stroke:#5eead4,color:#5eead4 style TARGET fill:#2a0d0d,stroke:#a00000,color:#f08080 style STATE1 fill:#0d1418,stroke:#1e8449,color:#82e0aa style STATE2 fill:#0d1418,stroke:#1e8449,color:#82e0aa style STATE3 fill:#0d1418,stroke:#1e8449,color:#82e0aa ``` **Reading the diagram**: Privilege escalation is graph traversal. The starting identity (orange, top) has a set of permissions. The harness checks which escalation techniques are available — a technique is available when its required permissions are a subset of the current permissions. PassRole + Lambda requires PassRole, CreateFunction, and InvokeFunction; if the starting identity has all three, the technique is available and transitions to a state with the Lambda execution role's permissions. CreatePolicy + AttachRolePolicy grants full admin. UpdateAssumeRolePolicy grants the target role's permissions. Each transition is an edge in the privilege graph. The harness runs BFS from the starting permissions to the target (s3:GetObject on a sensitive bucket, or full admin). The output is the list of escalation chains — the exact sequence of techniques that would take an adversary from initial access to the target. The same graph-based reasoning as S09.2's attack-path analysis, applied to the IAM layer. --- ## Diagram 5 — Evidence Schema to Compliance Mapping **Type**: Mermaid (flowchart) **Purpose**: Shows how a cloud evidence record flows through the finding pipeline to a compliance-mapped client deliverable. ```mermaid flowchart LR subgraph EVIDENCE["Cloud evidence record (hash-chained)"] E1["timestamp, account_id region, api_call"] E2["resource_arn, actor_arn request, response"] E3["scope_ref (authorization) previous_hash, record_hash"] end FINDING["Structured Finding type: iam_over_privilege severity: critical affected: Role-A"] MAPPING["Compliance Mapping"] REPORT["Client Deliverable"] subgraph MAPS["Framework controls"] SOC2["SOC 2: CC6.3 access authorization"] ISO["ISO 27001: A.9.2.5 access rights review"] PCI["PCI DSS: 7.2.1 access control system"] end subgraph REPORTS["Report sections"] EXEC["Executive summary (risk + business impact)"] TABLE["Finding table (ID, severity, control)"] NARR["Attack narrative (backed by evidence)"] ROAD["Remediation roadmap (prioritized actions)"] end EVIDENCE --> FINDING --> MAPPING MAPPING --> SOC2 MAPPING --> ISO MAPPING --> PCI SOC2 --> REPORT ISO --> REPORT PCI --> REPORT EVIDENCE --> NARR REPORT --> EXEC REPORT --> TABLE REPORT --> NARR REPORT --> ROAD style EVIDENCE fill:#14141f,stroke:#5eead4,color:#5eead4 style MAPPING fill:#14141f,stroke:#5eead4,color:#5eead4 style SOC2 fill:#0d1418,stroke:#1e8449,color:#82e0aa style ISO fill:#0d1418,stroke:#1e8449,color:#82e0aa style PCI fill:#0d1418,stroke:#1e8449,color:#82e0aa style REPORT fill:#0d2818,stroke:#1e8449,color:#82e0aa ``` **Reading the diagram**: The cloud evidence record (teal, left) captures every API action — timestamp, account, region, the exact API call, the resource ARN, who acted, the request and response, the scope reference that authorized it, and the hash chain that makes it tamper-evident. Evidence records roll up into structured findings: type (iam_over_privilege, public_exposure, escalation_path), severity, affected resource. The compliance mapping translates each finding type to framework controls — SOC 2 CC6.3 (access authorization), ISO 27001 A.9.2.5 (access rights review), PCI DSS 7.2.1 (access control system). The client deliverable (green, right) has four sections: executive summary (risk and business impact for the CISO), finding table (ID, severity, control mapping for tracking), attack narrative (step-by-step story backed by the evidence chain), and remediation roadmap (prioritized actions). The auditor does not need to understand iam:PassRole — they see SOC 2 CC6.3 at risk. That is what makes the deliverable client-ready.