Ransomware readiness
The intrusion an affiliate actually runs, tested stage by stage: credentialed entry, enumeration nobody saw, the escalation path that was already there, measured blast radius, and whether recovery survives the domain.
Start here, then go deeper.
Follow the intrusion in the order an affiliate runs it — credentialed entry, enumeration, escalation, reach, and the two properties that decide how bad the last stage gets.
- 01Initial accessThey Do Not Break In. They Log In.7 min ↗
Part one of testing the ransomware playbook: the initial access an affiliate needs is almost always a valid credential against a reachable endpoint — and that finding is usually already in a report somewhere, marked medium.
- 02First hourEnumeration Cannot Be Prevented. Ask Whether It Was Seen.7 min ↗
Part two of testing the ransomware playbook: the affiliate's first hour is the same directory collection you run, it cannot be blocked, and the engagement usually destroys the only question worth asking about it on day one.
- 03EscalationAffiliates Do Not Find Novel Paths. They Find Yours.7 min ↗
Part three of testing the ransomware playbook: privilege escalation inside the domain uses a small, stable set of paths — the same ones already written up on this site — and the affiliate picks by reliability, not by cleverness.
- 04Blast radiusThe Blast Radius Is One Number. Almost Nobody Has Measured It.7 min ↗
Part four of testing the ransomware playbook: lateral movement runs on your own administrative tooling, so detection is a signal-to-noise problem — and the number that actually decides the outcome is how many hosts accept the same credential.
- 05Impact limitsThe Last Two Steps Are Not in Scope. What Makes Them Survivable Is.6 min ↗
Part five of testing the ransomware playbook: an assessment stops before exfiltration and encryption, and it should. But the two properties that decide how bad either gets — egress and backup reachability — are fully testable, and almost never in scope.
Every matching record.
Methods and named-vulnerability research remain visually and editorially separate.
Field notes 12
The Event Was Visible. The Detection Still Needed Context.
Endpoint Security can deliver macOS authorization requests and event notifications, but an event is not yet a verdict. A defensible design preserves timing, sequence gaps, process identity, policy version, privacy, outcome, and the resulting system effect.
11 min read ↗Pentest · Sep 3, 2026One ATM Was Contained. The Fleet Trust Path Was Not.
The final ATM assessment chapter: test remote support, software deployment, segmentation, monitoring, transaction integrity, containment, and reconciliation as fleet-wide control planes.
12 min read ↗Pentest · Sep 2, 2026The Device API Was Standard. Authorization Was Assumed.
Part four of the ATM assessment series: test XFS-style middleware, caller identity, service providers, peripheral state, PIN boundaries, and transaction context with emulators and denied requests—not live device effects.
12 min read ↗Pentest · Sep 1, 2026The Desktop Was Hidden. The Execution Boundary Was Not.
Part three of the ATM assessment series: validate kiosk containment, application control, service identities, maintenance states, secrets, updates, and off-host telemetry without turning UI escape testing into a payload exercise.
12 min read ↗Pentest · Aug 31, 2026The BIOS Had a Password. The Boot Chain Still Needed Trust.
Part two of the ATM assessment series: an evidence-driven method for validating firmware recovery, Secure Boot, measured boot, disk-unlock policy, update integrity, and off-host detection without publishing a hardware-bypass playbook.
17 min read ↗Pentest · Aug 30, 2026The ATM Was Locked Down. The Transaction Path Was Not.
An evidence-driven methodology for authorized ATM security assessments: test the trust boundaries between the kiosk, operating system, device middleware, EPP, service network, monitoring plane, and transaction switch without turning the engagement into a cash-out exercise.
15 min read ↗Pentest · Aug 30, 2026The Red Team Reached Domain Admin. The Exercise Still Failed.
Domain Admin is a capability, not a business objective. This field methodology turns an authorized red team operation into a testable chain of objective, runtime authority, technical action, defender signal, response decision, evidence, and verified recovery.
18 min read ↗Pentest · Feb 6, 2026The Last Two Steps Are Not in Scope. What Makes Them Survivable Is.
Part five of testing the ransomware playbook: an assessment stops before exfiltration and encryption, and it should. But the two properties that decide how bad either gets — egress and backup reachability — are fully testable, and almost never in scope.
6 min read ↗Pentest · Jan 16, 2026The Blast Radius Is One Number. Almost Nobody Has Measured It.
Part four of testing the ransomware playbook: lateral movement runs on your own administrative tooling, so detection is a signal-to-noise problem — and the number that actually decides the outcome is how many hosts accept the same credential.
7 min read ↗Pentest · Dec 12, 2025Affiliates Do Not Find Novel Paths. They Find Yours.
Part three of testing the ransomware playbook: privilege escalation inside the domain uses a small, stable set of paths — the same ones already written up on this site — and the affiliate picks by reliability, not by cleverness.
7 min read ↗Pentest · Nov 21, 2025Enumeration Cannot Be Prevented. Ask Whether It Was Seen.
Part two of testing the ransomware playbook: the affiliate's first hour is the same directory collection you run, it cannot be blocked, and the engagement usually destroys the only question worth asking about it on day one.
7 min read ↗Pentest · Nov 7, 2025They Do Not Break In. They Log In.
Part one of testing the ransomware playbook: the initial access an affiliate needs is almost always a valid credential against a reachable endpoint — and that finding is usually already in a report somewhere, marked medium.
7 min read ↗