Configuration

How to configure the Command module

The Command module configuration consists of the command or script, the status of the command, the interval of execution of the command, and the checksum of the script.

To use the ThreatLockDown command monitoring capability, you first need to configure the system to monitor the command's output. This can be a central configuration on the ThreatLockDown server or locally on the endpoints. Once the command is configured, you can then create custom rulesets to process the output and trigger an alert.

For example, we use the Command module to monitor running processes on a Windows endpoint and alert if the notepad.exe process is running. Follow the steps below to configure the module.

1. Create a batch script named tasklist.bat in the C:\ root directory of the Windows endpoint and add the following content. The script adds a tasklist header to the output of the tasklist command:

   @Echo Off
   setlocal enableDelayedExpansion
   
   for /f "delims=" %%a in ('powershell -command "& tasklist"') do (
       echo tasklist: %%a
   )
   
   exit /b
   

2. Add the following configuration to the ThreatLockDown agent C:\Program Files (x86)\ossec-agent\ossec.conf file:

   <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. The PowerShell program executes the C:\tasklist.bat script.

   • The value 2m in the <interval> tag indicates that the Command module runs the command every 2 minutes.

   Note

   You can use the centralized configuration file to distribute this setting across multiple monitored endpoints.

3. Restart the ThreatLockDown agent to apply the changes, using PowerShell with administrator privileges:

   > Restart-Service -Name wazuh
   

Custom ruleset

Configure the ThreatLockDown server with a custom decoder and rule to analyze the events received from the Windows endpoint by following the steps below.

1. Add the following decoder to the /var/ossec/etc/decoders/local_decoder.xml file:

   <decoder name="tasklist">
     <prematch>^tasklist: </prematch>
   </decoder>
   

2. Add the rule below to the /var/ossec/etc/rules/local_rules.xml file to generate an alert when the notepad.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>
   

3. Restart the ThreatLockDown manager to apply the changes:

   $ sudo systemctl restart wazuh-manager
   

Visit the ThreatLockDown dashboard and navigate to the Threat Hunting module to visualize the generated alert as shown below.

How to configure the Logcollector module

A basic configuration for the Logcollector module requires the command to monitor, the frequency of execution of the command, and the log format of the executed command.

For example, to monitor the percentage of memory available on a Linux endpoint every 120 seconds, perform the following steps on the Linux endpoint.

1. Add the configuration below within the </ossec_config> block of the ThreatLockDown agent’s local configuration file, /var/ossec/etc/ossec.conf:

   <localfile>
     <log_format>full_command</log_format>
     <command>free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2 }'</command>
     <alias>memory_utilization</alias>
     <frequency>120</frequency>
   </localfile>
   

   Where:

   • The full_command value in the <log_format> tag specifies the output of the command free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2 }' is read as a single event.

   • The value free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2 }' in the <command> tag is the command the Logcollector module executes.

   • The value memory_utilization of the <alias> tag is a string that represents the free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2 }' command for better identification in creating rules.

   • The value 120 in the <frequency> tag implies the command runs every 120 seconds (2 minutes).

   Note

   You can use the centralized configuration file to distribute this setting across multiple monitored endpoints.

2. Restart the ThreatLockDown agent service to apply the changes:

   $ sudo systemctl restart wazuh-agent
   

At this stage, the Logcollector module is configured to execute the specified command on the Linux endpoint and forward its output to the ThreatLockDown server for analysis. The command output however needs to be analyzed to generate security alerts. ThreatLockDown provides a default decoder called ossec to analyze command outputs from the Logcollector module.

Additionally, ThreatLockDown provides a default rule definition with ID 530 that is triggered when it matches a command output of the Logcollector module. The rule level is set to 0, which means that it does not generate an alert by default when a command output triggers it. To generate security alerts for command outputs of the Logcollector module, you must create a custom rule with an increased level that inherits this base rule.

Perform the following steps on the ThreatLockDown server to generate alerts when ThreatLockDown analyzes the output of the command free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2.

1. Add the custom rule below to the /var/ossec/etc/rules/local_rules.xml file:

   <group name="memory_utilization,">
     <rule id="100012" level="6">
       <if_sid>530</if_sid>
       <match>^ossec: output: 'memory_utilization'</match>
       <description>Memory utilization metric.</description>
     </rule>
   </group>
   

2. Restart the ThreatLockDown manager to apply the changes:

   $ sudo systemctl restart wazuh-manager
   

After you perform the steps above, the ThreatLockDown server can now analyze the output of the command, free -m | awk 'NR==2{printf "%.2f\t\t\n", $3*100/$2, and trigger security alerts every 120 seconds.

Visit the ThreatLockDown dashboard and navigate to the Threat Hunting module to visualize the generated alert as shown below.

As shown in the figure above, the alert is expanded to show the available fields. The full_log field contains the message received from the Linux endpoint. The value 76.42 in the full_log field represents the percentage of memory utilized by the Linux endpoint. This value can be captured in a variable and displayed in the message description on the ThreatLockDown dashboard. Visit the section on Creating a custom ruleset to see how this is done.

Custom ruleset

ThreatLockDown provides an out-of-the-box decoder and rule to analyze the output of commands executed with the Logcollector module to generate security alerts.

The decoder is known as ossec as shown below and is available in the /var/ossec/ruleset/decoders/0200-ossec_decoders.xml file on the ThreatLockDown server.

<decoder name="ossec">
  <prematch>^ossec: </prematch>
  <type>ossec</type>
</decoder>

The rule is defined with ID 530 as shown below and is available in the /var/ossec/ruleset/rules/0015-ossec_rules.xml file on the ThreatLockDown server.

<rule id="530" level="0">
  <if_sid>500</if_sid>
  <match>^ossec: output: </match>
  <description>OSSEC process monitoring rules.</description>
  <group>process_monitor,</group>
</rule>

The rule level is set to 0, which means it does not generate an alert when it matches the expression ossec: output: of the Logcollector module’s command output. To generate alerts for command outputs, you must create a custom rule that inherits this base rule with an increased level unless you have created custom decoders. For example, the df -P command output triggers the rule below when the disk usage of the /dev directory of a Linux endpoint is 100%.

<rule id="531" level="7" ignore="7200">
  <if_sid>530</if_sid>
  <match>ossec: output: 'df -P': /dev/</match>
  <regex>100%</regex>
  <description>Partition usage reached 100% (disk space monitor).</description>
  <group>low_diskspace,pci_dss_10.6.1,gpg13_10.1,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

From the rule definition above, you can see that rule ID 531 inherits from the base rule with ID 530. Additionally, the rule level has been increased from 0 to 7 to generate a security alert as highlighted.

The default decoder and rule are limited and do not provide coverage for all available scenarios. For this reason, ThreatLockDown offers you the ability to create custom decoders and rules to meet your specific use case. Kindly visit the Creating a custom ruleset section of this documentation for more information.

Example configuration

The configurations below shows how to enable and disable remote command execution on ThreatLockDown agents in Linux endpoints.

• To enable the ThreatLockDown agent to accept remote commands from a ThreatLockDown server, add the configuration below to the /var/ossec/etc/local_internal_options.conf file on the Linux endpoint.

  • For the Command module:

    wazuh_command.remote_commands=1
    

  • For the Logcollector module:

    logcollector.remote_commands=1
    

• To disable remote command execution after explicitly enabling it, remove the configuration entirely or modify the appropriate value to 0 in the /var/ossec/etc/local_internal_options.conf file.

  • For the Command module:

    wazuh_command.remote_commands=0
    

  • For the Logcollector module:

    logcollector.remote_commands=0