📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🎓 ETHICAL HACKING COURSE
FREE
Part of the Free Ethical Hacking Course
Day 38 of 100 · 38% complete
⚠️ Legal Disclaimer: Every technique in this article is for authorised use only — lab environments, CTF platforms, and engagements where you have explicit written permission. Never apply these methods to systems you do not own or have not been given permission to test. Unauthorised access is a criminal offence.
The shell died. You rebooted the Windows VM to test something, came back, and your Meterpreter session was gone. No persistence. Back to square one. I’ve watched students lose an entire simulated engagement because they planted a payload, got a shell, and assumed it would still be there after the next reboot. It won’t — unless you do the work. Registry persistence is what keeps your access alive when the system cycles. Not a network-based beacon that dies when the firewall rule reloads. Not a service that gets caught by AV on the next scan. A few registry keys, written in the right places, that make Windows itself execute your payload every single time. That’s what we’re covering today. Three registry persistence mechanisms — Run Keys, COM hijacking, and Boot Execute modifications — that I use regularly in red team engagements because they survive reboots, blend into legitimate OS configuration, and are missed by defenders who focus on process trees and network connections instead of the registry. By the end of this lab, you’ll know how to plant all three, why each one works at the operating system level, and exactly what a defender needs to catch you.
🎯 What You’ll Master in Day 38
Plant HKCU and HKLM Run Key persistence entries that fire on every logon
Hijack COM objects using HKCU CLSID redirection — no admin required
Modify the BootExecute key to load a payload before Windows user-space initialises
Detect and clean up all three techniques the way a blue team would during incident response
⏱️ ~90 minutes · 3 exercises (Think Like Hacker · TryHackMe · Kali Lab) ### Before You Start Day 38 - ✅ Completed Day 37 — Network Persistence — you need that context on persistence categories - ✅ Kali Linux lab up and running (VM or native) - ✅ A Windows 10/11 VM, or access to the TryHackMe room used in Exercise 2 - ✅ Basic registry navigation from Day 32 Windows PrivEsc — know your HKCU from your HKLM ### Day 38 — What We’re Covering 1. Windows Run Keys — The Oldest Trick That Still Works 2. COM Hijacking — Redirecting Windows’ Own Object Model 3. Boot Execute Modifications — Persistence Before Windows Starts 4. Exercise 1 — Think Like a Hacker: Which Mechanism Do You Choose? 5. Exercise 2 — TryHackMe Lab: Registry Persistence in Practice 6. Exercise 3 — Kali Terminal: Plant and Verify Run Key Persistence 7. Commands Used Today — Day 38 Reference Card 8. Frequently Asked Questions Yesterday in Day 37 Network Persistence, we looked at techniques that keep access alive through network-layer mechanisms — scheduled callbacks, firewall rule manipulation, and remote management abuse. Today we go deeper into the operating system itself. Registry persistence is different from everything else we’ve covered because it doesn’t require a service, a scheduled task, or a network connection to fire — it uses Windows’ own configuration database as the trigger. Defenders who focus exclusively on process monitoring and network telemetry walk straight past it. Head back to the Free Ethical Hacking Course hub if you need to catch up on any earlier days, and check the latest articles for any supplementary material published alongside this module.
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:
HKCUSoftwareMicrosoftWindowsCurrentVersionRunHKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
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.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)