Detecting LodaRAT malware with Wazuh

August 6th 2025 | by Musbau Soladoye | Wazuh 4.12.0

LodaRAT is a remote access trojan (RAT) known for stealing sensitive data, executing commands, and maintaining persistence on infected systems. Commonly spread via phishing and malicious documents, it now uses advanced tactics like process injection, encrypted C2, and data exfiltration through legitimate services.

Recently, a new variant of LodaRAT emerged that can steal saved passwords and browser cookies. This upgrade allows attackers to hijack logged-in sessions, bypass security measures like multi-factor authentication (MFA), and gain unauthorized access to user accounts.

This blog post illustrates how organizations can detect and respond to LodaRAT malware on infected Windows endpoints.

LodaRAT malware behavior

LodaRAT is a stealthy Remote Access Trojan (RAT) that operates primarily through command-line execution. It is flexible and allows attackers to adapt its behavior based on the compromised system dynamically. Below are some of its notable malicious capabilities

The malware uses sophisticated evasion techniques, including runtime string deobfuscation and dynamic function name randomization to bypass static analysis and hinder reverse engineering efforts.
The malware performs a comprehensive system reconnaissance by collecting detailed host information (IP, OS version, architecture) and actively queries WMI to identify and potentially disable security solutions.
The executable drops a PowerShell script and creates a service via schtasks that executes the script to gain persistence. The script is placed in the C:\Users\Administrator\AppData\Local\Temp\ folder with an obfuscated name and is deleted after execution.
The malware connects to a command and control server, allowing the attacker to communicate with the victim through a chat window on the infected system.

Analyzed files

Hash type	Value
SHA256	6a46b3762d71b47d0c728e967ee9129f523689ff70196a953baa3f60c85a26b5
SHA256	155b933fb9fe44c971a042e6539d8544616f908960177e7922eee1c943008ab9

Infrastructure

We use the following infrastructure to demonstrate the detection of the LodaRAT malware with Wazuh:

A pre-built, ready-to-use Wazuh OVA 4.12.0, 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 victim endpoint with the Wazuh agent 4.12.0 installed and enrolled on the Wazuh server.

Wazuh detection

We use Sysmon to monitor several system events and create custom detection rules on the Wazuh server to detect the malicious behavior of LodaRAT malware.

Windows endpoint

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.

Download Sysmon from the Microsoft Sysinternals page.
Extract the compressed Sysmon file to your preferred location.
Download the sysmonconfig.xml file using PowerShell. 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

Using PowerShell with Administrator privileges, switch to the directory where the Sysmon executable is located. Then run the command below to install and start Sysmon:

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

Add the following configuration within the <ossec_config> block of the Wazuh agent configuration file C:\Program Files (x86)\ossec-agent\ossec.conf 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 configuration changes:

> Restart-Service -Name wazuh

Wazuh server

Create rules to detect the activities of the LodaRAT malware on the monitored Windows endpoint.

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

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

Add the following detection rules to the /var/ossec/etc/rules/lodarat_rules.xml file:

<group name="Lodarat, malware,">
    <rule id="100601" level="7">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.Image" type="pcre2">.*\\powershell\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">C:\\\\Users\\\\.+?\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\PowerShell\\\\StartupProfileData-NonInteractive</field>
    <description>Suspicious PowerShell startup profile file detected.</description>
    <mitre>
      <id>T1546.013</id>
    </mitre>
  </rule>

   <rule id="100602" level="12">
    <if_sid>61654</if_sid>
    <field name="win.eventdata.Image" type="pcre2">.*\\powershell\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">C:\\\\Users\\\\.+?\\\\AppData\\\\Local\\\\Temp\\\\.+?\.ps1</field>
    <description>Possible LodaRAT malware activity detected: $(win.eventdata.targetFilename) was executed and deleted in the temp directory.</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>

   <!-- DLL process injection -->
  <rule id="100603" level="7">
    <if_sid>61609</if_sid>
    <field name="win.eventdata.Image" type="pcre2">.*\\powershell\.exe</field>
    <field name="win.eventdata.ImageLoaded" type="pcre2">(?i)[c-z]:\\\\Windows\\\\assembly\\\\NativeImages_v4\.0\.30319_64\\\\mscorlib\\\\.*\\\\mscorlib\.ni\.dll</field>
    <description>Possible malware infection: PowerShell process loaded mscorlib.ni.dll, possibly indicating process injection.</description>
    <mitre>
        <id>T1055</id>
    </mitre>
  </rule>

  <rule id="100604" level="7">
    <if_sid>61609</if_sid>
    <field name="win.eventdata.Image" type="pcre2">.*\\powershell\.exe</field>
    <field name="win.eventdata.ImageLoaded" type="pcre2">(?i)[c-z]:\\\\Windows\\\\Microsoft\.NET\\\\Framework64\\\\v4\.0\.30319\\\\clrjit\.dll</field>
    <description>Possible malware infection: PowerShell process loaded clrjit.dll, indicating potential process injection.</description>
    <mitre>
        <id>T1055.001</id>
    </mitre>
  </rule>

  <rule id="100605" level="7">
    <if_sid>61609</if_sid>
    <field name="win.eventdata.Image" type="pcre2">.*\\powershell\.exe</field>
    <field name="win.eventdata.ImageLoaded" type="pcre2">(?i)[c-z]:\\\\Windows\\\\Microsoft\.NET\\\\Framework64\\\\v4\.0\.30319\\\\mscoreei\.dll</field>
    <description>Possible malware infection: PowerShell process loaded mscoreei.dll, indicating potential process injection.</description>
    <mitre>
        <id>T1055.001</id>
    </mitre>
  </rule>
</group>

Where:

Rule ID 100601 is triggered when a suspicious PowerShell startup profile is detected.
Rule ID 100602 is triggered when a malicious PowerShell script is executed and deleted from the /tmp directory.
Rule ID 100603 is triggered when LodaRAT malware injects mscorlib.ni.dll into C:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib.
Rule ID 100604 is triggered when LodaRAT malware injects clrjit.dll into C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
Rule ID 100605 is triggered when LodaRAT malware injects mscoreei.dll into C:\Windows\Microsoft.NET\Framework64\v4.0.30319.

Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

Detection results

Follow the steps below to view the alerts generated on the Wazuh dashboard when the LodaRAT malware is executed on the Windows endpoint.

Navigate to Threat intelligence > Threat Hunting and click the Events tab.
Click + Add filter. Then filter by rule.id.
In the Operator field, select is one of.
Search and select 100601, 100602, 100603, 100604, and 100605 in the Values field.
Click Save.

VirusTotal integration

VirusTotal aggregates antivirus products and online scan engines, providing an API that can be queried with URLs, IP addresses, domains, or file hashes to identify security threats. You can configure Wazuh to automatically send requests to the VirusTotal API with the hashes of files created or modified on a monitored endpoint.

For this integration, we configure the Wazuh File Integrity Monitoring module and VirusTotal to detect and scan files that are added or modified in specific directories on the Windows endpoint. Additionally, we configured the Wazuh Active Response module to automatically remove the files that VirusTotal identifies as malicious.

Windows endpoint

Add the following configuration within the <syscheck> block in the C:\Program Files (x86)\ossec-agent\ossec.conf file to monitor for changes. In this blog post, we configure the FIM module to monitor the Downloads folder for all users.

<directories realtime="yes">C:\Users\*\Downloads</directories>

Restart the Wazuh agent to apply the changes by running the following PowerShell command as an administrator:

> Restart-Service -Name wazuh

Active response Python script configuration

We create an active response script to remove any known variant of LodaRAT malware immediately after VirusTotal identifies it as a threat.

Create an active response script, remove-threat.py, on the Victim endpoint with the following content:

Warning: This script is a proof of concept (PoC). Review and validate it to ensure it meets the operational and security requirements of your environment

# Copyright (C) 2015-2025, Wazuh Inc.
# All rights reserved.

import os
import sys
import json
import datetime
import stat
import tempfile
import pathlib

if os.name == 'nt':
    LOG_FILE = "C:\\Program Files (x86)\\ossec-agent\\active-response\\active-responses.log"
else:
    LOG_FILE = "/var/ossec/logs/active-responses.log"

ADD_COMMAND = 0
DELETE_COMMAND = 1
CONTINUE_COMMAND = 2
ABORT_COMMAND = 3

OS_SUCCESS = 0
OS_INVALID = -1

class message:
    def __init__(self):
        self.alert = ""
        self.command = 0

def write_debug_file(ar_name, msg):
    with open(LOG_FILE, mode="a") as log_file:
        log_file.write(str(datetime.datetime.now().strftime('%Y/%m/%d %H:%M:%S')) + " " + ar_name + ": " + msg +"\n")

def setup_and_check_message(argv):
    input_str = ""
    for line in sys.stdin:
        input_str = line
        break

    msg_obj = message()
    try:
        data = json.loads(input_str)
    except ValueError:
        write_debug_file(argv[0], 'Decoding JSON has failed, invalid input format')
        msg_obj.command = OS_INVALID
        return msg_obj

    msg_obj.alert = data
    command = data.get("command")

    if command == "add":
        msg_obj.command = ADD_COMMAND
    elif command == "delete":
        msg_obj.command = DELETE_COMMAND
    else:
        msg_obj.command = OS_INVALID
        write_debug_file(argv[0], 'Not valid command: ' + command)

    return msg_obj

def send_keys_and_check_message(argv, keys):
    keys_msg = json.dumps({"version": 1,"origin":{"name": argv[0],"module":"active-response"},"command":"check_keys","parameters":{"keys":keys}})
    write_debug_file(argv[0], keys_msg)

    print(keys_msg)
    sys.stdout.flush()

    input_str = ""
    while True:
        line = sys.stdin.readline()
        if line:
            input_str = line
            break

    try:
        data = json.loads(input_str)
    except ValueError:
        write_debug_file(argv[0], 'Decoding JSON has failed, invalid input format')
        return OS_INVALID

    action = data.get("command")
    if action == "continue":
        return CONTINUE_COMMAND
    elif action == "abort":
        return ABORT_COMMAND
    else:
        write_debug_file(argv[0], "Invalid value of 'command'")
        return OS_INVALID

def secure_delete_file(filepath_str, ar_name):
    filepath = pathlib.Path(filepath_str)

    # Reject NTFS alternate data streams
    if '::' in filepath_str:
        raise Exception(f"Refusing to delete ADS or NTFS stream: {filepath_str}")

    # Reject symbolic links and reparse points
    if os.path.islink(filepath):
        raise Exception(f"Refusing to delete symbolic link: {filepath}")

    attrs = os.lstat(filepath).st_file_attributes
    if attrs & stat.FILE_ATTRIBUTE_REPARSE_POINT:
        raise Exception(f"Refusing to delete reparse point: {filepath}")

    resolved_filepath = filepath.resolve()

    # Ensure it's a regular file
    if not resolved_filepath.is_file():
        raise Exception(f"Target is not a regular file: {resolved_filepath}")

    # Perform deletion
    os.remove(resolved_filepath)

def main(argv):
    write_debug_file(argv[0], "Started")
    msg = setup_and_check_message(argv)

    if msg.command < 0:
        sys.exit(OS_INVALID)

    if msg.command == ADD_COMMAND:
        alert = msg.alert["parameters"]["alert"]
        keys = [alert["rule"]["id"]]
        action = send_keys_and_check_message(argv, keys)

        if action != CONTINUE_COMMAND:
            if action == ABORT_COMMAND:
                write_debug_file(argv[0], "Aborted")
                sys.exit(OS_SUCCESS)
            else:
                write_debug_file(argv[0], "Invalid command")
                sys.exit(OS_INVALID)

        try:
            file_path = alert["data"]["virustotal"]["source"]["file"]
            if os.path.exists(file_path):
                secure_delete_file(file_path, argv[0])
                write_debug_file(argv[0], json.dumps(msg.alert) + " Successfully removed threat")
            else:
                write_debug_file(argv[0], f"File does not exist: {file_path}")
        except OSError as error:
            write_debug_file(argv[0], json.dumps(msg.alert) + "Error removing threat")
        except Exception as e:
            write_debug_file(argv[0], f"{json.dumps(msg.alert)}: Error removing threat: {str(e)}")
    else:
        write_debug_file(argv[0], "Invalid command")

    write_debug_file(argv[0], "Ended")
    sys.exit(OS_SUCCESS)

if __name__ == "__main__":
    main(sys.argv)

The active response Python script handles the removal of the malicious file using the os.remove() function:

os.remove(msg.alert["parameters"]["alert"]["data"]["virustotal"]["source"]["file"])

Download Python and run the installer. This works with Python 3.8.7 or later (with pip pre-installed). Then, select the following checkboxes during installation:

Use admin privileges when installing py.exe.
Add Python.exe to PATH.

Note

This step is optional if Python is installed on the Windows endpoint.

Run the following command with administrative privileges to install Pyinstaller using PowerShell:

> pip install -U pyinstaller

Change to the directory where the Python script remove-threat.py is located and convert the file to an executable file with the following command:

> pyinstaller -F remove-threat.py

Move the executable file remove-threat.exe, from the \dist folder under your current working directory to the C:\Program Files (x86)\ossec-agent\active-response\bin folder.
Restart the agent to apply the changes by running the following PowerShell command as an administrator:

> Restart-Service -Name wazuh

Wazuh server

Append the configuration below to the /var/ossec/etc/ossec.conf file to scan the LodaRAT executable files with VirusTotal:

<ossec_config>
  <integration>
    <name>virustotal</name>
    <api_key><API_KEY></api_key> <!-- Replace with your VirusTotal API key -->
    <rule_id>554,550</rule_id>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

Replace the <API_KEY> variable with your VirusTotal API key.

The FIM rule IDs 554 and 550 detect file addition and modification events, respectively.

Active response configuration

Append the following configuration to the /var/ossec/etc/ossec.conf file:

<ossec_config>
  <command>
    <name>remove-threat</name>
    <executable>remove-threat.exe</executable>
    <timeout_allowed>no</timeout_allowed>
  </command>

  <active-response>
    <disabled>no</disabled>
    <command>remove-threat</command>
    <location>local</location>
    <rules_id>87105</rules_id>
  </active-response>
</ossec_config>

Add the following rules to the /var/ossec/etc/rules/lodarat_rules.xml file to generate alerts when the Wazuh Active Response module successfully removes the malicious files.

<group name="virustotal,">
  <rule id="100701" level="12">
    <if_sid>657</if_sid>
    <match>Successfully removed threat</match>
    <description>$(parameters.program) removed threat located at $(parameters.alert.data.virustotal.source.file)</description>
  </rule>

  <rule id="100702" level="12">
    <if_sid>657</if_sid>
    <match>Error removing threat</match>
    <description>Error removing threat located at $(parameters.alert.data.virustotal.source.file)</description>
  </rule>
</group>

Where:

Rule ID 100701 generates an alert when the Wazuh Active Response module successfully removes the LodaRAT malware.
Rule ID 100702 generates an alert when the Wazuh Active Response module fails to remove the LodaRAT malware.

Restart the Wazuh manager to apply configuration changes:

# systemctl restart wazuh-manager

Visualize results

When a variant of LodaRAT is downloaded to the victim’s Downloads folder, Wazuh generates alerts and promptly initiates an active response to remove the malicious file. The screenshot below shows that the Wazuh FIM module detects the file addition, which VirusTotal confirms as malicious, triggering Wazuh to take an automated response. Follow these steps to view these alerts:

Navigate to Threat intelligence > Threat Hunting and click the Events tab.
Click + Add filter. Then filter by rule.id.
In the Operator field, select is one of.
Filter for 100701, 100702, 553, 554, 550, and 87105 in the Values field.
Click Save.

Conclusion

LodaRAT is a remote access trojan (RAT) designed to steal sensitive data, execute commands, and maintain persistence. Wazuh, a free and open source SIEM/XDR platform, provides the visibility and detection capabilities necessary to safeguard your endpoints from emerging threats.

In this blog post, we demonstrated how integrating Sysmon with Wazuh can effectively detect the behavior of LodaRAT malware. Additionally, we utilized the Wazuh FIM and VirusTotal integration to identify the malware upon its download to an endpoint. We leveraged the Wazuh Active Response module to show how malicious files can be swiftly removed, neutralizing the threat before it causes damage.

To learn more about Wazuh capabilities, check out our documentation, blog posts, and community for support and updates.

LodaRAT malware behavior

Analyzed files

Infrastructure

Wazuh detection

Windows endpoint

Wazuh server

Detection results

VirusTotal integration

Windows endpoint

Active response Python script configuration

Wazuh server

Active response configuration

Visualize results

Conclusion

References

Related content

Detecting Auto-color malware with Wazuh

Integrating ESET PROTECT Hub with Wazuh

Detecting and responding Mamona ransomware with Wazuh

Detecting DOGE Big Balls ransomware with Wazuh

Use cases

Malware Detection

Threat Hunting