Series · 5 partsTesting the Ransomware PlaybookPart 1 · You are here
Initial access in 60 seconds
Most writing about ransomware is written from one of two seats: the incident responder’s, after it happened, or the threat intelligence analyst’s, from public reporting. This series is written from the third seat — the one where you get to look at the same infrastructure first, with permission, and write down what you find.
Because the uncomfortable thing about the ransomware playbook is how little of it is exotic. Up to the moment of encryption, an affiliate is doing the work of an internal assessment. Badly, loudly, and with worse tooling — but the same work.
This part covers how they get in. The next four cover what they do once they are.
The premise nobody wants in a report
Affiliates do not, in the main, exploit their way in. They authenticate. Somebody’s credential is valid, some endpoint accepts it, and no second factor stands in the way.
Which means the finding that would have prevented the whole event usually already exists. It was written up as “multi-factor authentication is not enforced on the remote access portal”, categorised as medium because no exploitation was demonstrated, and scheduled behind the things that had CVEs attached.
That is the gap this part is about. Not finding the door — the door is rarely hidden. Making the finding survive triage.
MFA is an endpoint fact, not an organisation fact
“MFA is enforced” is almost always true and almost never complete. It is enforced on the thing that was in scope when MFA was rolled out. The estate then keeps growing.
The endpoints that turn up uncovered are consistently the ones that were never thought of as remote access: an API that authenticates against the same directory, a legacy protocol left enabled for one integration, a management interface that predates the identity project, a service account exempted “temporarily” because it could not do interactive auth.
None of these look like a front door. All of them accept the same credential.
Testing it properly
The productive external test is not a password spray. It is an inventory of which authentication surfaces exist and what each one enforces — and the second half is the part that gets skipped.
# 1. Enumerate the authentication surface, not just the web surface.
# Every host that accepts a directory credential is in scope for this question.
# 2. For each endpoint, establish what a failed and a successful auth look like,
# and whether a second factor is actually demanded after a correct password.
# A 200 with an MFA prompt and a 200 with a session cookie are different findings.
# 3. Only then, and only within the lockout policy, test credential validity.
$ kerbrute passwordspray -d lab.local --dc dc01.lab.local users.txt 'Season2026!' \
--safe --delay 3000The --safe behaviour matters more than the spray does: stop on the first lockout rather
than working through the list. A test that locks accounts converts a technical finding into
an operational incident, and the report afterwards is about you rather than about the door.
The lockout policy is readable before you start, and there is no reason to guess at it:
Get-ADDefaultDomainPasswordPolicy |
Select-Object LockoutThreshold, LockoutObservationWindow, LockoutDurationThreshold minus one, spread across the observation window, is the whole calculation. Everything else is impatience.
The finding that survives triage
Three elements, and the third is the one usually missing:
The specific endpoint. Not “MFA is not enforced” but “this host, this path, this protocol, accepts a directory credential and completes authentication without a second factor.”
Proof it authenticates. A session, a token, a directory read — something that demonstrates the credential was accepted, not merely that a prompt appeared.
What it reaches. This is the multiplier. An uncovered endpoint that lands you on an isolated segment is a real finding. One that lands you somewhere you can enumerate the directory is the first move of every subsequent part in this series, and the report should say so explicitly.
Without the third element the finding gets read as a configuration gap. With it, it gets read as the entry point it actually is.
Evidence matrix
| Signal | What it proves | Negative control | Defender verification |
|---|---|---|---|
| One externally reachable endpoint accepts the approved test credential without MFA | MFA coverage has a route-specific gap | Use the same identity on a protected endpoint and require the second factor | Maintain an endpoint-by-endpoint authentication inventory, including legacy and vendor portals |
| Successful login lands on an internal or directory-aware segment | The gap is an initial-access path, not an isolated login defect | Repeat with an account scoped to a true isolated zone and compare reachability | Validate post-authentication routing, DNS, directory, and management-plane access |
| Disabled or policy-blocked test identity is rejected everywhere | Revocation and conditional access reach every front door | Disable the canary identity and probe all endpoints within the approved window | Correlate identity-provider, VPN, appliance, and application-native authentication logs |
| The endpoint records enough context to identify the login | Detection can distinguish the event and support response | Test an expected failure and confirm both result and source context are logged | Verify alert routing for successful password-only access from a new source |
The pattern I keep seeing
Identity projects are scoped to the things that look like remote access. The exceptions granted during rollout — for the integration that could not do modern auth, for the service account, for the interface nobody could migrate in time — are recorded as temporary, and the temporary ones outlive the project. Nobody revisits them because they are not broken; they work exactly as intended, for the one thing they were exempted for, and for anything else that finds them.
So the honest version of the finding is rarely “MFA is missing”. It is “MFA is enforced, and here is the list of places it is not, and here is which of them a valid credential reaches.”
What to hand the defenders
The inventory, not the incident. Every endpoint that accepts a directory credential, and what each enforces. That list is the deliverable; the one you got in through is an example from it.
Push the exceptions to expiry. Exemptions that cannot be removed today should carry a date and an owner. Most of the ones that turn up in testing have neither, which is why they are still there.
Then the reachability question. For each uncovered endpoint, what can the resulting session touch? That is what decides whether it is a finding to fix this quarter or this week — and it is the question that connects this part to the next one.
Next in this series: what an affiliate enumerates in the first hour, and why it is the same collection you already run.
How current is this note?
The latest source-review, content-update, or publication date is shown.
The author completed a technical review. This does not, by itself, claim lab reproduction.