Use cases

Forwarding Linux logs using rsyslog

In this use case, we configure a CentOS 7 endpoint to forward logs using rsyslog to the ThreatLockDown server for analysis. On the CentOS 7 endpoint, we create and delete the user account Stephen. ThreatLockDown has default rules that generate alerts for the creation and deletion of user accounts.

CentOS endpoint

Perform the following steps to forward logs using rsyslog to the ThreatLockDown server.

Edit the /etc/rsyslog.conf file and add the following configuration:
```
*.info@@<WAZUH_SERVER_IP_ADDRESS>:514
```
Where:
- <WAZUH_SERVER_IP_ADDRESS> represents the IP address of the ThreatLockDown server.
Restart the rsyslog service to apply the change:
```
# systemctl restart rsyslog
```

ThreatLockDown server

Perform the following steps to configure the ThreatLockDown server to receive logs from the CentOS 7 endpoint.

Edit the /var/ossec/etc/ossec.conf file and add the following configuration in between the <ossec_config> tags:
```
<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips><LINUX_ENDPOINT_IP_ADDRESS></allowed-ips>
</remote>
```
Where:
- <LINUX_ENDPOINT_IP_ADDRESS> represents the IP address of the CentOS 7 endpoint.
Restart the ThreatLockDown manager for the changes to take effect:
```
# systemctl restart wazuh-manager
```

Test the configuration

Perform the following on the CentOS 7 endpoint to test the configuration.

Add the user Stephen:
```
# useradd Stephen
```
Delete the same user Stephen:
```
# userdel Stephen
```

Navigate to Threat Hunting module on the ThreatLockDown dashboard to view the alerts.

Note

You can filter for only the CentOS endpoint events by taking the following steps.

Click on the Add filter button.
Search for “location” in the Field input, then select the is Operator.
Enter the IP address of the CentOS 7 endpoint as the Value, and click save.

The image below shows an alert for user creation.

The image below shows an alert for user deletion.

Detecting the installation of applications on Windows

In this use case, we detect when an application is installed on a Windows endpoint. We test this use case by installing an application called Dr. Memory.

Dr. Memory is an open source memory monitoring tool capable of detecting invalid memory accesses, memory leaks, handle leaks, accesses to freed memory, and other memory-related issues.

Windows endpoint

Download and install Dr. Memory.

By default, the ThreatLockDown agent monitors the installation of applications using the configuration below located in the ThreatLockDown agent configuration file C:\Program Files (x86)\ossec-agent\ossec.conf:

<localfile>
  <location>Application</location>
  <log_format>eventchannel</log_format>
</localfile>

ThreatLockDown server

ThreatLockDown has a built-in rule 60612 to detect when an application is installed on a Windows endpoint. You can view this rule in the /var/ossec/ruleset/rules/0585-win-application_rules.xml file on the ThreatLockDown server.

<rule id="60612" level="3">
  <if_sid>60609</if_sid>
  <field name="win.system.eventID">^11707$|^1033$</field>
  <options>no_full_log</options>
  <description>Application installed $(win.eventdata.data).</description>
</rule>

Test the configuration

After installing Dr. Memory, navigate to Threat Hunting on the ThreatLockDown dashboard and apply the filter rule.id:60612 to view the alert.

Monitoring PowerShell activity

In this use case, we configure ThreatLockDown to detect when PowerShell adds a new Windows registry key.

Windows endpoint

Perform the following steps to enable PowerShell logging on a Windows endpoint and configure the ThreatLockDown agent to monitor logged PowerShell activities.

Press Windows + R keys on your keyboard to open the run dialog box.
Type gpedit.msc in the search box and click OK to open the local group policy editor.
Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging.

Note

Turning on PowerShell Script Block Logging will log a lot of PowerShell events in the Microsoft-Winndows-PowerShell/Operational event channel.
Select Enabled, and then click OK.
Add the following in between the <ossec_config> tags of the ThreatLockDown agent configuration file C:\Program Files (x86)\ossec-agent\ossec.conf to monitor PowerShell logs:
```
<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
```
Restart the ThreatLockDown agent via PowerShell with administrator privileges to apply the change:
```
> Restart-Service -Name wazuh
```

ThreatLockDown server

ThreatLockDown has a built-in rule 91843 to detect when a PowerShell adds a new Windows registry key. You can view this rule in the /var/ossec/ruleset/rules/0915-win-powershell_rules.xml file on the ThreatLockDown server:

<rule id="91843" level="3">
  <if_sid>91802</if_sid>
  <field name="win.eventdata.scriptBlockText" type="pcre2">(?i)New-ItemProperty.+\-Path</field>
  <options>no_full_log</options>
  <description>Powershell executed "New-ItemProperty -Path". Possible addition of new item to registry</description>
  <mitre>
    <id>T1059.001</id>
    <id>T1112</id>
  </mitre>
</rule>

Test the configuration

Perform the following steps to test the configuration:

On the Windows endpoint, run the following command via PowerShell with administrator privileges to add a registry entry NoofAlerts to the HKLM\Software\Microsoft\ADs registry key, and set the value to 2:
```
> New-ItemProperty -Path "HKLM:\Software\Microsoft\ADs" -Name "NoofAlerts" -Value 2
```
Note

We recommend running the above command in a sandbox environment, and not in a production environment.
Navigate to Threat Hunting on the ThreatLockDown dashboard and apply the rule.id:91843 filter to view the alert.