An attacker with a foothold on a monitored host wants the credential material sitting in the Windows registry. Most EDR products block the best-known route to it. Our team went looking for whether blocking that route actually prevents the outcome.
It does not — and the reason is worth more than the specific technique. A detection written against a tool is not a detection against a behaviour, and credential theft from the registry is a behaviour with more than one tool.
What is actually being targeted
Three registry hives hold material that is worth an attacker's time.
SAM
The Security Account Manager — a local database on every Windows system, containing the hashed passwords of local accounts. On an estate with a shared or predictable local administrator password, one machine's SAM is a key to many.
SECURITY
Stores the LSA policy database: which domains are trusted to authenticate logons, which users may access the system and over which logon types, what privileges are assigned, how users are audited — and, critically, cached domain credentials and service account logon information. Service account material here is frequently the bridge from one workstation to the wider domain.
SYSTEM
Among much else, it holds the boot key needed to decrypt the contents of the other two. Without it the hashes are inert, which is why these hives are always taken together.
An attacker taking all three has local password hashes, LSA secrets, cached domain credentials and the key to decrypt them — retrieved from a machine that is running EDR.
The finding
The well-known way to extract these hives uses a specific built-in Windows binary, and EDR vendors have been blocking it for years. That block works, for that binary.
But hive extraction is not a capability that lives in one executable. It is an operating system function exposed through several interfaces, some with a graphical front end, all shipped with Windows and all signed by Microsoft. Our team confirmed that the hives can be exported while EDR is running and blocking the obvious route, and that the resulting files can be processed off-box at leisure.
We are not publishing the steps. The point is not the alternative route — there is more than one, and there will be another after this. The point is that the control was never on the capability.
Why this pattern recurs
Blocking a named binary is cheap, specific and produces very few false positives, which is exactly why it is popular. It is also trivially avoidable whenever the underlying capability is reachable another way. The same shape appears across Windows security: block the tool, and the technique migrates to the next signed binary that can do the same job.
Detecting the behaviour instead
These detections survive the choice of tool, because they describe the outcome rather than the route.
- Files written in registry hive format. The exported hive has a recognisable structure and is rarely created in normal operation. A hive-format file appearing anywhere outside the expected system locations — particularly in a user profile, a temporary directory or a staging folder — is high-signal and low-volume.
- Handle access to the SAM, SYSTEM and SECURITY hives by any process that is not part of normal system operation. Loud if enabled without tuning; very effective once baselined.
- Backup and Restore privilege use. Reading these hives while Windows is running requires privileges that ordinary applications have no reason to invoke. Their use is noteworthy on its own.
- Volume Shadow Copy creation outside a backup window, which is another long-standing route to locked system files.
- Exfiltration shape. Three files, created together, of characteristic sizes, moved off the host shortly afterwards. The movement is often easier to spot than the collection.
- Interactive use of administrative tooling on a server that nobody should be logged into interactively.
Reducing what is worth stealing
Detection catches the attempt. These reduce the reward:
- Windows Defender Credential Guard — isolates LSA secrets using virtualisation-based security. It does not protect the on-disk SAM, but it removes a substantial part of what makes memory and LSA material valuable.
- LAPS — unique, rotated local administrator passwords on every machine. This is the single highest-value control here: it turns a stolen SAM from an estate-wide key into one compromised host.
- Restrict cached domain credentials. Fewer cached logons means less domain material in the SECURITY hive. Balance against laptops that need offline logon.
- Remove standing local administrator rights. All of this requires elevation, so the number of users who can reach it is a control in itself.
- Tiered administration — domain and service accounts should not be logging into workstations, because whatever is cached there becomes recoverable.
- Application control, to constrain which signed binaries can run where, narrowing the set of available routes.
The wider lesson
This is a defence-in-depth argument, but a specific one rather than the usual platitude.
EDR blocking a known tool is a real control and it is worth having. What it is not is a guarantee that the capability is gone — and the gap between those two things is where a lot of intrusions live, because the alert that never fires looks exactly like the attack that never happened.
The practical question for any control is not "does it block the tool we know about", but "what happens when the same outcome is pursued a different way, and would we see it". For credential material on disk, the answer has to come from behavioural detection, from reducing the value of what is stored, and from testing the assumption occasionally rather than trusting it.
That last part is the one most often skipped. A purple team exercise that attempts hive extraction on a representative host answers the only question that matters: did anything alert, did it reach a human, and how long did it take.