Detecting and responding to Phobos ransomware using Wazuh

| by | Wazuh 4.7.3
Post icon

Phobos ransomware has become a growing concern due to its tactics in targeting state and territorial governments. The ransomware group compromises Windows endpoints using phishing as the primary method to gain initial entry, deploying covert payloads such as SmokeLoader and Cobalt Strike. Also, attackers exploit vulnerable networks by scanning and brute-forcing open Remote Desktop Protocol (RDP) services to deploy Phobos ransomware. 

Phobos ransomware operates by establishing persistence in systems, taking advantage of process injection techniques to execute malicious code and evade detection. It also modifies the Windows Registry to maintain persistence within compromised environments.

This blog post explores how to use Wazuh to detect and respond to Phobos ransomware attacks on Windows endpoints.

Phobos ransomware behavior

Phobos ransomware exhibits several behaviors when it infects a Windows endpoint. These behaviors include the following:

  • Replicates itself to a hidden system location on the %AppData% directory C:\Users\*\AppData\Local\phobos.exe.
  • Phobos ransomware places itself in the Startup folder and adds registry keys for persistence.
  • The ransomware disables the system firewall using the netsh in command prompt:
netsh advfirewall set currentprofile state off
netsh firewall set opmode mode=disable
  • It uses the vssadmin, wmic, and wbadmin commands to delete volume shadow copies and catalogs thereby preventing their victims from recovering their encrypted files.
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
wbadmin delete catalog -quiet
  • It modifies the boot record and prevents the ability of system recovery using the bcdedit command.
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
  • It uses the Windows native binary mshta.exe to display the ransom note to victims.
mshta C:\%USERPROFILE%\Desktop\info.hta
mshta C:\%PUBLIC%\Desktop\info.hta
mshta C:\info.hta

Analyzed IoC file

Hash typeValue
MD52809e15a3a54484e042fe65fffd17409
SHA256518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c

Infrastructure

We use the following infrastructure to demonstrate the detection of Phobos ransomware with Wazuh,

  • A pre-built ready-to-use Wazuh OVA 4.7.3. Follow this guide to download the virtual machine.
  • A Windows 11 victim endpoint with Wazuh agent 4.7.3 installed and enrolled to the Wazuh server. Refer to the installation guide to install the Wazuh agent. 

Detection with Wazuh

We use the following techniques to detect the Phobos ransomware on the infected Windows endpoint:

Detection rules

We use Sysmon to monitor several system events on the Windows endpoint and create rules on the Wazuh server to detect the malicious activities of Phobos ransomware activities.

Windows endpoint

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

1. Download Sysmon from the Microsoft Sysinternals page.

2. Using Powershell with administrator privilege, create a Sysmon folder in the endpoint C:\ folder:

> New-Item -ItemType Directory -Path C:\Sysmon 

3. Extract the compressed Sysmon file to the folder created above C:\Sysmon.

> Expand-Archive -Path "<PATH>\Sysmon.zip" -DestinationPath "C:\Sysmon"

Replace <PATH> with the path where Sysmon.zip was downloaded.

4. Download the Sysmon configuration file – sysmonconfig.xml to C:\Sysmon using the Powershell command below:

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

5. Switch to the directory with the Sysmon executable and run the command below to install and start Sysmon using PowerShell with administrator privileges:

> cd C:\Sysmon 
> .\Sysmon64.exe -accepteula -i sysmonconfig.xml

6. Add the following configuration within the <ossec_config> block of the C:\Program Files (x86)\ossec-agent\ossec.conf file:

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

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

> Restart-Service -Name wazuh

Wazuh server

We create custom rules to generate alerts when Phobos ransomware activities are detected on the Windows endpoint. Perform the following steps to create detection rules on the Wazuh server.

1. Create a custom rule file phobos_ransomware_rules.xml in the /var/ossec/etc/rules/ directory:

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

2. Add the custom rules for Phobos ransomware below to the /var/ossec/etc/rules/phobos_ransomware_rules.xml:

<group name="phobos, ransomware,">

<!-- Suspicious file creation -->
  <rule id="100201" level="12">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:\\Users\\.+\\AppData\\Local\\.*exe</field>
    <description>The executable $(win.eventdata.image) created a copy of itself $(win.eventdata.targetFilename) in a system folder.</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>

<!-- Persistence detection --> 
  <rule id="100202" level="15">
    <if_sid>92300</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\.exe</field>
    <field name="win.eventdata.eventType" type="pcre2">(?i)SetValue</field>
    <field name="win.eventdata.targetObject" type="pcre2">(?i)HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\[A-Za-z0-9]+</field>
    <description>New run key added to registry by $(win.eventdata.image).</description>
    <mitre>
      <id>T1547.001</id>
    </mitre>
  </rule>

 <rule id="100203" level="12">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\.+\.exe</field>
    <description>$(win.eventdata.targetFilename) added to Startup programs by $(win.eventdata.image).</description>
    <mitre>
      <id>T1547.001</id>
    </mitre>
  </rule>

<!-- Impair defenses -->
 <rule id="100204" level="12">
    <if_sid>92042</if_sid>
    <field name="win.eventdata.CommandLine" type="pcre2">netsh  advfirewall set currentprofile state off</field>
    <description>Windows firewall disabled.</description>
    <mitre>
      <id>T1562</id>
    </mitre>
  </rule>

<!-- System recovery inhibition -->
 <rule id="100205" level="12">
     <if_sid>61603</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)vssadmin\s\sdelete\sshadows\s\/all\s\/quiet</field>
     <description>Volume shadow copy deleted using $(win.eventdata.originalFileName). Potential ransomware activity detected.</description>
     <mitre>
       <id>T1490</id>
       <id>T1059.003</id>
     </mitre>
  </rule>

 <rule id="100206" level="12">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.CommandLine" type="pcre2">wmic  shadowcopy delete</field>
    <description>$(win.eventdata.originalFileName) invoked to delete shadow copies. Potential ransomware activity detected.</description>
    <mitre>
      <id>T1490</id>
      <id>T1059.003</id>
    </mitre>
  </rule>

 <rule id="100207" level="12">
     <if_sid>61603</if_sid>
     <field name="win.eventdata.CommandLine" type="pcre2">(?i)bcdedit\s\s\/set\s{default}\sbootstatuspolicy\signoreallfailures</field>
     <description>Boot configuration data edited.</description>
     <mitre>
       <id>T1059</id>
     </mitre>
  </rule>

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

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

<!-- Ransom note file creation -->
  <rule id="100210" level="12" timeframe="100" frequency="2">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:\\.*8base</field>
    <description>The file $(win.eventdata.targetFilename) has been created in multiple directories. Phobos ransomware activity detected.</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>

</group>

Below is the list of rule IDs that are triggered when activity associated with Phobos ransomware is detected:

  • Rule ID 100201 is triggered when the ransomware creates a copy of itself in the %APPDATA% directory.
  • Rule ID 100202 is triggered when a new run key is added to the registry.
  • Rule ID 100203 is triggered when an executable file is added to the startup folder.
  • Rule ID 100204 is triggered when the ransomware disables the Windows firewall.
  • Rule IDs 100205 and 100206 are triggered when the shadow copies are deleted on the victim endpoint.
  • Rule ID 100207 is triggered when the boot status policy is modified.
  • Rule ID 100208 is triggered when system recovery on the endpoint is disabled.
  • Rule ID 100209 is triggered when the system backup catalog is deleted.
  • Rule ID 100210 is triggered when there are changes to the file extension on the Windows endpoint after encryption.

3. Restart the Wazuh server for the changes to take effect:

# systemctl restart wazuh-manager

Detection results

The screenshot below shows the alerts generated on the Wazuh dashboard when Phobos ransomware is executed on the victim’s Windows endpoint. From the Modules tab on your Wazuh dashboard, click on Agents to select the Windows endpoint, then select Security events tab to view the generated alerts.

Phobos Ransomware alerts
Figure 1: Phobos ransomware alerts on the Wazuh dashboard

Detecting and removing Phobos ransomware with VirusTotal and Active response

VirusTotal is a platform that provides an API that can detect security threats by querying it with URLs, IP addresses, 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 that are added or modified in specific directories on the Windows endpoint. Furthermore, we configure the Wazuh active response module to remove any files that have been identified 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 Phobos ransomware file, append 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:

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

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

1. Download the latest Python and run the installer. Select the Use admin privileges when installing py.exe and Add Python.exe to PATH checkboxes on the installer dialog box.

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

> pip install -U pyinstaller

3. 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"])

4. Convert the Python script remove-threat.py  to an executable file by running the command below:

> 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 Wazuh 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 files monitored by 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. Append 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 -->
    <rule_id>554,550</rule_id>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

Note: Replace the <API_KEY> with your VirusTotal API key

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,">

<!-- VirusTotal detection rules -->

  <rule id="200201" 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="200202" 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 200201 generates an alert when the active response module successfully removes the threat.
  • Rule ID 200202 generates an alert when the active response module fails to remove the threat.

3. Restart the Wazuh manager to apply configuration changes:

# systemctl restart wazuh-manager

Active response result

A variant of Phobos ransomware is added to the Download folder on the Windows endpoint to test the configuration. The screenshot below shows the file integrity monitoring and active response alerts on the Wazuh dashboard.

VirusTotal Active Response alerts
Figure 2: VirusTotal and Active response alerts on the Wazuh dashboard

Conclusion

In this blog post, we showed how to detect and respond to Phobos ransomware on a Windows endpoint with Wazuh. We utilized Sysmon integration to enrich Windows event logs from the victim endpoint and then created rules to detect malicious activities associated with Phobos ransomware. We also combined VirusTotal with the Wazuh Active response to scan and remove the Phobos ransomware file from the victim endpoint.

Wazuh is a free and open source enterprise-ready security platform for threat detection, incident response, and compliance. Wazuh integrates seamlessly with third-party solutions and technologies. Wazuh also has an ever-growing community where users are supported. To learn more about Wazuh, please check out our documentation and blog posts.

References