---
title: "The Blast Radius Is One Number. Almost Nobody Has Measured It."
description: "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."
date: 2026-01-16
author: Sevban Dönmez (@jankesec)
canonical: https://jankesec.com/posts/ransomware-playbook-04-lateral-movement/
---

## Lateral movement in 60 seconds

Something in the domain now has rights it should not have. The objective changes at this
point, and the change is easy to miss: the affiliate stops trying to become more privileged
and starts trying to be more places.

That shift matters because the two are defended differently, and almost all of the attention
goes to the first one.

## They do not bring tools

Lateral movement runs on SMB, WMI, WinRM and scheduled tasks. Not because those evade
anything, but because they are the administrative surface — the same one the platform team
uses to push agents, run inventory, and fix things at three in the morning.

So detection here is not a signature problem. Nothing needs to be identified as malicious,
because nothing is malicious in isolation. It is a signal-to-noise problem, and the noise is
your own operations.

Which turns "do you detect remote service creation?" into the wrong question. Event 7045 is
in the log. The right question is whether anyone can tell *this* service creation from the
forty legitimate ones the same week — and answering that requires knowing what the
legitimate forty look like. Most estates have never characterised their own administrative
traffic, so the answer is no, regardless of what the product claims.

## The number that actually decides the outcome

Movement technique is not the multiplier. Credential reuse is.

One local administrator password, valid on every workstation, converts a single compromised
host into all of them in one pass. No escalation, no new technique — the same hash, replayed.
Whether that is possible is a single measurable property of the estate, and it is the
property that separates an incident from an outage.

<figure class="diagram">
<svg viewBox="0 0 700 236" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="One shared local administrator credential is accepted by every host, giving a blast radius of the whole estate; per-host randomised passwords reduce the blast radius to one.">
<text x="0" y="16" class="dg-crit">SHARED LOCAL ADMIN</text>
<rect x="0" y="28" width="150" height="46" rx="8" class="dg-box-accent" />
<text x="14" y="48" class="dg-mono">one hash</text>
<text x="14" y="65" class="dg-muted">RECOVERED ONCE</text>
<line x1="152" y1="40" x2="268" y2="34" class="dg-line-crit" />
<line x1="152" y1="48" x2="268" y2="52" class="dg-line-crit" />
<line x1="152" y1="56" x2="268" y2="70" class="dg-line-crit" />
<line x1="152" y1="62" x2="268" y2="88" class="dg-line-crit" />
<rect x="270" y="24" width="130" height="20" rx="5" class="dg-box" />
<text x="282" y="38" class="dg-mono">host — accepted</text>
<rect x="270" y="46" width="130" height="20" rx="5" class="dg-box" />
<text x="282" y="60" class="dg-mono">host — accepted</text>
<rect x="270" y="68" width="130" height="20" rx="5" class="dg-box" />
<text x="282" y="82" class="dg-mono">host — accepted</text>
<text x="418" y="46" class="dg-crit">BLAST RADIUS</text>
<text x="418" y="64" class="dg-mono">every host that shares the password</text>
<text x="418" y="82" class="dg-muted">ONE PASS, NO ESCALATION NEEDED</text>
<line x1="0" y1="112" x2="700" y2="112" class="dg-line dg-dash" />
<text x="0" y="138" class="dg-accent">PER-HOST RANDOMISED</text>
<rect x="0" y="150" width="150" height="46" rx="8" class="dg-box" />
<text x="14" y="170" class="dg-mono">one hash</text>
<text x="14" y="187" class="dg-muted">RECOVERED ONCE</text>
<line x1="152" y1="172" x2="268" y2="172" class="dg-line" />
<rect x="270" y="162" width="130" height="20" rx="5" class="dg-box" />
<text x="282" y="176" class="dg-mono">host — accepted</text>
<text x="418" y="168" class="dg-accent">BLAST RADIUS 1</text>
<text x="418" y="186" class="dg-mono">worth exactly one machine</text>
<line x1="0" y1="212" x2="700" y2="212" class="dg-line dg-dash" />
<text x="0" y="232" class="dg-mono">same technique, same tooling, same detection — only the reuse changed</text>
</svg>
<figcaption>Nothing about the movement differs between the two halves. The affiliate runs the same commands and the same events land in the log. What differs is how far one recovered credential travels, and that is a configuration decision made years earlier.</figcaption>
</figure>

## Testing it as a measurement

The finding is not "lateral movement was possible". It is a number.

```
# Recover one local admin hash, then measure how far it goes.
$ nxc smb 10.0.0.0/24 -u Administrator -H <ntlm-hash> --local-auth
SMB  10.0.0.51  [+] WS01\Administrator (Pwn3d!)
SMB  10.0.0.52  [+] WS02\Administrator (Pwn3d!)
SMB  10.0.0.53  [+] WS03\Administrator (Pwn3d!)
...
```

The count at the bottom of that output is the deliverable. "One recovered local
administrator credential authenticated to 214 of 227 hosts" is a sentence that changes
budget decisions. "Pass-the-hash is possible" is not.

Two other measurements worth taking while you are there:

```powershell
# Is LAPS deployed, and where is it missing?
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwdExpirationTime |
  Where-Object { -not $_.'ms-Mcs-AdmPwdExpirationTime' } |
  Measure-Object

# Who can read the managed passwords? This is the escalation-shaped half of LAPS.
Get-ADComputer WS01 -Properties ntSecurityDescriptor |
  Select-Object -ExpandProperty ntSecurityDescriptor |
  Select-Object -ExpandProperty Access |
  Where-Object { $_.ObjectType -ne '00000000-0000-0000-0000-000000000000' }
```

That second query matters because LAPS does not delete the problem, it relocates it into a
DACL — the same point made in [the note on edge shelf life](/posts/bloodhound-edge-triage/).
A per-host random password that a broad helpdesk group can retrieve on demand has a blast
radius closer to the shared-password case than to one.

## Where the credentials come from

Worth being precise, because the sources have very different detection profiles and get
lumped together in reports:

**LSASS memory.** The loud one. Every endpoint product watches for handle opens against it,
and this is the technique detection is tuned for — which, as
[part three](/posts/ransomware-playbook-03-privilege-escalation/) argued, is why it is not
the first choice.

**The local SAM.** Local account hashes, no domain privilege needed, and the source of the
reuse problem above.

**Cached domain credentials.** Slow to crack by design, so they are a patience play rather
than an immediate one.

**Files nobody thinks of as credential stores.** Scheduled task definitions, service
configurations, deployment scripts on a share, and application config. No memory access, no
alert, and in practice the most reliable of the four.

The last category is the one that survives an EDR rollout completely intact.

## Evidence matrix

| Signal | What it proves | Negative control | Defender verification |
| --- | --- | --- | --- |
| One approved local credential authenticates to multiple hosts | Credential reuse creates a measurable blast radius | Test a LAPS-managed host and require the same credential to fail | Compare local administrator password/identity uniqueness across the estate |
| Management protocol is reachable from a user workstation segment | Network design permits the credential to travel | Block the protocol at the segment boundary and confirm the hop fails | Validate SMB, WinRM, RDP, and remote-service paths by source and destination tier |
| Credential is recovered from a share, task, service, or deployment file | The movement path survives memory protections and EDR | Remove the secret and confirm the automation still works through a managed identity | Scan configuration stores and shares, then map each secret to owner and consumers |
| Same action generates recognizable authentication and service events | The path is detectable with existing telemetry | Repeat a failed authentication and compare the event sequence | Correlate one identity authenticating laterally to an unusual number of peers |

## The pattern I keep seeing

Shared local administrator passwords are almost never a decision anybody defends. They are
the residue of an imaging process — a gold image built once, with a password set once, and
then deployed for years. Nobody chose it; it was inherited, and rotating it means touching
every machine, which is exactly the kind of work that never gets prioritised until it is
prioritised by an incident.

The same shape produces the credential-in-a-file category. A deployment script needed
credentials to run unattended, someone put them in the script, the script went on a share so
the automation could reach it, and the share is readable by everyone because that was the
fastest way to make it work.

## What to hand the defenders

**The number, first.** How many hosts accepted one credential. Everything else in this
section is context for that figure.

**The baseline gap, second.** If nobody can distinguish your movement from routine
administration, say it as its own finding. It is fixable — characterise which accounts
legitimately perform remote execution, from which sources, on what schedule — and it makes
every subsequent detection rule possible. Without it, no rule can be written that does not
drown the analyst.

**LAPS with the read rights checked.** Recommending LAPS without auditing who can read the
passwords produces a deployment that satisfies the finding and leaves the blast radius
unchanged.

---

*Next, and last in this series: the part testing does not cover — exfiltration and
encryption, and why the finding that would have stopped them is upstream of both.*