Monitoring running processes
In this use case, we configure ThreatLockDown agents to run commands locally to monitor running processes on Windows, Linux, and macOS endpoints. Then, we create custom rules on the ThreatLockDown server to generate alerts when a particular process is running or not.
Monitoring running processes on Windows endpoint
We configure the Command module to monitor running processes on the Windows endpoint and alert if the notepad.exe
process is running.
Configuration
Windows endpoint
Perform the following steps to configure the Command module to run a batch script on the Windows endpoint.
Create a batch script named
tasklist.bat
in theC:\
directory of the Windows endpoint and add the following content. The script adds atasklist
header to the output of thetasklist
command:@Echo Off setlocal enableDelayedExpansion for /f "delims=" %%a in ('powershell -command "& tasklist"') do ( echo tasklist: %%a ) exit /b
Append the following configuration to the ThreatLockDown agent’s
C:\Program Files (x86)\ossec-agent\ossec.conf
file. Thetasklist
command lists running processes on Windows endpoints:<ossec_config> <wodle name="command"> <disabled>no</disabled> <tag>tasklist</tag> <command>PowerShell.exe C:\tasklist.bat</command> <interval>2m</interval> <run_on_start>yes</run_on_start> <timeout>10</timeout> </wodle> </ossec_config>
Where:
The
PowerShell.exe C:\tasklist.bat
value in the<command>
tag is the command to be executed by the Command module. As seen, the PowerShell executable is used to execute theC:\tasklist.bat
script.The value
2m
in the<interval>
tag indicates that the Command module runs the command every 2 minutes.
Restart the ThreatLockDown agent to apply the changes, using PowerShell with administrator privileges:
> Restart-Service -Name wazuh
ThreatLockDown server
Configure the ThreatLockDown server with a custom decoder and rule to analyze the events received from the Windows endpoint using the steps below.
Add the following decoder to the
/var/ossec/etc/decoders/local_decoder.xml
file:<decoder name="tasklist"> <prematch>^tasklist: </prematch> </decoder>
Add the rule below to the
/var/ossec/etc/rules/local_rules.xml
file to generate an alert when thenotepad.exe
process is running:<group name="process_monitor,"> <rule id="100010" level="6"> <decoded_as>tasklist</decoded_as> <regex type="pcre2">(?i)notepad.exe</regex> <description>Notepad.exe is running.</description> </rule> </group>
Restart the ThreatLockDown manager to apply the changes:
$ sudo systemctl restart wazuh-manager
Test the configuration
Trigger the alert by launching the Notepad application on the Windows endpoint.
Visualize the alerts
Go to Threat Hunting module on the ThreatLockDown dashboard to visualize the generated alerts when the monitored command runs.
Monitoring running processes on Linux endpoint
Linux endpoints run a number of processes by default including the Cron daemon. For this endpoint, we monitor the running processes using the Logcollector module and alert if the /usr/sbin/cron
process is not running as expected. We use the ps
command to get the status of active processes on the Linux endpoint.
Configuration
Perform the following steps on the respective endpoints to check if the Cron daemon is not running as expected.
Linux endpoint
Configure this endpoint to monitor the status of the running processes every two minutes and forward its output to the ThreatLockDown server for analysis.
Append the Logcollector module configuration below to the ThreatLockDown agent
/var/ossec/etc/ossec.conf
file:<ossec_config> <localfile> <log_format>full_command</log_format> <command>ps -auxw</command> <frequency>120</frequency> </localfile> </ossec_config>
Where:
The
full_command
value in the<log_format>
tag specifies the output of the command is read as a single event.The value
ps -auxw
in the<command>
tag specifies the command the Logcollector module executes.The value
120
in the<frequency>
tag specifies the command runs every 120 seconds (2 minutes).
Restart the ThreatLockDown agent service to apply the changes:
$ sudo systemctl restart wazuh-agent
ThreatLockDown server
Configure the ThreatLockDown server with custom rules to analyze the events received from the Linux endpoint using the steps below.
Add the rules below to the
/var/ossec/etc/rules/local_rules.xml
file. The rules generate an alert when the/usr/sbin/cron
process is not running as expected:<group name="process_monitor,"> <rule id="100012" level="6"> <if_sid>530</if_sid> <match>^ossec: output: 'ps -auxw'</match> <description>Cron process not running.</description> </rule> <rule id="100013" level="0"> <if_sid>100012</if_sid> <match>/usr/sbin/cron</match> <description>Cron process is running as expected.</description> </rule> </group>
The first rule with ID
100012
generates an alert ("Cron process not running.
") unless it is overridden by its child rule with ID100013
that matches/usr/sbin/cron
in the command output. You can add as many child rules as needed to enumerate all of the important processes you want to monitor.Restart the ThreatLockDown manager to apply the changes:
$ sudo systemctl restart wazuh-manager
Test the configuration
Trigger the alert by stopping the Cron process on the Linux endpoint with the command below:
$ sudo systemctl stop cron
Visualize the alerts
Go to Threat Hunting module on the ThreatLockDown dashboard to visualize the generated alert when the Cron process is not running.
Monitoring running processes on macOS endpoint
Monitoring running processes on macOS endpoints is similar to that of Linux endpoints. For this use case, we monitor if a particular process is running using the Logcollector module. Unlike the configuration for the Windows and Linux endpoints which filters the command output using rules, the configuration for this endpoint filters the command output using the configured command itself. This method reduces the command output result and streamlines rule creation. The configuration also introduces the alias
attribute of the Logcollector module.
Configuration
macOS endpoint
Perform the following steps to configure the ThreatLockDown Logcollector module to check if the calendar application Calendar.app
or calendar.app
is running.
Append the following configuration to the ThreatLockDown agent
/Library/Ossec/etc/ossec.conf
file:<ossec_config> <localfile> <log_format>full_command</log_format> <command>ps auxw | grep -i [C]alendar.app</command> <alias>check_calendar_status</alias> <frequency>120</frequency> </localfile> </ossec_config>
Where:
The
full_command
value in the<log_format>
tag specifies the output of the command is read as a single event.The value
ps auxw | grep -i [C]alendar.app
in the<command>
tag is the command the Logcollector module executes to check the state of the Calendar application.The value
check_calendar_status
in the<alias>
tag is a string that represents theps auxw | grep -i [C]alendar.app
command for better identification.The value
120
in the<frequency>
tag specifies the command runs every 120 seconds (2 minutes).
Restart the ThreatLockDown agent service to apply the changes:
# /Library/Ossec/bin/wazuh-control restart
ThreatLockDown server
Configure the ThreatLockDown server with a custom rule to analyze the Calendar application events received from the macOS endpoint using the steps below.
Add the following rules to the
/var/ossec/etc/rules/local_rules.xml
file on the ThreatLockDown server. The rule only matches the stringossec: output: 'check_calendar_status'
in the command output as only one log is generated from the Logcollector configuration specified above:<group name="process_monitor,"> <rule id="100013" level="6"> <if_sid>530</if_sid> <match>^ossec: output: 'check_calendar_status'</match> <description>Calendar is running.</description> </rule> </group>
Restart the ThreatLockDown manager to apply the changes:
$ sudo systemctl restart wazuh-manager
Test the configuration
Trigger the alert by launching the Calendar application on the macOS endpoint.
Visualize the alerts
Go to Threat Hunting module on the ThreatLockDown dashboard to visualize the generated alert.