Module: S10 — Cloud Red Team Harnesses · Duration: ~60 minutes
Format: Verbatim transcript. Cues [SLIDE N] map to 03-slide-deck.html.
[SLIDE 1 — Title]
This is Module S Zero Ten: Cloud Red Team Harnesses. Sixty minutes. The second and final module of Pillar Three — Cloud Security. Three sub-sections: cloud-specific offensive architecture, IAM privilege escalation harnesses, and findings, evidence, and client deliverables. S Nine built the defensive harness — posture, monitoring, remediation. S Ten flips to offense. Same cloud. Opposite direction. By the end you can build a harness that attacks the cloud the way cloud adversaries do — API-first, identity-first, no port scanning — finds IAM privilege escalation chains, and produces evidence-backed findings mapped to SOC Two, ISO Twenty Seven Thousand One, and PCI DSS.
[SLIDE 2 — S10.1: Cloud-Specific Offensive Architecture]
Sub-section one. Cloud-specific offensive architecture. The fundamental point. A network pentest harness scans ports, enumerates services, and exploits vulnerabilities in running software. A cloud red team harness does none of these things. The cloud is not a network. It is an API. The attack surface is not open ports. It is identities, permissions, and configurations. The cloud offensive harness is built on a fundamentally different architecture.
If you take a network pentest harness and point it at a cloud account, you will scan a lot of IP addresses and find very little. The cloud's attack surface is not at the network layer. An AWS account has no ports to scan in the way nmap scans them. It has IAM policies to enumerate, roles to map, trust relationships to trace, and API endpoints to query. The harness must be rebuilt around this reality.
[SLIDE 3 — API-first, identity-first, no port scanning]
The defining difference is the attack surface boundary. API-first: every action the harness takes is an API call against the cloud provider's control plane, not a packet against a network interface. Identity-first: the primary attack surface is IAM — users, roles, policies, and trust relationships — not the compute infrastructure. And no port scanning: the reconnaissance phase enumerates cloud resources and permissions via the provider APIs. ListBuckets, GetRole, ListAttachedRolePolicies. Not nmap.
This changes the tool suite entirely. The S Zero Two bug bounty harness wrapped nmap, httpx, nuclei, ffuf. The S Ten cloud red team harness wraps a different set of tools. Prowler — CIS benchmark and cloud security configuration checks across AWS, Azure, and GCP. ScoutSuite — multi-cloud auditing that builds a visual attack surface. Pacu — the AWS exploitation framework, with IAM escalation and post-exploitation modules. Stormspotter — the Azure attack graph builder. And the GCP IAM Recommender, which identifies over-privileged service accounts.
Each tool is wrapped as a harness tool following the S Zero Two point two pattern. Pydantic-typed input. Scope-checked against the engagement authorization. Rate-limited. Evidence-logged. The wrapping is what makes these offensive tools safe to run under authorization. The scope check is the legal boundary.
[SLIDE 4 — The cloud kill chain]
The cloud kill chain mirrors the network kill chain in phases but differs in execution at each phase. Reconnaissance: enumerate the target's public assets — S Three buckets, API Gateways, exposed endpoints — and identities, and permissions. Done entirely through provider APIs. No network scanning. Initial access: gain a foothold via an exposed service with a vulnerability, a compromised credential like a leaked access key, or a public resource that accepts unauthenticated interaction.
Privilege escalation — the core of cloud offense. From the initial access identity, abuse IAM permissions to gain higher privilege. This is sub-section two. Lateral movement: pivot from the compromised identity to others via cross-account trust relationships, cross-service shared VPCs, or over-broad security groups. And impact: data access demonstrated as read-only proof, resource exposure mapping, and persistence vector identification. Not actual exfiltration. The harness demonstrates the path exists. It does not steal the data.
And scope enforcement is mandatory at every phase. The scope file defines the account boundaries — which AWS account IDs are authorized. The region constraints — which regions are in scope, with denied regions like GovCloud never touched. And the service exclusions — destructive calls like DeleteRole, DeleteBucket, TerminateInstances are blocked unconditionally unless the scope file explicitly authorizes them with a separate approval. The scope file is the legal boundary. The middleware enforces it on every API call.
The destructive-action blocking deserves emphasis. An authorized cloud engagement demonstrates paths to impact — it does not cause impact. A finding that an adversary could delete a production database is demonstrated by showing the identity has the permission, not by deleting the database. The scope file blocks destructive calls unconditionally. Even if the harness has valid credentials and the identity has the permission, the middleware prevents the destructive call from executing. This is what separates a red team engagement from an actual attack. The restraint is engineered into the harness, not left to operator discipline.
[SLIDE 5 — S10.2: IAM Privilege Escalation]
Sub-section two. IAM privilege escalation harnesses. IAM is the primary attack surface in cloud environments. Not the network. Not the compute. Not the storage. The identity and access management layer. A cloud breach is almost always an IAM abuse. An over-privileged role used to access data it should not. A trust relationship exploited to assume a more powerful identity. A permission chain that escalates from low-privilege to admin. The IAM privilege escalation harness automates finding these chains.
[SLIDE 6 — Canonical escalation paths]
The canonical AWS privilege escalation paths are documented and finite. The Rhino Security Labs research is the reference. The harness enumerates which paths are available from a given starting identity and chains them. iam PassRole plus service creation: if an identity has PassRole and can create a service — Lambda, EC Two — it can pass a more privileged role to the new service and act through it. Pass a role with full S Three access to a new Lambda, invoke the Lambda, read every bucket. iam CreatePolicy and AttachRolePolicy: if an identity can create policies and attach them, it can grant itself any permission. Create a policy with star-colon-star, attach it to its own role. iam UpdateAssumeRolePolicy: if an identity can modify a role's trust policy, it can add itself as a trusted principal and assume that role, gaining whatever permissions it has. Lambda InvokeFunction chains: a Lambda that has access to resources the current identity cannot reach — invoke it with a crafted payload to act through the Lambda's execution role. And sts AssumeRole chains: a role whose trust policy permits assumption by the current identity — assume it, gain its permissions, look for further escalation from the new position.
[SLIDE 7 — Graph-based PE path finding]
Each path is a node-and-edge graph. The current identity's permissions are the starting edges. Each escalation technique is a transition to a more privileged state. The goal is a permission set that reaches the target — s Three GetObject on a sensitive bucket, or star-colon-star for full admin.
The harness models this as graph traversal. The same technique as S Nine point two's attack-path analysis, applied to the IAM layer. Nodes are permission sets. Edges are escalation techniques. The harness runs breadth-first search from the starting identity's permissions to the target permission set. 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 tools. Pacu is the AWS exploitation framework. It implements many of these escalation techniques as modules. The iam privesc scan module enumerates the current identity's permissions and identifies available escalation paths. Stormspotter is the Azure equivalent — it builds a graph of Azure identities and resources and visualizes the attack surface. Both produce structured output that the harness consumes. The harness wraps Pacu and Stormspotter as tools, feeds their output into the privilege graph, and produces a structured escalation-path report. The harness adds what the tools alone do not provide: the chain reasoning, the scope enforcement, and the evidence schema.
[SLIDE 8 — Demonstrated, not theoretical]
Every escalation path the harness identifies must be backed by evidence. Not asserted. Demonstrated. The evidence schema captures the API call, the response, the timestamp, the account, the region, and the resource ARN. For a PassRole escalation, the evidence is the GetRole call showing the identity has PassRole permission. The Lambda creation showing the role was passed. The Lambda invocation showing the escalation succeeded. And the response showing the elevated access worked.
This evidence is what distinguishes a demonstrated escalation path from a theoretical one. The client does not need to trust the harness's assertion that Role-A can escalate to admin. The evidence shows the exact API calls, in order, that achieve it. Reproducible. Verifiable. Client-presentable. This is S Zero Two point three's evidence chain engineering, applied to the cloud context.
The difference between demonstrated and theoretical matters for three reasons. First, the client's remediation depends on the proof. A theoretical path might not be exploitable in the specific environment — there may be a guardrail, a service control policy, a permissions boundary, that blocks the technique in practice. The demonstration either succeeds, confirming the path is real and the remediation is urgent, or it fails, revealing the guardrail, which is itself a finding about defense-in-depth. Second, the auditor needs reproducibility. A compliance review may ask to see the evidence months after the engagement. The hash-chained evidence log is reproducible — anyone with the credentials can re-run the sequence and confirm the result. Third, the engineering team needs to verify the fix. After remediation — removing the over-permissive PassRole permission — the team re-runs the evidence sequence to confirm the escalation no longer works. The fix is verified against the same evidence that demonstrated the vulnerability.
[SLIDE 9 — S10.3: Findings, Evidence & Deliverables]
Sub-section three. Findings, evidence, and client deliverables. The cloud red team engagement produces findings — demonstrated paths from initial access to impact. Each finding must be structured, evidenced, and mapped to compliance frameworks for the client deliverable. The evidence schema and the compliance mapping are what make the findings actionable for the client's auditor, not just interesting to the client's security team.
The point that drives this section. The client's auditor does not care about iam PassRole chains. The auditor cares whether the organization meets SOC Two, ISO Twenty Seven Thousand One, or PCI DSS requirements. The finding-to-framework mapping is what translates the red team's technical findings into the auditor's compliance language.
[SLIDE 10 — Cloud evidence schema]
Every finding is backed by a chain of evidence records. The cloud evidence schema extends S Zero Two point three's hash-chained evidence log with cloud-specific fields. The base fields from the evidence chain — id, trace id, session id, timestamp, the request and response, the scope ref, the previous hash and record hash for tamper-evidence, the retention class and expiry. The cloud-specific additions: the cloud provider, the account id, the region, the API call — for example s Three GetObject — the resource ARN — the exact resource acted upon — and the actor ARN — which identity made the call.
These fields make the evidence precise. Not just "a call was made," but "the call s Three GetObject was made against arn aws s Three the client's sensitive data bucket, in us-east-1, from account one two three four five six seven eight nine zero one two, at this exact timestamp, authorized by this scope entry, producing this exact response." The hash chain ensures tamper-evidence. No record can be altered without breaking the chain.
[SLIDE 11 — Finding to compliance mapping]
Each finding type maps to specific controls in each framework. An over-privileged IAM role is not just "a misconfiguration." It is a violation of SOC Two CC six point three — the entity authorizes, modifies, or removes access to data. ISO Twenty Seven Thousand One A nine point two point five — review of user access rights. And PCI DSS seven point two point one — establish an access control system for systems components.
A public exposure finding maps to SOC Two CC six point one — logical access controls. ISO A thirteen point one point one — network controls. PCI one point two point one — restrict inbound and outbound traffic. A privilege escalation path maps to SOC Two CC six point three, ISO A nine point four point four, PCI seven point one point one. A missing encryption finding maps to SOC Two CC six point seven, ISO A ten point one point one, PCI three point four.
This mapping makes the finding immediately actionable for the compliance team. They know which control is at risk and what the remediation satisfies. They do not need to translate the technical finding themselves. The harness does the translation.
The client report has four sections. The executive summary: the overall risk assessment, what was tested, what was found, the business impact, the prioritized remediation roadmap. One page, non-technical language, framed in risk and compliance terms. The finding table: each finding with ID, title, severity, affected resource, compliance mapping, status. The structured overview the technical team uses to track remediation. The attack narrative: for each significant finding, the step-by-step story — how the initial access was obtained, how the escalation chain proceeded, what the impact would be. Backed by the evidence chain. Each step references the specific evidence records that demonstrate it. And the remediation roadmap: prioritized actions, mapped to the finding table and compliance frameworks. What to fix first, what to fix next, what to accept as residual risk.
The report is generated from the structured findings and evidence store, not written by hand. The evidence chain ensures every claim in the narrative is backed by a reproducible API call sequence. The compliance mapping ensures every finding speaks the auditor's language. This is what makes the deliverable client-ready. Technical depth for the engineers. Executive framing for the CISO. Compliance language for the auditors.
[SLIDE 12 — What you take forward]
The cloud red team harness is operational. API-first and identity-first offensive architecture that treats the cloud as an API, not a network. The cloud kill chain from reconnaissance through demonstrated impact, with scope enforcement on every call. IAM privilege escalation as graph path-finding — the same technique as the posture harness's attack-path analysis, applied to the offense side. And evidence-backed findings mapped to SOC Two, ISO Twenty Seven Thousand One, and PCI DSS, producing a client deliverable that serves engineers, executives, and auditors from one finding store.
Pillar Three is complete. The cloud posture harness tells you where your weaknesses are. The cloud red team harness exploits them under authorization. S Eleven moves to a different attack surface — the blockchain. Smart contract audit harnesses. A different domain, but the same discipline. Scope enforcement. Evidence chains. Structured findings. Client-ready deliverables. The harness engineering principles you have built across ten modules transfer. The attack surface changes. The discipline does not.
[End of script]
# Teaching Script — Module S10: Cloud Red Team Harnesses **Module**: S10 — Cloud Red Team Harnesses · **Duration**: ~60 minutes **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. --- [SLIDE 1 — Title] This is Module S Zero Ten: Cloud Red Team Harnesses. Sixty minutes. The second and final module of Pillar Three — Cloud Security. Three sub-sections: cloud-specific offensive architecture, IAM privilege escalation harnesses, and findings, evidence, and client deliverables. S Nine built the defensive harness — posture, monitoring, remediation. S Ten flips to offense. Same cloud. Opposite direction. By the end you can build a harness that attacks the cloud the way cloud adversaries do — API-first, identity-first, no port scanning — finds IAM privilege escalation chains, and produces evidence-backed findings mapped to SOC Two, ISO Twenty Seven Thousand One, and PCI DSS. --- [SLIDE 2 — S10.1: Cloud-Specific Offensive Architecture] Sub-section one. Cloud-specific offensive architecture. The fundamental point. A network pentest harness scans ports, enumerates services, and exploits vulnerabilities in running software. A cloud red team harness does none of these things. The cloud is not a network. It is an API. The attack surface is not open ports. It is identities, permissions, and configurations. The cloud offensive harness is built on a fundamentally different architecture. If you take a network pentest harness and point it at a cloud account, you will scan a lot of IP addresses and find very little. The cloud's attack surface is not at the network layer. An AWS account has no ports to scan in the way nmap scans them. It has IAM policies to enumerate, roles to map, trust relationships to trace, and API endpoints to query. The harness must be rebuilt around this reality. [SLIDE 3 — API-first, identity-first, no port scanning] The defining difference is the attack surface boundary. API-first: every action the harness takes is an API call against the cloud provider's control plane, not a packet against a network interface. Identity-first: the primary attack surface is IAM — users, roles, policies, and trust relationships — not the compute infrastructure. And no port scanning: the reconnaissance phase enumerates cloud resources and permissions via the provider APIs. ListBuckets, GetRole, ListAttachedRolePolicies. Not nmap. This changes the tool suite entirely. The S Zero Two bug bounty harness wrapped nmap, httpx, nuclei, ffuf. The S Ten cloud red team harness wraps a different set of tools. Prowler — CIS benchmark and cloud security configuration checks across AWS, Azure, and GCP. ScoutSuite — multi-cloud auditing that builds a visual attack surface. Pacu — the AWS exploitation framework, with IAM escalation and post-exploitation modules. Stormspotter — the Azure attack graph builder. And the GCP IAM Recommender, which identifies over-privileged service accounts. Each tool is wrapped as a harness tool following the S Zero Two point two pattern. Pydantic-typed input. Scope-checked against the engagement authorization. Rate-limited. Evidence-logged. The wrapping is what makes these offensive tools safe to run under authorization. The scope check is the legal boundary. [SLIDE 4 — The cloud kill chain] The cloud kill chain mirrors the network kill chain in phases but differs in execution at each phase. Reconnaissance: enumerate the target's public assets — S Three buckets, API Gateways, exposed endpoints — and identities, and permissions. Done entirely through provider APIs. No network scanning. Initial access: gain a foothold via an exposed service with a vulnerability, a compromised credential like a leaked access key, or a public resource that accepts unauthenticated interaction. Privilege escalation — the core of cloud offense. From the initial access identity, abuse IAM permissions to gain higher privilege. This is sub-section two. Lateral movement: pivot from the compromised identity to others via cross-account trust relationships, cross-service shared VPCs, or over-broad security groups. And impact: data access demonstrated as read-only proof, resource exposure mapping, and persistence vector identification. Not actual exfiltration. The harness demonstrates the path exists. It does not steal the data. And scope enforcement is mandatory at every phase. The scope file defines the account boundaries — which AWS account IDs are authorized. The region constraints — which regions are in scope, with denied regions like GovCloud never touched. And the service exclusions — destructive calls like DeleteRole, DeleteBucket, TerminateInstances are blocked unconditionally unless the scope file explicitly authorizes them with a separate approval. The scope file is the legal boundary. The middleware enforces it on every API call. The destructive-action blocking deserves emphasis. An authorized cloud engagement demonstrates paths to impact — it does not cause impact. A finding that an adversary could delete a production database is demonstrated by showing the identity has the permission, not by deleting the database. The scope file blocks destructive calls unconditionally. Even if the harness has valid credentials and the identity has the permission, the middleware prevents the destructive call from executing. This is what separates a red team engagement from an actual attack. The restraint is engineered into the harness, not left to operator discipline. --- [SLIDE 5 — S10.2: IAM Privilege Escalation] Sub-section two. IAM privilege escalation harnesses. IAM is the primary attack surface in cloud environments. Not the network. Not the compute. Not the storage. The identity and access management layer. A cloud breach is almost always an IAM abuse. An over-privileged role used to access data it should not. A trust relationship exploited to assume a more powerful identity. A permission chain that escalates from low-privilege to admin. The IAM privilege escalation harness automates finding these chains. [SLIDE 6 — Canonical escalation paths] The canonical AWS privilege escalation paths are documented and finite. The Rhino Security Labs research is the reference. The harness enumerates which paths are available from a given starting identity and chains them. iam PassRole plus service creation: if an identity has PassRole and can create a service — Lambda, EC Two — it can pass a more privileged role to the new service and act through it. Pass a role with full S Three access to a new Lambda, invoke the Lambda, read every bucket. iam CreatePolicy and AttachRolePolicy: if an identity can create policies and attach them, it can grant itself any permission. Create a policy with star-colon-star, attach it to its own role. iam UpdateAssumeRolePolicy: if an identity can modify a role's trust policy, it can add itself as a trusted principal and assume that role, gaining whatever permissions it has. Lambda InvokeFunction chains: a Lambda that has access to resources the current identity cannot reach — invoke it with a crafted payload to act through the Lambda's execution role. And sts AssumeRole chains: a role whose trust policy permits assumption by the current identity — assume it, gain its permissions, look for further escalation from the new position. [SLIDE 7 — Graph-based PE path finding] Each path is a node-and-edge graph. The current identity's permissions are the starting edges. Each escalation technique is a transition to a more privileged state. The goal is a permission set that reaches the target — s Three GetObject on a sensitive bucket, or star-colon-star for full admin. The harness models this as graph traversal. The same technique as S Nine point two's attack-path analysis, applied to the IAM layer. Nodes are permission sets. Edges are escalation techniques. The harness runs breadth-first search from the starting identity's permissions to the target permission set. 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 tools. Pacu is the AWS exploitation framework. It implements many of these escalation techniques as modules. The iam privesc scan module enumerates the current identity's permissions and identifies available escalation paths. Stormspotter is the Azure equivalent — it builds a graph of Azure identities and resources and visualizes the attack surface. Both produce structured output that the harness consumes. The harness wraps Pacu and Stormspotter as tools, feeds their output into the privilege graph, and produces a structured escalation-path report. The harness adds what the tools alone do not provide: the chain reasoning, the scope enforcement, and the evidence schema. [SLIDE 8 — Demonstrated, not theoretical] Every escalation path the harness identifies must be backed by evidence. Not asserted. Demonstrated. The evidence schema captures the API call, the response, the timestamp, the account, the region, and the resource ARN. For a PassRole escalation, the evidence is the GetRole call showing the identity has PassRole permission. The Lambda creation showing the role was passed. The Lambda invocation showing the escalation succeeded. And the response showing the elevated access worked. This evidence is what distinguishes a demonstrated escalation path from a theoretical one. The client does not need to trust the harness's assertion that Role-A can escalate to admin. The evidence shows the exact API calls, in order, that achieve it. Reproducible. Verifiable. Client-presentable. This is S Zero Two point three's evidence chain engineering, applied to the cloud context. The difference between demonstrated and theoretical matters for three reasons. First, the client's remediation depends on the proof. A theoretical path might not be exploitable in the specific environment — there may be a guardrail, a service control policy, a permissions boundary, that blocks the technique in practice. The demonstration either succeeds, confirming the path is real and the remediation is urgent, or it fails, revealing the guardrail, which is itself a finding about defense-in-depth. Second, the auditor needs reproducibility. A compliance review may ask to see the evidence months after the engagement. The hash-chained evidence log is reproducible — anyone with the credentials can re-run the sequence and confirm the result. Third, the engineering team needs to verify the fix. After remediation — removing the over-permissive PassRole permission — the team re-runs the evidence sequence to confirm the escalation no longer works. The fix is verified against the same evidence that demonstrated the vulnerability. --- [SLIDE 9 — S10.3: Findings, Evidence & Deliverables] Sub-section three. Findings, evidence, and client deliverables. The cloud red team engagement produces findings — demonstrated paths from initial access to impact. Each finding must be structured, evidenced, and mapped to compliance frameworks for the client deliverable. The evidence schema and the compliance mapping are what make the findings actionable for the client's auditor, not just interesting to the client's security team. The point that drives this section. The client's auditor does not care about iam PassRole chains. The auditor cares whether the organization meets SOC Two, ISO Twenty Seven Thousand One, or PCI DSS requirements. The finding-to-framework mapping is what translates the red team's technical findings into the auditor's compliance language. [SLIDE 10 — Cloud evidence schema] Every finding is backed by a chain of evidence records. The cloud evidence schema extends S Zero Two point three's hash-chained evidence log with cloud-specific fields. The base fields from the evidence chain — id, trace id, session id, timestamp, the request and response, the scope ref, the previous hash and record hash for tamper-evidence, the retention class and expiry. The cloud-specific additions: the cloud provider, the account id, the region, the API call — for example s Three GetObject — the resource ARN — the exact resource acted upon — and the actor ARN — which identity made the call. These fields make the evidence precise. Not just "a call was made," but "the call s Three GetObject was made against arn aws s Three the client's sensitive data bucket, in us-east-1, from account one two three four five six seven eight nine zero one two, at this exact timestamp, authorized by this scope entry, producing this exact response." The hash chain ensures tamper-evidence. No record can be altered without breaking the chain. [SLIDE 11 — Finding to compliance mapping] Each finding type maps to specific controls in each framework. An over-privileged IAM role is not just "a misconfiguration." It is a violation of SOC Two CC six point three — the entity authorizes, modifies, or removes access to data. ISO Twenty Seven Thousand One A nine point two point five — review of user access rights. And PCI DSS seven point two point one — establish an access control system for systems components. A public exposure finding maps to SOC Two CC six point one — logical access controls. ISO A thirteen point one point one — network controls. PCI one point two point one — restrict inbound and outbound traffic. A privilege escalation path maps to SOC Two CC six point three, ISO A nine point four point four, PCI seven point one point one. A missing encryption finding maps to SOC Two CC six point seven, ISO A ten point one point one, PCI three point four. This mapping makes the finding immediately actionable for the compliance team. They know which control is at risk and what the remediation satisfies. They do not need to translate the technical finding themselves. The harness does the translation. The client report has four sections. The executive summary: the overall risk assessment, what was tested, what was found, the business impact, the prioritized remediation roadmap. One page, non-technical language, framed in risk and compliance terms. The finding table: each finding with ID, title, severity, affected resource, compliance mapping, status. The structured overview the technical team uses to track remediation. The attack narrative: for each significant finding, the step-by-step story — how the initial access was obtained, how the escalation chain proceeded, what the impact would be. Backed by the evidence chain. Each step references the specific evidence records that demonstrate it. And the remediation roadmap: prioritized actions, mapped to the finding table and compliance frameworks. What to fix first, what to fix next, what to accept as residual risk. The report is generated from the structured findings and evidence store, not written by hand. The evidence chain ensures every claim in the narrative is backed by a reproducible API call sequence. The compliance mapping ensures every finding speaks the auditor's language. This is what makes the deliverable client-ready. Technical depth for the engineers. Executive framing for the CISO. Compliance language for the auditors. --- [SLIDE 12 — What you take forward] The cloud red team harness is operational. API-first and identity-first offensive architecture that treats the cloud as an API, not a network. The cloud kill chain from reconnaissance through demonstrated impact, with scope enforcement on every call. IAM privilege escalation as graph path-finding — the same technique as the posture harness's attack-path analysis, applied to the offense side. And evidence-backed findings mapped to SOC Two, ISO Twenty Seven Thousand One, and PCI DSS, producing a client deliverable that serves engineers, executives, and auditors from one finding store. Pillar Three is complete. The cloud posture harness tells you where your weaknesses are. The cloud red team harness exploits them under authorization. S Eleven moves to a different attack surface — the blockchain. Smart contract audit harnesses. A different domain, but the same discipline. Scope enforcement. Evidence chains. Structured findings. Client-ready deliverables. The harness engineering principles you have built across ten modules transfer. The attack surface changes. The discipline does not. --- [End of script]