Windows Services, Tasks & Persistence

Why Persistence Is the Attacker's Priority

Once an attacker gains initial access to a Windows system, their first concern is survival. A reboot, a user logoff, or a crashed process could sever their foothold entirely. Persistence is the set of techniques attackers use to ensure their code re-executes automatically — surviving reboots, user logoffs, and even some remediation attempts.

Windows provides dozens of legitimate mechanisms for software to start automatically. Each of those mechanisms is a potential persistence vector. Understanding them is not optional for a SOC analyst — it is foundational. If you cannot enumerate every way code can persist on a Windows endpoint, you cannot confidently say a system is clean after an incident.

Click to enlarge

Windows Services Architecture

How the Service Control Manager Works

The Service Control Manager (SCM), running as services.exe, is the central authority for Windows services. Every service on the system — from Spooler to Windows Defender — is registered with and controlled by the SCM.

When Windows boots, the SCM reads the service database from the registry (HKLM\SYSTEM\CurrentControlSet\Services\) and starts each service according to its configured start type:

Service Configuration in the Registry

Every service has a registry key under HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName> containing:

ImagePath    : REG_EXPAND_SZ : C:\Windows\System32\svchost.exe -k netsvcs
Start        : REG_DWORD     : 2  (Automatic)
Type         : REG_DWORD     : 32 (Win32 Share Process)
ObjectName   : REG_SZ        : LocalSystem
Description  : REG_SZ        : "Provides network connectivity..."

The ImagePath value is critical — it specifies the exact binary that runs when the service starts. Attackers who modify this value can execute arbitrary code with the service's privileges (often SYSTEM).

Service Types

Service-Based Persistence

How Attackers Create Malicious Services

Attackers create services using built-in Windows tools, making the activity blend in with legitimate administrative operations:

Using sc.exe (command line):

sc create EvilSvc binPath= "C:\Users\Public\payload.exe" start= auto obj= LocalSystem
sc description EvilSvc "Windows Performance Data Helper"
sc start EvilSvc

Using PowerShell:

New-Service -Name "EvilSvc" -BinaryPathName "C:\Users\Public\payload.exe" -StartupType Automatic -Description "Windows Performance Data Helper"
Start-Service -Name "EvilSvc"

Direct registry manipulation (stealthier):

$key = "HKLM:\SYSTEM\CurrentControlSet\Services\EvilSvc"
New-Item -Path $key -Force
Set-ItemProperty -Path $key -Name "ImagePath" -Value "C:\Users\Public\payload.exe"
Set-ItemProperty -Path $key -Name "Start" -Value 2
Set-ItemProperty -Path $key -Name "Type" -Value 16
Set-ItemProperty -Path $key -Name "ObjectName" -Value "LocalSystem"

Detection: Event ID 7045

When a new service is installed, Windows logs Event ID 7045 in the System event log:

Log Name:      System
Source:        Service Control Manager
Event ID:      7045
Description:   A service was installed in the system.

Service Name:  EvilSvc
Service File Name:  C:\Users\Public\payload.exe
Service Type:  user mode service
Service Start Type:  auto start
Service Account:  LocalSystem

Scheduled Tasks

Task Scheduler Architecture

The Task Scheduler service (Schedule) allows programs to run automatically based on triggers: time-based (daily, weekly), event-based (on logon, on event), or condition-based (on idle, on network connect).

Tasks are stored as XML files in C:\Windows\System32\Tasks\ and in the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\.

Creating Scheduled Tasks

Using schtasks.exe:

schtasks /create /tn "WindowsUpdateCheck" /tr "C:\Users\Public\payload.exe" /sc onlogon /ru SYSTEM

Using PowerShell:

$action = New-ScheduledTaskAction -Execute "C:\Users\Public\payload.exe"
$trigger = New-ScheduledTaskTrigger -AtLogon
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
Register-ScheduledTask -TaskName "WindowsUpdateCheck" -Action $action -Trigger $trigger -Principal $principal

XML Task Definition

Every scheduled task is defined by an XML file. Understanding this structure is essential for forensic analysis:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Triggers>
    <LogonTrigger>
      <Enabled>true</Enabled>
    </LogonTrigger>
  </Triggers>
  <Principals>
    <Principal>
      <UserId>S-1-5-18</UserId>  <!-- SYSTEM -->
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Actions>
    <Exec>
      <Command>C:\Users\Public\payload.exe</Command>
    </Exec>
  </Actions>
</Task>

Detection: Event IDs 4698, 4699, 4702

Registry Run Keys Persistence

The Classic Persistence Mechanism

Registry Run Keys are the most well-known persistence method on Windows. Programs listed in these keys execute automatically during user logon or system startup.

Primary Run Key locations:

Setting a Run Key (attacker perspective):

Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "WindowsHelper" -Value "C:\Users\Public\payload.exe"

Additional Registry Persistence Locations

Beyond the standard Run keys, attackers use these less-monitored locations:

WMI Event Subscriptions

The "Fileless" Persistence Method

Windows Management Instrumentation (WMI) Event Subscriptions are one of the stealthiest persistence mechanisms because they require no files on disk (the payload is stored entirely within the WMI repository database) and no registry modifications that traditional tools would flag.

A WMI persistence implant has three components:

Creating a WMI persistence implant:

$filter = Set-WmiInstance -Namespace "root\subscription" -Class __EventFilter -Arguments @{
    Name = "WindowsCoreUpdate"
    EventNamespace = "root\cimv2"
    QueryLanguage = "WQL"
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240"
}

$consumer = Set-WmiInstance -Namespace "root\subscription" -Class CommandLineEventConsumer -Arguments @{
    Name = "WindowsCoreUpdate"
    CommandLineTemplate = "C:\Users\Public\payload.exe"
}

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

This implant triggers 4 minutes after boot (SystemUpTime >= 240 seconds) and runs the payload. There is no file in a Startup folder, no registry Run key, and no scheduled task visible in Task Scheduler.

Detection: Event ID 5861

Windows 10+ logs WMI Event Subscription activity in the Microsoft-Windows-WMI-Activity/Operational log:

Other Persistence Mechanisms

Startup Folder

The simplest persistence method — drop a shortcut (.lnk) or executable into the Startup folder:

Easy to detect: any executable or shortcut in these folders that was not placed by IT is suspicious.

DLL Search Order Hijacking

When a program loads a DLL without specifying a full path, Windows searches for it in a predictable order:

1. Directory of the calling application
2. System directory (C:\Windows\System32)
3. Windows directory (C:\Windows)
4. Current directory
5. PATH directories

An attacker who places a malicious DLL in the application directory (step 1) can hijack the load order, causing the legitimate application to load the malicious DLL instead of the system version.

COM Object Hijacking

Component Object Model (COM) objects are registered in the registry. Attackers modify COM registration entries to point to malicious DLLs. When a legitimate process instantiates the COM object, it loads the attacker's DLL instead.

Key registry locations: HKCU\SOFTWARE\Classes\CLSID\ and HKLM\SOFTWARE\Classes\CLSID\. The HKCU entries take precedence over HKLM, meaning a standard user can hijack COM objects without admin privileges.

Systematic Persistence Detection

The Detection Checklist

Individual persistence checks are necessary but not sufficient. Attackers layer multiple persistence mechanisms. A thorough audit must check all vectors systematically.

Click to enlarge

Velociraptor: PersistenceSniper Artifact

Velociraptor's Windows.Persistence.PersistenceSniper artifact automates the entire checklist above in a single hunt:

SELECT * FROM Artifact.Windows.Persistence.PersistenceSniper()

This artifact checks over 50 persistence locations including:

• All registry Run/RunOnce keys (including 32-bit and 64-bit views)
• Services with unusual ImagePath values
• Scheduled tasks pointing to non-standard locations
• Active WMI event subscriptions
• Startup folder contents
• Known COM hijack locations
• AppInit_DLLs and IFEO entries
• Boot Execute entries and LSA extensions

Sysinternals Autoruns

Microsoft Sysinternals Autoruns is the gold standard GUI tool for persistence enumeration. It checks over 100 autostart locations and shows:

• The autostart entry location
• The binary or script that runs
• The digital signature status (unsigned binaries are flagged)
• The VirusTotal detection ratio (if enabled)

autorunsc.exe -accepteula -a * -c -h -s -v -vt > autoruns_output.csv

ATT&CK Mapping Summary

What's Next

You now understand the major persistence mechanisms on Windows and how to detect them systematically. In Lesson 3.6: Linux Internals for Defenders, you will shift to the Linux operating system and learn the equivalent persistence techniques — cron jobs, systemd services, init scripts, LD_PRELOAD hijacking, and .bashrc/.profile modifications — along with the detection strategies that SOC analysts use to hunt for Linux persistence in enterprise environments.