Detecting Windows persistence techniques with Wazuh

Persistence techniques refer to methods attackers or malicious software use to maintain access to a compromised endpoint even after reboots, logouts, or other interruptions. These techniques ensure that the malware or unauthorized user remains active and can continue to execute malicious activities without re-exploitation.

Common Windows persistence techniques involve modifying startup scripts, abusing scheduled tasks and legitimate system services, or tampering with registry keys. Attackers often exploit these methods to establish long-term control over compromised systems, enabling data exfiltration, spying, and encryption of sensitive data.

This blog post covers how Wazuh can detect common persistence techniques that malicious actors use to maintain access to compromised Windows endpoints.

Infrastructure

We use the following infrastructure to demonstrate the detection of Windows persistence techniques with Wazuh:

• A pre-built, ready-to-use Wazuh OVA 4.11.2, which includes the Wazuh central components (Wazuh server, Wazuh indexer, and Wazuh dashboard). Follow this guide to download and set up the Wazuh virtual machine.
• A Windows 11 endpoint with the Wazuh agent 4.11.2 installed and enrolled to the Wazuh server. We monitor this endpoint to detect the persistence techniques.

Sysmon configuration

Sysmon (System Monitor) is a Windows system utility from Microsoft’s Sysinternals suite that provides detailed event logging to help monitor and analyze system activity. It logs detailed information about process creation, network connections, file and registry changes, and other low-level events into the Windows event log. 

Follow the steps below to configure Sysmon on the monitored Windows endpoint and forward logs from the Sysmon event channel to the Wazuh server for analysis:

1. Download the latest version of Sysmon from the Microsoft Sysinternals page.
2. Extract the compressed Sysmon file to your preferred location.

> Expand-Archive "<PATH>\Sysmon.zip"

Replace <PATH> with the directory where the Sysmon.zip file was downloaded.

3. Download the Sysmon configuration file using PowerShell as an administrator. Replace <SYSMON_EXECUTABLE_PATH> with the path to your Sysmon executable:

> wget -Uri https://wazuh.com/resources/blog/emulation-of-attack-techniques-and-detection-with-wazuh/sysmonconfig.xml -OutFile <SYSMON_EXECUTABLE_PATH>\sysmonconfig.xml

4. Switch to the folder containing the Sysmon executable. Run the command below to install and start Sysmon:

> .\Sysmon64.exe -accepteula -i sysmonconfig.xml

5. Add the following configuration within the <ossec_config> block of the C:\Program Files (x86)\ossec-agent\ossec.conf file to forward Sysmon events to the Wazuh server:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

6. Restart the Wazuh agent to apply the changes:

> Restart-Service -Name wazuh

Common persistence techniques and detection with Wazuh

The MITRE ATT&CK® framework, which stands for MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), is a knowledge base for modeling the behavior of a cyber adversary. Some commonly used MITRE persistence techniques on Windows endpoints include the following:

• T1053.005 – Scheduled Task/Job: Scheduled Task
• T1136 – Create Account
• T1543.003 – Create or Modify System Process: Windows Service
• T1546.011 – Event Triggered Execution: Application Shimming
• T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
• T1547.004 – Boot or Logon Autostart Execution: Winlogon Helper DLL

T1053.005 – Scheduled Task/Job: Scheduled Task

This technique abuses the Windows Task Scheduler utility to automate the execution of malicious code. Threat actors can run the schtasks utility directly on the command line or the Task Scheduler utility. This allows adversaries to maintain persistence or escalate privileges at specific times or when particular conditions are met.

Detection rules

Wazuh provides the built-in rule 92154 that is triggered when a process loads the Task Scheduler service on Windows:

Attack simulation

Run the following command on the Windows endpoint using PowerShell with administrator privileges to simulate persistence with a scheduled task. This command creates a scheduled task named T1053_005 that launches calc.exe (the calculator app) from the command line cmd.exe, every time a user logs on:

> schtasks /create /tn "T1053_005" /sc onlogon /tr "cmd.exe /c calc.exe"

By default, Wazuh detects when a new task is scheduled on a Windows endpoint. You can see the following alerts with rule ID 92154 generated on the Wazuh dashboard.

After successfully simulating this technique, remove the scheduled task with the command below using PowerShell with administrator privileges:

> schtasks /delete /tn "T1053_005" /f

T1136 – Create Account

Malicious actors may create new user accounts on compromised endpoints to maintain persistence. With adequate permissions, these accounts can be used to create additional accounts that do not require persistent remote access tools. These accounts can be created locally, within a domain, or in a cloud environment. 

Detection rules

Wazuh provides the following built-in rules to detect changes to user accounts and group memberships:

• Rule ID 60110 – when a user account is changed.
• Rule ID 60109 – when a user account is enabled or created.
• Rule ID 60160 – when the domain users group changes.

Attack simulation

Run the command below on the Windows endpoint using PowerShell with administrator privileges to simulate the new account. The command creates a new local account with the username T1136 without assigning a password:

> New-LocalUser -Name "T1136" -NoPassword

Navigate to Threat Hunting > Events to view the alerts on the Wazuh dashboard. 

After simulating this technique, remove the newly created user with the command below:

> Remove-LocalUser -Name "T1136"

T1543.003 – Create or Modify System Process: Windows Service

When a Windows system boots, it launches background programs known as services that handle various system functions. Adversaries can create a new service or modify an existing one to automatically run malicious programs at startup, thereby maintaining persistence on an endpoint. Service configurations can be created or altered using system tools like sc.exe, by editing the Windows Registry, or through the Windows API.

Detection rules

Wazuh provides the built-in rule 92307 that is triggered when there is evidence of new service creation in the Windows registry.

Attack simulation

Run the following command in the Windows Command Prompt as an administrator to simulate persistence via Windows service modification. The command uses the sc config utility to change the binary path of an existing Windows service named TapiSrv (Telephony service) to the PowerShell path:

> sc config TapiSrv binPath= "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

Navigate to Threat Hunting > Events to view the alerts on the Wazuh dashboard. Wazuh detects Windows service modification with rule ID 92307 on the Wazuh dashboard.

After simulating this technique, run the following command in Command Prompt as an administrator on the endpoint. The command restores the original binary path of the Telephony service:

> sc config TapiSrv binPath= "C:\WINDOWS\System32\svchost.exe -k NetworkService -p"

T1546.011 – Event Triggered Execution: Application Shimming

Adversaries may abuse application shims to gain persistence or escalate privileges on Windows systems. Application shimming is a Microsoft feature that ensures compatibility between older applications and newer Windows versions by redirecting or altering app behavior without modifying the original code.

Shims are stored in shim databases (.sdb files) and installed using the sdbinst.exe utility. When an application runs, Windows checks the shim cache to see if the program requires the use of the shim database. If so, the shim database uses hooking to redirect the code as necessary to communicate with the OS.

Shims run in user mode and require administrator privileges to install. However, adversaries can exploit specific shim types to bypass User Account Control (UAC), inject malicious DLLs, disable protections, or hijack execution flow. This makes sdbinst.exe a potential tool for attackers to gain persistence on a system by silently applying malicious shims.

Detection rules

Wazuh provides the built-in rule 92058 that is triggered when the application compatibility database is launched 

Attack simulation

We install the AtomicShim shim database to simulate this technique. The shim database file, provided by Atomic Red Team, is used in adversary emulation to demonstrate Application shimming. Follow the steps below to simulate the persistence technique.

1. Download the shim database file using PowerShell with administrator privileges:

> Invoke-WebRequest -Uri "https://github.com/redcanaryco/atomic-red-team/raw/master/atomics/T1546.011/bin/AtomicShimx86.sdb" -OutFile "C:\AtomicShimx86.sdb"

2. Install the database file:

> sdbinst.exe C:\AtomicShimx86.sdb

Navigate to Threat Hunting > Events to view the alerts on the Wazuh dashboard. Wazuh detects the Application shim database installation with rule ID 92058. 

After simulating this technique, run the following commands using PowerShell with administrator privileges to uninstall the shim database and remove the file from the endpoint:

> sdbinst.exe -u C:\AtomicShimx86.sdb
> Remove-Item -Path "C:\AtomicShimx86.sdb" -Force

T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder

Attackers maintain persistence by adding malicious programs to startup folders or Registry run keys. When a user logs in, any entry added to these “run keys” or the startup folder triggers the associated program to be executed. These programs run with the permissions of the user account they are tied to.

Windows endpoints have the following system-wide run keys created by default:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

Placing a program in a startup folder causes it to run automatically when a user logs in. Windows uses the following system-wide startup folders for all users:

• C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp.

Detection rules

Wazuh provides a File Integrity Monitoring (FIM) capability that helps security analysts track changes to sensitive system files, directories, and Windows Registry files in real-time. Wazuh monitors the startup folder and registry run keys of all users by default using the FIM module. You’ll find the setting below in the Wazuh agent configuration file C:\Program Files (x86)\ossec-agent\ossec.conf, on the monitored endpoint:

<syscheck>
  <frequency>43200</frequency>
  <directories realtime="yes">%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup</directories>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce</windows_registry>
</syscheck>

Wazuh provides the following built-in rules to detect file modification, deletion and addition in a monitored directory: 

• Rule ID 550 – When a file is modified in the monitored directory. 
• Rule ID 553 – When a file is deleted in the monitored directory. 
• Rule ID 554 – When a file is added to the monitored directory. 
• Rule ID 92226 – When the PowerShell process copies an executable file to the Windows start-up folder.

Attack simulation

Follow the steps below to simulate an attacker using the startup folder for persistence.

1. Download the EICAR test file with PowerShell to the monitored startup folder using the command below:

> Invoke-WebRequest -Uri https://secure.eicar.org/eicar.com.txt -OutFile "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\eicar.com.txt"

2. Delete the file from the Windows endpoint:

> Remove-Item "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\eicar.com.txt"

The Wazuh FIM module detects the addition and removal of the test file from the startup folder. To view these alerts, go to Threat Hunting > Events on the Wazuh dashboard, you will see alerts with rule IDs 553, 92226, 550, and 554.

T1547.004 – Boot or Logon Autostart Execution: Winlogon Helper DLL

The Winlogon utility is a Windows component responsible for actions at logon/logoff, as well as the Secure Attention Sequence (SAS) triggered by Ctrl-Alt-Delete. Adversaries can abuse Winlogon features to run malicious code each time a user logs in. Windows endpoints have the following Winlogon registry keys to manage additional helper programs and functionalities that support Winlogon.

• HKLM\Software[\Wow6432Node\]\Microsoft\Windows NT\CurrentVersion\Winlogon\
• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\

Malicious modifications to these registry keys may cause Winlogon to load and execute malicious DLLs and/or executables. The following subkeys have been known to be possibly vulnerable to abuse:

• Winlogon\Notify – Loads DLLs for handling logon events.
• Winlogon\Userinit – Loads userinit.exe, the user initialization program executed when a user logs on.
• Winlogon\Shell – Loads explorer.exe, the system shell executed when a user logs on.

Detection rules

The Wazuh FIM capability can help security teams track changes to the Winlogon Registry keys. Wazuh monitors the Winlogon run keys of all users on the endpoint by default using the FIM module. You’ll find the setting below in the Wazuh agent configuration file C:\Program Files (x86)\ossec-agent\ossec.conf on the monitored Windows endpoint.

<syscheck>
  <frequency>43200</frequency>
   <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon</windows_registry>
</syscheck>

Wazuh provides the built-in rule 594 that is triggered when the integrity checksum of a monitored Windows Registry key changes. 

Attack simulation

Run the command below to simulate the persistence of the Winlogon Userinit key. The command will modify the Winlogon registry value to execute cmd.exe upon logon/logoff. 

> Set-ItemProperty "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\" "Userinit" "Userinit.exe, C:\Windows\System32\cmd.exe" -Force

The Wazuh FIM module detects modifications to monitored Windows registry values. To view these alerts, go to File Integrity Monitoring > Events on the Wazuh dashboard, you will see alerts with the rule ID 594.

After simulating this technique, run the following command using PowerShell with administrator privileges on the endpoint to restore the correct binary path of the Userinit utility:

> Set-ItemProperty "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\" "Userinit" "Userinit.exe, C:\Windows\system32\userinit.exe" -Force

Conclusion

This blog post shows how Wazuh uses out-of-the-box rules to detect several techniques used by adversaries to maintain persistence on compromised Windows endpoints. We enriched logs from the victim endpoint by integrating Sysmon logs with Wazuh. We also demonstrated how Wazuh can help security teams detect these persistence techniques using log analysis and file integrity monitoring capabilities.

If you have any questions about this blog post or Wazuh, we invite you to join our community, where our team can assist you.

Reference

Atomic Red Team Tests

Persistence, Tactic TA0003 – Enterprise | MITRE ATT&CK®