CrossLock ransomware detection with Wazuh

July 28th 2023 | by Anthony Faruna | Wazuh 4.4.5

CrossLock ransomware is a recent strain of ransomware developed using the Go programming language, making it harder to reverse engineer. The ransomware is capable of infecting several platforms, including Windows and UNIX-like operating systems. Like most recent ransomware strains, CrossLock uses the double extortion technique to increase the chances of payment from its victims. This technique encrypts and exfiltrates the victim’s data from their endpoint. This puts significant pressure on the victim as the cybercriminals threaten to publicize their data or sell it on the dark web.

In this blog post, we use Wazuh to detect the malicious activities of CrossLock ransomware on an infected Windows endpoint.

CrossLock ransomware behavior

CrossLock ransomware exhibits several behaviors when executed on an endpoint. Some of these behaviors include the following:

Runs with a hardcoded command line instruction that can be found within the ransomware executable. Below is an example of such a command:

rware.exe –host dcServer –domain icme[.]com –user administrator -p 123456@passwd -P C$

Modifies Event Tracing for Windows (ETW) using the Event Tracing Bypass technique to avoid detection and conceal its action on the Windows endpoint. ETW is a mechanism built into Windows that allows developers to capture application and system events for troubleshooting purposes.
Deletes all the shadow copies of files and folders on the Windows endpoint to prevent recovery of the lost files.
Uses the wevtutil cl application command to clear application event logs in the Windows Event Viewer program.
Executes the bcdedit /set {default} recoveryenabled No command to disable automatic repair on the Windows endpoint.
Uses the wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest command to delete the oldest system backup that contains critical files like registry, system, and boot files.
Uses the wbadmin delete catalog command to delete backup catalogs containing information about backup taken on the Windows endpoint.
Executes the wevtutil cl security command to clear security events logs in the Windows Event Viewer program.
Uses the bcdedit /set {default} bootstatuspolicy ignoreallfailures command to set the boot policy on the Windows endpoint to ignore all failures.
Using the wbadmin DELETE SYSTEMSTATEBACKUP command to delete system state backup on the Windows endpoint.
Using wevtutil cl system to clear system event logs in the Windows Event Viewer on the Windows endpoint.

Infrastructure

To demonstrate the detection of CrossLock ransomware with Wazuh, we use the following infrastructure.

A pre-built, ready-to-use Wazuh OVA 4.4.5. Follow this guide to download the virtual machine (VM). This VM hosts the Wazuh central components (Wazuh server, Wazuh indexer, and Wazuh dashboard).
A Windows 11 victim endpoint with Wazuh agent 4.4.5 installed and enrolled to the Wazuh server. To install the Wazuh agent, refer to the Wazuh Windows installation guide.

Detection with Wazuh

In this blog post, we use the following techniques to detect the intrusion and behaviors of the CrossLock ransomware on infected Windows endpoints:

Using custom detection rules: This technique alerts about malicious activities in an infected endpoint.
Scanning malicious files using the Wazuh VirusTotal integration and active response to remove malicious files.

Using custom detection rules

Perform the following steps to configure the Wazuh agent to capture Sysmon logs and send them to the Wazuh server for analysis.

Install Sysmon on the Windows endpoint

1. Download Sysmon from the Microsoft Sysinternals page.

2. Extract the compressed Sysmon file to your preferred location.

3. Download the Sysmon configuration file – sysmonconfig.xml 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

4. Switch to the directory with the Symon executable. Run the command below to install and start Sysmon using PowerShell with Administrator privileges:

> .\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. This configures the Wazuh agent to collect and forward Sysmon event logs 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

In this section, we create rules to detect CrossLock ransomware behavior on the endpoint.

1. Add the rules below to the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server:

<group name="crosslock,">
<!-- Detects when CrossLock ransomware creates ransom notes. -->
  <rule id="100201" level="12" timeframe="50" frequency="2">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)[C-Z]:.*.CrossLock.*---.txt</field>
    <description>The file $(win.eventdata.targetFilename) has been created in multiple directories. CrossLock ransomware detected.</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>

<!-- Detects when CrossLock deletes the oldest system state backup on the system. -->
  <rule id="100202" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wbadmin\s\sDELETE\sSYSTEMSTATEBACKUP\s-deleteOldest</field>
     <description>Suspicious command to delete the oldest system state backup executed. Possible ransomware activity.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>

<!-- Detects when CrossLock deletes the system state backup on the system. -->
  <rule id="100203" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wbadmin\s\sDELETE\sSYSTEMSTATEBACKUP</field>
     <description>Suspicious command to delete system state backup executed. Possible ransomware activity.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>

  <rule id="100204" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wevtutil\s\scl\sapplication</field>
     <description>Windows application event deleted. Possible ransomware activity detected.</description>
     <mitre>
       <id>T1070.001</id>
     </mitre>
  </rule>

  <rule id="100205" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wevtutil\s\scl\ssecurity</field>
     <description>Windows security event logs deleted. Possible ransomware activity detected.</description>
     <mitre>
       <id>T1070.001</id>
     </mitre>
  </rule>

  <rule id="100206" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)bcdedit\s\s\/set\s{default}\sbootstatuspolicy\signoreallfailures</field>
     <description>Boot status policy set to ignore all failures. Possible ransomware activity detected.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>

  <rule id="100207" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wevtutil\s\scl\ssystem</field>
     <description>Windows system event logs deleted. Possible ransomware activity detected.</description>
     <mitre>
       <id>T1070.001</id>
     </mitre>
  </rule>

  <rule id="100208" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)bcdedit\s\s\/set\s{default} recoveryenabled\sNo</field>
     <description>System recovery disabled. Possible ransomware detected.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>

  <rule id="100209" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)wbadmin\s\sdelete\scatalog\s-quiet</field>
     <description>System backup catalog deleted. Possible ransomware activity detected.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>

  <rule id="100210" level="12">
     <if_sid>92032</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)vssadmin\s\sdelete\sshadows\s\/all\s\/quiet</field>
     <description>Shadow copies have been deleted. Possible ransomware detected.</description>
     <mitre>
       <id>T1490</id>
     </mitre>
  </rule>
  
</group>

Where:

Rule ID 100201 is triggered when CrossLock ransomware drops a ransom note with the file name —CrossLock_readme_To_Decrypt—.txt in various folders.
Rule ID 100202 is triggered when CrossLock ransomware deletes the oldest system state backup on the Windows endpoint. A system state backup is a backup of the system’s critical files, including the registry, boot files, and system files.
Rule ID 100203 is triggered when CrossLock ransomware deletes the system state backup on the Windows endpoint.
Rule ID 100204 is triggered when CrossLock ransomware clears the application event logs in the Windows Event Viewer.
Rule ID 100205 is triggered when CrossLock ransomware clears the security event logs in the Windows Event Viewer.
Rule ID 100206 is triggered when CrossLock ransomware sets the boot status policy to ignore all failures.
Rule ID 100207 is triggered when CrossLock ransomware clears the system event logs in the Windows Event Viewer.
Rule ID 100208 is triggered when CrossLock ransomware disables the automatic startup repair feature on the Windows endpoint.
Rule ID 100209 is triggered when CrossLock ransomware deletes the backup catalog of the Windows endpoint.
Rule ID 100210 is triggered when CrossLock ransomware deletes all the shadow copies of the files and folders on the Windows endpoint.

2. Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

Detection results

The screenshot below shows the alerts generated on the Wazuh dashboard when the CrossLock ransomware is executed on the victim endpoint.

From the Agents tab in your Wazuh dashboard, select the Windows endpoint and navigate to the Security events tab to view the generated alerts.

Detecting and removing CrossLock ransomware with VirusTotal and active response

VirusTotal aggregates many antivirus products and online scan engines, offering an API that can be queried by using either URLs, IPs, domains, or file hashes. You can configure Wazuh to automatically send requests to the VirusTotal API with the hashes of files created or modified on the monitored endpoint.

We configure the Wazuh File Integrity Monitoring module and VirusTotal to detect and scan files added or modified to the Windows endpoint. Additionally, we configure the Wazuh active response module to run a Python script that removes the files flagged as malicious by VirusTotal.

Windows endpoint

Configure the Wazuh FIM module and create an active response script using the steps below.

Configuring the FIM module

1. To monitor the intrusion of the CrossLock ransomware file, add the following configuration to the "C:\Program Files (x86)\ossec-agent\ossec.conf" file. In our case, we configure the FIM module to monitor the Downloads folder:

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

2. Restart the 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 the CrossLock ransomware when VirusTotal identifies it as a threat.

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

#!/usr/bin/python3
# Copyright (C) 2015-2022, Wazuh Inc.
# All rights reserved.
 
import os
import sys
import json
import datetime
 
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):
 
    # get alert from stdin
    input_str = ""
    for line in sys.stdin:
        input_str = line
        break
 
 
    try:
        data = json.loads(input_str)
    except ValueError:
        write_debug_file(argv[0], 'Decoding JSON has failed, invalid input format')
        message.command = OS_INVALID
        return message
 
    message.alert = data
 
    command = data.get("command")
 
    if command == "add":
        message.command = ADD_COMMAND
    elif command == "delete":
        message.command = DELETE_COMMAND
    else:
        message.command = OS_INVALID
        write_debug_file(argv[0], 'Not valid command: ' + command)
 
    return message
 
 
def send_keys_and_check_message(argv, keys):
 
    # build and send message with 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()
 
    # read the response of previous message
    input_str = ""
    while True:
        line = sys.stdin.readline()
        if line:
            input_str = line
            break
 
    # write_debug_file(argv[0], input_str)
 
    try:
        data = json.loads(input_str)
    except ValueError:
        write_debug_file(argv[0], 'Decoding JSON has failed, invalid input format')
        return message
 
    action = data.get("command")
 
    if "continue" == action:
        ret = CONTINUE_COMMAND
    elif "abort" == action:
        ret = ABORT_COMMAND
    else:
        ret = OS_INVALID
        write_debug_file(argv[0], "Invalid value of 'command'")
 
    return ret
 
def main(argv):
 
    write_debug_file(argv[0], "Started")
 
    # validate json and get command
    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 necessary, abort execution
        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:
            os.remove(msg.alert["parameters"]["alert"]["data"]["virustotal"]["source"]["file"])
            write_debug_file(argv[0], json.dumps(msg.alert) + " Successfully removed threat")
        except OSError as error:
            write_debug_file(argv[0], json.dumps(msg.alert) + "Error removing threat")
           
       
    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 os.remove() function in the active response Python script handles the removal of the malicious file:

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

2. Download Python and run the installer. Then, select the following checkboxes during installation:

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

3. Run the following command with administrative privilege to install Pyinstaller via the command prompt:

> pip install -U pyinstaller

4. Convert the Python script remove-threat.py to an executable file and run the following command to create the executable.

> pyinstaller -F remove-threat.py

5. Move the executable file remove-threat.exe from the \dist folder under your current working directory to C:\Program Files (x86)\ossec-agent\active-response\bin.

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

> Restart-Service -Name wazuh

Wazuh server

We configure VirusTotal to scan the detected files received from the Windows endpoint against public malware engines for malicious behavior. Consequently, we configure the Wazuh active response module to automatically run the Python executable when VirusTotal flags the scanned files as malicious.

VirusTotal configuration

1. Add the configuration below to the /var/ossec/etc/ossec.conf file to scan the files with VirusTotal:

<ossec_config>
  <integration>
    <name>virustotal</name>
    <api_key>API_KEY</api_key> <!-- Replace with your VirusTotal API key -->
    <group>syscheck</group>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

Active response configuration

1. Add 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>

2. Add the following rules to the /var/ossec/etc/rules/local_rules.xml file to generate alerts when the active response module successfully removes the malicious files or not.

<group name="virustotal,">
  <rule id="110006" 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="110007" 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 110006 generates an alert when the active response module successfully removes the threat.
Rule ID 110007 generates an alert when the active response module fails to remove the threat.

3. Restart the Wazuh manager to apply configuration changes:

$ sudo systemctl restart wazuh-manager

We downloaded a CrossLock ransomware sample on the Windows endpoint to test the configuration. You can see in the screenshot below that the active response module deletes the file and generates an alert of this event.

Conclusion

In this blog post, we demonstrated how to detect CrossLock ransomware activities with Wazuh. We utilized Sysmon to enrich logs from the victim endpoint and created rules to detect malicious activities associated with the CrossLock ransomware.

CrossLock ransomware uses several techniques that increase the effectiveness of the attack and make it difficult to recover files. Therefore, we encourage you to maintain proper visibility of your infrastructure to monitor such ransomware activities and take appropriate measures to remediate them before they escalate.

References

CrossLock Ransomware Emerges: New GoLang-Based Malware On the Horizon

CrossLock ransomware detection with Wazuh

CrossLock ransomware behavior

Detection with Wazuh

Using custom detection rules

Install Sysmon on the Windows endpoint

Wazuh server

Detection results

Detecting and removing CrossLock ransomware with VirusTotal and active response

Windows endpoint

Configuring the FIM module

Active response Python script configuration

Wazuh server

VirusTotal configuration

Active response configuration

Related content

Detecting malicious URLs using Wazuh and URLhaus

Ransomware protection on Windows with Wazuh

How to configure Rsyslog client to send events to Wazuh

Integrating Imperva cloud web application firewall (CWAF) with Wazuh

Use cases

Log Data Analysis

Malware Detection

Regulatory Compliance