Introducing The Month of Bypasses: What Defender Can't See

By the Persistent Security Research Team — April 2026

Introducing the Month of Bypasses

Today we're launching a new series: the Month of Bypasses. We'll publish bypasses for known MITRE attack techniques on a regular basis over the coming 30 days, each one discovered by AI-driven variant analysis using our Nemesis Breach and Attack Simulation (BAS) platform.

Why? Because that's what Defenders are doing right now as well: Using AI automation to revive their proven tool sets. Static BAS testing alone won't cut it anymore!

The rules are simple but strict: every bypass must be a variation of a technique that Defender already catches. We're not switching to a different attack technique: If Defender blocks LSASS credential dumping, our bypass must also dump credentials, just differently enough that Defender doesn't see it. Same MITRE ATT&CK technique ID, same attack objective, different execution path.

This constraint mirrors what real adversaries do. When a defensive product blocks their go-to tool, they don't give up on the technique, they find another way to achieve the same result. Our goal is to show how defenders can stay ahead of that adaptation by understanding where their protections actually apply and where the gaps are before they are exploited by adversaries.

How we find them: Nemesis is our BAS platform with an AI-driven variant analysis for techniques, it executes them in parallel, measures the result (blocked or not blocked), and iterates. All this works because in Nemesis there's a clear definition of success and the ability to try many approaches quickly, repeatably and deterministically. Think of it as a fuzzer for defensive products.

Over this series, we'll cover bypasses across credential access, defense evasion, persistence, execution, and more. Each post will include full technical detail, the code, and — critically — what defenders should do about it.

Let's take a Windows 11 System with latest Defender for Endpoint in default configuration. The system has a critical gap that it shares with a lot of virtualized installations and we would hope Defender closes it at least to some extent: There's no PPL / Credential Guard enabled. To kick off Nemesis variant and evasion analysis we're starting with a proven technique that is part of nearly any ransomware attack affecting Windows clients and every red teaming exercise in Active Directory:

What Defender Blocks: SAM Hive Extraction (T1003.002)

MITRE ATT&CK technique T1003.002, OS Credential Dumping: Security Account Manager, targets the SAM database that stores local account password hashes. SAM by itself is encrypted, the SYSTEM hive holds the boot key needed to decrypt it. Get both, run them through any offline parser, and you have NTLM hashes for every local account on the box. From there: pass-the-hash to other machines that share the local admin password, offline cracking for plaintext recovery, and lateral movement on networks where LAPS isn't deployed.

The SAM file at C:\Windows\System32\config\SAM is held open exclusively by the kernel while Windows is running. Any extraction has to either go through a registry-aware API, snapshot the volume, or get the file out from a state where it isn't locked. Defender knows the standard playbook and blocks the obvious paths.

Block 1: reg save, behavior monitoring catches it

ProcDump is a Microsoft-signed Sysinternals tool designed for process memory dumps. It's legitimate software that passes Defender's file scanning without issue — no quarantine, no signature match. But when ProcDump targets lsass.exe with the -ma (full dump) flag:

C:\> reg save HKLM\SAM sam.save
C:\> reg save HKLM\SYSTEM sys.save

Defender's behavior monitoring treats reg save against HKLM\SAM or HKLM\SYSTEM as a high-fidelity credential theft signal. The operation is blocked, the parent process is flagged, and an alert is raised in the security console.

Block 2: vssadmin plus copy from shadow, blocked by behavior monitoring

The shadow copy approach creates a VSS snapshot, then copies the SAM hive out from the shadow path where it isn't locked:

C:\> vssadmin create shadow /for=C:
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .

Defender watches for this exact sequence: a process creating a shadow copy followed by a read against config\SAM or config\SYSTEM from the shadow path. The combination, not the individual operations, is what triggers detection. Both files are blocked from being copied out.

Block 3: Direct file copy, locked file

The naive approach fails for a different reason entirely:

C:\> copy C:\Windows\System32\config\SAM sam.bak
The process cannot access the file because it is being used by another process.

No matter the privilege level, the kernel holds an exclusive handle and a normal CreateFile for read access fails.

So reg save is hooked, the vssadmin chain is detected by behavior, and direct reads are blocked by the lock itself. The standard toolkit is closed off. The game is over.

Or is it?

How Nemesis AI Found the Gap

We put the Nemesis agentic AI onto this job the way a scientist approaches an experiment: form a hypothesis, test it, observe the result, refine, repeat.

Generation 1: WMI shadow copy via Win32_ShadowCopy

Hypothesis: Defender's signature on the vssadmin chain is process-name driven. If we create the shadow copy via WMI instead, we sidestep vssadmin.exe and the detection should not fire.

The variant called the WMI class directly:

powershell

$class = [WMICLASS]"root\cimv2:Win32_ShadowCopy"
$class.Create("C:\", "ClientAccessible")

The shadow was created without alerting. But the moment Copy-Item ran against \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM, Defender blocked the read.

Observation: The detection isn't on vssadmin, it's on the access pattern to config\SAM and config\SYSTEM reached via a shadow copy path, regardless of how the shadow was created.

Generation 2: P/Invoke RegSaveKeyEx with SE_BACKUP_NAME

Hypothesis: If reg save is blocked at the user-mode binary level, calling RegSaveKeyEx directly via P/Invoke from compiled C# should bypass the signature on reg.exe.

The variant enabled SeBackupPrivilege, opened HKLM\SAM with RegOpenKeyEx, and called RegSaveKeyEx with REG_LATEST_FORMAT. Same outcome as reg save: the call was blocked. Defender's hook is on the privileged save operation against the SAM/SYSTEM keys at the kernel transition, not on the user-mode binary that invokes it.

Observation confirmed: any explicit save-style API targeting HKLM\SAM or HKLM\SYSTEM is caught regardless of caller.

Generation 3: esentutl /y /vss

This is where the LOLBIN catalog earns its keep. The AI had now established the shape of Defender's detection surface for T1003.002:

• vssadmin and Win32_ShadowCopy plus a read of config\SAM from a shadow path: detected on the access pattern

• reg save, RegSaveKeyEx, anything that names the SAM key in a save API: hooked at the kernel transition

• Direct file open: fails on the lock

The signal across all three is the combination of (mechanism, named target). What's missing from this picture is a tool that:

1. Is signed by Microsoft and ships with Windows

2. Has a documented, legitimate reason to copy files using VSS internally

3. Doesn't go through the registry save APIs

4. Doesn't trigger the behavior rule on vssadmin plus shadow access

esentutl.exe fits all four. It's the Extensible Storage Engine utility, primarily used for Exchange and Active Directory NTDS.dit maintenance. It supports a /y flag ("copy a database in safe mode") and a /vss flag that internally creates a shadow copy via the VSS COM API and reads the source through it. The combination doesn't invoke vssadmin, doesn't touch the registry save path, and the access to config\SAM is mediated by a Microsoft-signed binary using its documented switches.

The Bypass:

esentutl.exe /y /vss C:\Windows\System32\config\SAM    /d .\sam_dump
esentutl.exe /y /vss C:\Windows\System32\config\SYSTEM /d .\sys_dump

Result	Defender Detection	Behavior Block	Exit Code
SAM and SYSTEM hives copied to the working directory in roughly two seconds.	none	none	0: NOT PREVENTED

What Defenders Should Do

Closing this gap means watching the access pattern to config\SAM and config\SYSTEM independent of which tool mediated it, plus restricting esentutl to the narrow set of contexts where it's actually needed.

1. Restrict execution with AppLocker or WDAC

esentutl.exe has no legitimate business on a typical workstation or member server. Block it for non-admin users via AppLocker or Windows Defender Application Control. On domain controllers and Exchange servers where it does have a legitimate role, restrict execution to scheduled maintenance windows and known administrator accounts.

2. Sysmon Event ID 1 with command-line filtering

A Sysmon rule that fires on esentutl.exe with /vss in the command line is high-fidelity. Pair it with file creation events for typical output paths (current working directory, %TEMP%, user profile) and the alert is actionable: legitimate ESE database backups go to known backup paths, not to .\sam_dump in a user's home directory.

3. Monitor Volume Shadow Copy creation by non-system processes

Any non-backup user-mode process creating a shadow copy is suspicious. Backup software is well-known and stable in any given environment. Shadow copies created by powershell.exe, cmd.exe, esentutl.exe, wmic.exe, or arbitrary user processes should generate alerts. The Microsoft-Windows-VolumeSnapshot-Driver ETW provider gives kernel-level visibility into shadow operations regardless of which user-mode tool initiated them, EDR products that consume this provider catch the operation even when the tool itself is benign.

4. LAPS for local administrator accounts

Credential Guard protects domain credentials in LSASS, it does not protect local SAM hashes. For local accounts the right answer is LAPS, unique randomly-generated frequently-rotated local admin passwords managed centrally. Even when SAM is dumped, the extracted hash is useful only on that one machine and only until the next rotation. This neutralizes the most damaging downstream consequence of T1003.002, lateral movement via shared local admin passwords.

5. Disable VSS where it isn't needed

On systems that don't use System Restore or VSS-aware backup software, the Volume Shadow Copy service can be disabled outright. This kills esentutl /vss, vssadmin-based extraction, Win32_ShadowCopy, and every other VSS-mediated technique in a single configuration change. Test in your environment, some endpoint backup agents depend on VSS being available on demand.

The Broader Lesson

Defender's SAM protection is built around named techniques: reg save, vssadmin plus copy, mimikatz signatures, P/Invoke against the registry save APIs, you name it.

But using a legitimate binary shows that signature-based defense lags behind LOLBIN abuse as well as the behavioural detection: the tool is signed, the flags are documented, the access path doesn't match any of the existing rules.

The defensive answer isn't another tool-specific signature, it's monitoring the data access pattern itself, any non-standard process reaching config\SAM or config\SYSTEM via any path.

ETW providers and behavior-based EDR rules that key on outcome rather than mechanism close these gaps more reliably than hooks ever will.

What's Next

We'll look at a different other detection layer such as AMSI (the Antimalware Scan Interface) and potentially other products, let's see where this journey will take us!

The Month of Bypasses is a research project by the Persistent Security team. All findings that are based on actual vulnerabilities are disclosed through the Belgian Coordinated Vulnerability Disclosure (CVD) framework via the Centre for Cybersecurity Belgium (CCB). Nemesis BAS is available at persistent-security.net.

Have questions or want to test your own defenses? Contact us at info@persistent-security.net.