Persistence Mechanisms: Scheduled Tasks, Registry

Persistence mechanisms are techniques used by attackers to ensure continued access to a compromised system after initial exploitation. In the context of the PT0-002 exam, persistence is part of the 'Attacks and Exploits' domain (Objective 3.4: 'Given a scenario, perform post-exploitation techniques'). The goal is to maintain access even if the system is rebooted, the user logs off, or credentials are changed. Without persistence, an attacker would need to re-exploit the system after every reboot, which is unreliable and noisy.

Windows Task Scheduler is a built-in service that allows users to schedule automated tasks. An attacker can create a scheduled task that executes a payload (e.g., a reverse shell) at a specific time or triggered by an event (e.g., system startup, user logon).

Key Components: - Task Scheduler Service (Schedule): Runs as svchost.exe and manages task execution. - Task XML Definition: Tasks are stored in %SystemRoot%\System32\Tasks as XML files. The XML contains triggers, actions, conditions, and settings. - Triggers: Common triggers for persistence include: - TimeTrigger: At a specific time (e.g., every day at 3 AM). - LogonTrigger: When any user logs on. - BootTrigger: At system startup. - RegistrationTrigger: When the task is created or modified. - Actions: Typically execute a program (e.g., cmd.exe /c payload.exe). - Security Context: Tasks can run as SYSTEM, Administrator, or a specific user. For stealth, attackers often use high-integrity accounts.

Creation Tools: - schtasks.exe: The command-line tool for creating, querying, and deleting tasks. - Create a task that runs at logon:

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

- Create a task that runs every hour:

schtasks /create /tn "Updater" /tr "C:\Users\Public\malware.exe" /sc hourly /mo 1 /ru SYSTEM

- PowerShell: New-ScheduledTask, Register-ScheduledTask cmdlets.

$action = New-ScheduledTaskAction -Execute "C:\Users\Public\malware.exe"
  $trigger = New-ScheduledTaskTrigger -AtStartup
  Register-ScheduledTask -TaskName "Updater" -Action $action -Trigger $trigger -RunLevel Highest

Detection and Removal: - List all tasks:

schtasks /query /fo LIST /v

- Delete a task:

schtasks /delete /tn "Updater" /f

- PowerShell:

Get-ScheduledTask | Where-Object {$_.TaskPath -notlike "\Microsoft\*"} | Unregister-ScheduledTask -Confirm:$false

Registry run keys are locations in the Windows Registry that specify programs to run automatically when a user logs on or when the system starts. Attackers add entries to these keys to execute their payloads.

Key Locations: - Current User (HKCU): - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce - Local Machine (HKLM): - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices (for services, less common) - 64-bit vs 32-bit: On 64-bit systems, there are also Wow6432Node paths for 32-bit applications: - HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

Mechanism: - During user logon, winlogon.exe loads the user's profile and processes the Run and RunOnce keys. For HKLM, the system processes these keys at boot time. - RunOnce keys are executed once and then deleted, but attackers can abuse them by setting a value that re-creates the key after execution. - Values are typically REG_SZ or REG_EXPAND_SZ containing the path to the executable.

Creation Tools: - reg.exe: Command-line registry editor.

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Backdoor" /t REG_SZ /d "C:\Users\Public\malware.exe"

- PowerShell:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Backdoor" -Value "C:\Users\Public\malware.exe"

Detection and Removal: - Use reg query to list keys:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"

- Delete a value:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Backdoor" /f

- Autoruns (Sysinternals): The autorunsc.exe tool lists all auto-start locations, including registry run keys, scheduled tasks, services, etc. This is the gold standard for detection.

autorunsc.exe -a -c -h > autoruns.csv

Scheduled tasks and registry run keys are often used together. For example, an attacker might use a scheduled task to re-add a registry run key if it gets deleted. Additionally, other persistence mechanisms like service creation (sc.exe), startup folder entries, and WMI event subscriptions can complement these methods. On the exam, you may be asked to identify which persistence mechanism is being used based on the description of the trigger or storage location.

- Check scheduled task status:

schtasks /query /tn "Updater" /v | findstr "Status"

- Check registry run keys for all users:

reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
  reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"

- Use PowerShell to search for common persistence locations:

Get-CimInstance -ClassName Win32_StartupCommand | Select-Object Name, Command, Location, User

A penetration tester successfully phishes an employee at a regional bank and gains a foothold on a workstation. The tester needs to maintain access for lateral movement to the core banking server. The workstation has endpoint protection that scans new files but does not monitor scheduled tasks. The tester creates a scheduled task named 'AdobeFlashUpdate' that runs every hour as the current user, executing a PowerShell one-liner that downloads and runs a reverse shell from a command-and-control server. The task is hidden by placing it in the \Microsoft\Windows\ task folder (e.g., \Microsoft\Windows\Update\), which is often ignored by administrators. The tester also adds a registry run key under HKCU as a backup, but the scheduled task is the primary persistence because it survives reboots and runs even if the user logs off (if set to run as SYSTEM). The key consideration: the task must run with sufficient privileges to allow lateral movement. The tester uses schtasks /create /ru SYSTEM to escalate privileges via the task.

A hospital still runs Windows 7 on some medical devices. A tester exploits a vulnerability in a legacy application and gains SYSTEM access. Because the system is heavily locked down with group policies that restrict scheduled task creation, the tester opts for registry run keys under HKLM. They add a value under HKLM\Software\Microsoft\Windows\CurrentVersion\Run that launches a service installer (sc.exe create Backdoor binPath= "C:\ProgramData\malware.exe"). The service starts automatically, providing persistence. However, the tester must be careful: on Windows 7, the Run key is processed before the user logs on, so the payload runs as SYSTEM. The tester also adds a RunOnce key that re-creates the Run key if it is deleted. In production, this method is noisy because it modifies the registry, but on legacy systems without advanced monitoring, it is effective.

A common mistake is using the 'AtLogon' trigger when the attacker wants persistence at boot. 'AtLogon' runs when a user logs on, but if the system is set to auto-logon, it works. However, if the system is a server that rarely has interactive logons, the task may never run. The correct trigger for boot-time persistence is 'AtStartup'. In one engagement, a tester used 'AtLogon' on a domain controller that had no interactive logons; the task never executed. The fix was to change the trigger to 'AtStartup' and run as SYSTEM.