Eventually, every internal tool reaches the point where keeping it private stops making sense. That moment has arrived for Swarmer—a tool that enables stealthy modification of the Windows Registry from a low-privilege context. We’ve been using this technique in real-world engagements for almost a year now, and enough time has passed that it feels appropriate to share what we’ve learned, particularly around one of Windows’ dustier and least-discussed features: mandatory user profiles.

The Problem with Registry Persistence

If you’ve done red team work anytime in the last decade, you already know that traditional registry-based persistence has become painfully noisy. Writing to the classic run keys—HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and friends—is something modern EDRs watch obsessively. Touch those keys with a RegSetValue call and you might as well announce your presence over the PA system.

The root of the problem is straightforward: EDRs hook the standard Windows Registry APIs. Calls like RegCreateKey, RegSetValue, and RegOpenKey are monitored, logged, and analyzed in real time. So the obvious question becomes:

How do you get registry persistence without actually touching the registry?

Mandatory User Profiles: Forgotten, Not Gone

Windows is full of legacy features that refuse to die. Mandatory user profiles are one of them.

In enterprise environments, administrators sometimes want a user profile that resets to a known-good state every time a user logs in. To support this, Windows allows the use of a file called NTUSER.MAN (the .MAN stands for mandatory). When present, this file takes precedence over the normal NTUSER.DAT registry hive in %USERPROFILE% during logon.

What’s interesting is that while this sounds like an admin-only feature, there’s nothing technically stopping a regular user from copying a valid NTUSER.DAT, renaming it to NTUSER.MAN, and placing it in their own profile directory. Windows happily loads it at login.

That gives us a foothold—but not a solution yet. We don’t want to reuse an existing hive; we want to modify it.

Unfortunately, NTUSER.DAT can’t be edited while the user is logged in because it’s already loaded into memory. Any changes made through regedit or similar tools hit the same monitored registry APIs we’re trying to avoid. And while the registry hive format exists in the wild, it’s effectively undocumented, brittle, and absolutely not something you want to manipulate by hand.

Falling Down the Offline Registry API Rabbit Hole

So how do you safely modify a valid registry hive file without touching the live registry at all?

The answer lies in yet another piece of Windows legacy infrastructure: the Offline Registry API, implemented in Offreg.dll.

This API exists for things like Windows setup, backup utilities, and forensic tools—situations where you need to read or modify registry hives on disk without loading them into the running system.

Microsoft’s documentation includes a wonderfully stern warning:

Applications should not use the offline registry functions to bypass the security requirements of the system registry.

Naturally, we ignored that.

The Offline Registry API gives us everything we need: ORCreateHive, OROpenHive, ORCreateKey, ORSetValue, and ORSaveHive. Using these functions, we can construct or modify a complete registry hive without invoking a single standard registry API call. Process Monitor sees nothing. ETW sees nothing. And most importantly, EDRs see nothing of interest.

Even better, we don’t need to use these APIs on the target host at all. We can export the user’s HKCU hive using reg export and work entirely offline. If we want to avoid shell commands altogether, any BOF capable of dumping registry keys—such as TrustedSec’s reg_query—works just as well.

Introducing Swarmer

All of this research eventually turned into Swarmer, a tool we’ve been using internally since February 2025.

The basic workflow looks like this:

1. Export the target user’s HKCU registry (via reg export or a BOF-based approach)
2. Modify the exported data however you like
3. Use Swarmer to convert the modified export into a binary registry hive
4. Drop the resulting NTUSER.MAN file into the user’s profile directory

At its simplest: swarmer.exe exported.reg NTUSER.MAN

If you want to add a startup entry in one shot:

swarmer.exe --startup-key "Updater" --startup-value "C:\Path\To\payload.exe" exported.reg NTUSER.MAN

Swarmer can also parse the output of TrustedSec’s reg_query BOF directly, which is useful when you’re operating from a C2 implant and want to avoid touching disk with a .reg file:

swarmer.exe --bof --startup-key "Updater" --startup-value "C:\Path\To\payload.exe" bof_output.txt NTUSER.MAN

Implementation Notes

The implementation ended up being more annoying than we expected.

Calling ORCreateHive directly produces a hive file that Windows refuses to load as a valid NTUSER.MAN. Something about the internal structure doesn’t match what the system expects.

The workaround is to first create an empty hive using RegLoadAppKeyW. This API is legitimate, does not require administrative privileges, and produces a hive file Windows is happy with. Once that file exists, we open it using OROpenHive and populate it using the Offline Registry APIs.

Swarmer is written in C# for a few practical reasons:

• Clean P/Invoke access to Windows APIs
• Easy deployment as either a standalone executable or a PowerShell module
• The ability to run completely offline on an operator machine, if you’re paranoid about even Offreg.dll usage on the target

Example PowerShell usage:

Import-Module '.\swarmer.dll'
Convert-RegToHive -InputPath '.\exported.reg' -OutputPath '.\NTUSER.MAN'

Caveats and Limitations

This technique isn’t magic, and it definitely isn’t risk-free.

• One-shot only: Once NTUSER.MAN exists, the user profile becomes mandatory. You can’t update it without deleting the file, which requires admin privileges. If you want persistence, you need to get it right the first time.
• Requires logoff/logon: The hive is only loaded at login. This isn’t immediate persistence, but it does survive reboots cleanly.
• HKCU only: This affects the user hive, not HKLM. You’re limited to per-user persistence mechanisms.
• Registry corruption is possible: It is absolutely possible to break a profile badly enough that the user can’t log in. Swarmer does not handle every edge case in registry configuration. Test your hives on machines you control before deploying them.
• Detection still exists: While we avoid standard registry APIs, artifacts remain. A new NTUSER.MAN file appearing in a profile directory may be suspicious. An unexpected process loading Offreg.dll could trigger behavioral detections. And once the persistence fires, whatever you launch is visible. These risks can be reduced by building the hive off-host, but writing NTUSER.MAN is hard to completely hide.

Why Share This Now?

We’ve used this technique operationally since February 2025 across Windows 10 and 11 systems, and it’s proven reliable in real engagements. Since the underlying behavior is publicly documented—if obscure—it feels reasonable to give defenders visibility into how it can be abused.

The bigger lesson here isn’t just about mandatory profiles. It’s about the sheer amount of legacy functionality still present in Windows. Features designed decades ago for legitimate administrative reasons often exist entirely outside the assumptions modern security tooling is built on.

For defenders, monitoring for unexpected NTUSER.MAN creation in user profile directories is a good start—especially when it isn’t tied to enterprise profile management. Processes loading Offreg.dll without a clear reason may also be worth scrutiny.