A vulnerable web component to full estate compromise in 4 minutes and 38 seconds.
A real run of the platform, published in full — every document the engagement produced, exactly as it came out of the engine. One run crossed a public web application, a cloud tenancy, and an Active Directory forest — the way an attacker moves, rather than one tool per silo. Read it before you talk to us.
No form, no email required. Also in the set: the PCI DSS v4.0 §11.4 report (5 pages).
Seven transitions, no operator at the keyboard.
The full run chained thirteen stages; the graph condenses them to the seven that cross from one domain into the next. Each hop was proven, not inferred — the engine held the credential it stole at one stage and used it at the next, which is the part a siloed test structurally cannot show you.
How a routine misconfiguration became a full domain compromise.
- 01
Server-side request forgery on an internet-facing application
A public web application could be induced to make requests on the tester’s behalf. Pointed at the cloud instance-metadata service, it returned credentials belonging to the host’s own IAM role. No authentication was required to reach this point.
- 02
Cloud storage looted for secrets
Those credentials opened a storage bucket named for cardholder data. Inside it sat a plain-text password file written for VPN domain-join operations — a routine operational artifact, left where a stolen cloud role could read it.
- 03
The cloud credential worked on-premises
That password authenticated directly against the on-premises directory. This is the bridge most testing never finds, because it only appears when one engagement covers both sides: a misconfigured web application became a path from the public internet into the internal network.
- 04
Certificate services relayed into the domain controller
An ADCS enrollment endpoint accepted a relayed authentication (ESC8), yielding a certificate for the domain controller’s own machine account. From there the tester authenticated as the DC itself.
- 05
Full domain compromise
Acting as the domain controller, the engine replicated every credential in the directory — 19 records, including the krbtgt master key that underwrites authentication for every user and system in the organization. Elapsed time from the first external request: four minutes, thirty-eight seconds.
Written to be verified, not believed.
Every finding carries its evidence
Not a severity label and a paragraph of advice — the actual request and response, the command that ran, and the output it produced. Your team reads what happened rather than taking our word for it.
Re-runnable reproduction steps
Each finding ships with the steps to reproduce it in your own environment. That is what makes a fix verifiable: you can confirm the finding is gone rather than trusting a retest invoice.
The chain, not a list of issues
A scanner reports an SSRF and a weak password policy as two unrelated medium findings. This report shows the line connecting them, which is what determines whether either one actually matters.
Mapped to the frameworks you report against
Findings carry CWE, CVSS v3.1, and MITRE ATT&CK technique mappings, with OWASP ASVS and PCI DSS overlays available where the scope warrants.
One engagement, three documents.
Every engagement produces the same set, rendered from one frozen snapshot of the findings — so the executive summary, the technical detail, and the compliance artifacts can never drift out of agreement with each other.
Executive summary
The engagement outcome, business impact, and priority remediation — written for a board or an exec team, not for engineers.
Download the Executive summary (4 pages, PDF)Technical report
Every finding in full — CVSS and CWE, the request and response, the commands that ran, and re-runnable reproduction steps.
Download the Technical report (82 pages, PDF)PCI DSS v4.0 §11.4 report
The §11.4 penetration-test report an assessor asks for — CDE boundary, per-requirement coverage from 11.4.1 to 11.4.5, and segmentation testing results.
Download the PCI DSS v4.0 §11.4 report (5 pages, PDF)Check that these are the files we published.
Every report is hashed and signed at publication against a frozen snapshot of the engagement data. The verification endpoint is public and needs no account — anyone holding the file can confirm it has not been altered since, including by us. All three PDFs above are byte-identical to their published artifacts.
42c7fa3154d99268e7b1c74b964abf3292fede6eb9028a614ab8c384e314620d
Compare against the signed record for the Executive summary (opens in a new tab) db781599db1aefea7946a3f38771a7701ccfc1027a14d769138315933dba3066
Compare against the signed record for the Technical report (opens in a new tab) 7abcd482fc0727dd9cb8c4889a3fae462258fb74e69d0e075c36c8265113fb58
Compare against the signed record for the PCI DSS v4.0 §11.4 report (opens in a new tab)
shasum -a 256 Section-31-Sample-*.pdf
All three signed Ed25519 against snapshot 0bc673ec…2d1f0.
About this engagement. The report describes a real, complete run of the platform against a purpose-built hybrid estate — a public web tier, an AWS tenancy, and a Windows domain — configured to mirror the mid-market environments we test. The customer name and domain are fictional so the document can be published in full; the attack path, timings, findings, and evidence are exactly as the engine produced them. We publish a sample with a fictional target rather than a redacted real customer, because a report with the interesting parts blacked out proves nothing.
See this against your own estate.
We will run a scoped assessment against your external surface and one Active Directory domain, and you keep the report — whatever it finds, and whether or not you buy anything.