# 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.