Windows Registry Persistence

Registry-based persistence survives reboots without creating visible scheduled tasks or services. Run keys execute payloads at user login or system startup. More advanced keys like Winlogon and AppInit_DLLs load code deeper in the boot process and are less likely to be caught by basic persistence scans.

Run and RunOnce keys

The most common persistence mechanism. Entries under Run execute every time the user logs in. RunOnce entries execute once and are deleted automatically.

Winlogon persistence

Winlogon keys control what runs during the Windows login process. Appending to Userinit or replacing Shell loads your payload alongside the normal login sequence. Both require admin.

Always preserve the original value in Userinit. If you overwrite it without keeping userinit.exe, the user will not get a desktop on login and the persistence will be obvious. Read the current value first and append with a comma separator.

AppInit_DLLs

DLLs listed in AppInit_DLLs are loaded into every process that loads User32.dll — which is nearly every GUI application. This gives broad execution coverage but is noisy and well-monitored by modern EDR.

AppInit_DLLs is disabled by default when Secure Boot is enabled. Check before relying on it. On modern hardened systems this technique is rarely viable — prefer Run keys or scheduled tasks.

COM object hijacking

COM objects registered under HKCU override system-wide HKLM registrations for the current user. Replacing a COM object's InprocServer32 path with your DLL causes it to load whenever that COM object is instantiated — with no admin required and no Run key visible in standard autoruns checks.

COM hijacking requires identifying which CLSIDs are looked up in HKCU but not found. Use Sysinternals Autoruns with the Hijacks filter enabled — it highlights all COM objects where an HKCU override is possible. The payload must be a DLL, not an EXE.

Cleaning up registry persistence