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
WMIto identify and potentially disable security solutions. - The executable drops a PowerShell script and creates a service via
schtasksthat executes the script to gain persistence. The script is placed in theC:\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 |
| 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 fileC:\Program Files (x86)\ossec-agent\ossec.confto 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.xmlin 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.xmlfile:
<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
100601is triggered when a suspicious PowerShell startup profile is detected. - Rule ID
100602is triggered when a malicious PowerShell script is executed and deleted from the/tmpdirectory. - Rule ID
100603is triggered when LodaRAT malware injectsmscorlib.ni.dllintoC:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib. - Rule ID
100604is triggered when LodaRAT malware injectsclrjit.dllintoC:\Windows\Microsoft.NET\Framework64\v4.0.30319. - Rule ID
100605is triggered when LodaRAT malware injectsmscoreei.dllintoC:\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, and100605in 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 theC:\Program Files (x86)\ossec-agent\ossec.conffile to monitor for changes. In this blog post, we configure the FIM module to monitor theDownloadsfolder 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
Pyinstallerusing PowerShell:
> pip install -U pyinstaller
- Change to the directory where the Python script
remove-threat.pyis 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\distfolder under your current working directory to theC:\Program Files (x86)\ossec-agent\active-response\binfolder. - 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.conffile 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.conffile:
<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.xmlfile 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
100701generates an alert when the Wazuh Active Response module successfully removes the LodaRAT malware. - Rule ID
100702generates 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, and87105in 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.