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%
directoryC:\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
, andwbadmin
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 type | Value |
MD5 | 2809e15a3a54484e042fe65fffd17409 |
SHA256 | 518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c |
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:
- Using detection rules to detect the Phobos ransomware activities.
- Using the incident response capability to scan and remove files with malicious patterns.
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
and100206
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.
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.
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