Penetration testing
Our testing runs on this method end to end — every finding you receive was reachable and demonstrated, not inferred from a severity label.
Sample Engagement
A walkthrough of how Crimson turns a raw vulnerability scan into a short list of genuinely exploitable, validated findings — and the proof behind each one. This is an illustrative sample built to show the method, not a real client engagement.
Illustrative sample. Hosts, findings, and figures below are synthetic and do not represent a real client or engagement — they show the method Crimson applies on every test.
The problem
A single authenticated scan of a mid-size estate came back with 480 findings across 214 hosts — 137 of them flagged “Critical.” Handed that spreadsheet, most teams either try to patch everything at once or freeze. Neither answers the only question that matters: which of these could an attacker actually use, and how far would it get them?
The method
01
Crimson’s machine-learning models rank every host by likelihood of successful exploitation — not raw CVSS. Printers, workstations, and dead-end hosts drop down the queue; domain controllers and exposed services rise. 214 hosts → 47 worth a closer look.
02
Each candidate CVE is enriched from our threat-intelligence platform — EPSS probability, CISA KEV status, exploit maturity, known modules, ransomware associations. Findings with no real-world exploit path fall away. 47 → 12 candidate targets.
03
The remaining targets are put to the test through a controlled, consultant-directed exploitation workflow. A finding only makes the final list if it was actually reachable and actually worked. 12 → 6 proven.
04
The six are written up with the evidence, the impact, and the fix — plus the three chained paths that led to domain admin. That is the deliverable: a fix list ranked by consequence, not a 480-row export.
The proof
| Host | Weakness | CVSS | EPSS | KEV | Crimson | Validated result |
|---|---|---|---|---|---|---|
| SRV-DC01 | Unauthenticated RCE in a file-sharing service | 9.8 | 0.94 | KEV | 98 | Domain administrator |
| VPN-EDGE1 | Authentication bypass in a remote-access gateway | 9.4 | 0.88 | KEV | 91 | Internal network foothold |
| SRV-APP03 | Deserialization RCE in a web application | 9.1 | 0.72 | KEV | 88 | Shell + cached credentials |
| SRV-SQL02 | Service-account credential reuse | 8.1 | 0.10 | — | 76 | Lateral movement to DC01 |
| WEB-DMZ2 | Exposed admin interface with default credentials | 8.6 | 0.30 | — | 71 | Application compromise |
| FILE-07 | SMB signing disabled — credential relay | 7.5 | 0.05 | — | 64 | Credential relay to SRV-SQL02 |
Note the last three rows: two carry a modest CVSS and a low EPSS, and none are on the KEV list — a severity-only triage would rank them far down. Crimson surfaced them because, in this environment, they were the links that chained a foothold all the way to the domain.
The story the list doesn’t tell
The auth bypass on VPN-EDGE1 put a tester on the internal network with no credentials — the front door, not the wall.
Disabled SMB signing on FILE-07 allowed a credential relay that landed a service account on SRV-SQL02 — a “medium” the scanner nearly buried.
That account’s reuse reached SRV-DC01, where the unauthenticated RCE completed the path to domain administrator.
The scanner marked 137 findings “Critical.” Six were reachable and exploitable. Three, chained together, reached domain admin. That gap — between what is flagged and what is provable — is the entire point of a Crimson-driven test.
How We Help
Our testing runs on this method end to end — every finding you receive was reachable and demonstrated, not inferred from a severity label.
See the engine behind the funnel — the exploitability scoring, live intelligence, and controlled exploitation that produced this short list.
This is the shape of every Crimson-driven penetration test: less noise, validated findings, and a fix list ranked by what an attacker could actually do. Tell us what is in scope and we will size the work.