Simulating and Analyzing BlackMatter Ransomware Behavior

Posted Apr 22, 2025 Updated Apr 22, 2025

By Arjun Tarakesh

24 min read

`Read the full blog here:https://medium.com/@arjuntarakesh01/simulating-and-analyzing-blackmatter-ransomware-behavior-adff20c2d9e0`

Introduction to BlackMatter Ransomware

BlackMatter is a ransomware-as-a-service (RaaS) family that emerged in July 2021, believed to combine the “best features” of the DarkSide, REvil, and LockBit ransomware operations. In practice, BlackMatter targets organizations (especially those with $100M+ revenue) in big-game ransomware attacks, often tailoring each attack’s payload — for instance, generating a unique ransom note with victim-specific details. It encrypts data on Windows (and even Linux servers) using strong cryptography, and demands hefty ransoms for decryption. This blog post will demonstrate a dynamic malware analysis of a BlackMatter sample using the ANY.RUN sandbox platform. We’ll walk through key behaviors observed (Indicators of Compromise, or IOCs) and map how this analysis feeds into the first two phases of the NIST Incident Handling process: Preparation and Detection & Analysis. Along the way, we’ll highlight how such analysis aids in identifying and responding to an incident, and suggest practical tips and tools — from free sandboxes and VirusTotal to YARA rules — that readers can adapt in their own environments. Finally, we’ll touch on what well-equipped teams (with SIEM and EDR tools like Splunk and Microsoft Defender) could do in later incident response phases (Containment, Eradication, and Post-Incident).

Dynamic Analysis of BlackMatter using ANY.RUN

ANY.RUN is an interactive online sandbox that allows analysts to safely execute malware in a virtual environment and observe its behavior in real-time. For this analysis, we detonated a BlackMatter ransomware sample in ANY.RUN and monitored the system processes, file system changes, and network traffic it produced. The sandbox immediately flagged the sample as malicious ransomware, and the following behaviors were observed:

Process Execution and Privilege Escalation: Upon launch, the malware process (bearing the hash of the sample) spawned additional processes. Notably, it invoked a Windows component used for User Account Control (UAC) bypass. The sample launched a dllhost.exe process with a special CLSID (COM interface) – a technique (known from the DarkSide toolkit) to silently elevate privileges via the ICMLuaUtil COM object. In the ANY.RUN process tree, we saw the malware process inject code into a svchost.exe service process (running as SYSTEM), confirming process injection for privilege escalation. With SYSTEM-level permissions acquired, the ransomware had free rein on the system.
File System Activity — Encryption and Ransom Note: Once running with high privileges, BlackMatter began scanning and modifying files. The sandbox logged 1,762 file read events in a short time, indicating the malware was enumerating files (likely to encrypt them). A handful of file write events were observed corresponding to encryption or creating new files. Crucially, the ransomware dropped a ransom note on the Desktop — in our run, a file named **AwlCQEBCC.README.txt** appeared on the Admin’s desktop. (BlackMatter generates a uniquely named *.README.txt file for each victim as its ransom note, often containing the victim ID or name) The malware then opened this note using Notepad, which is a common ransomware tactic to ensure the victim sees the ransom instructions immediately. We can consider the appearance of oddly named .README.txt files a strong IOC for ransomware on any system.
Persistence Mechanism: The analysis also revealed that BlackMatter tries to persist on the infected machine. ANY.RUN’s behavioral indicators showed “Process was added to the startup”, meaning the malware attempted to create an auto-run entry. In fact, BlackMatter is known to set RunOnce registry keys in both the current user and local machine hives to ensure it runs on reboot. By adding itself to HKCU\\...\\RunOnce (and/or HKLM\\...\\RunOnce), the ransomware would relaunch after a system restart, maintaining its foothold. This persistence IOC (new Run/RunOnce registry entries with suspicious executables) is something defenders can look out for.
Defense Evasion and Destructive Actions: Like many ransomware strains, BlackMatter takes steps to impede security and recovery. During sandbox execution, the malware triggered the Volume Shadow Copy Service (vssvc.exe) on Windows. This likely indicates an attempt to delete shadow copies (to prevent the victim from restoring files). BlackMatter is reported to disable or stop security services as well – for example, it will kill processes for antivirus, backups, and other tools to avoid detection and remove backups. Although our sandbox run didn’t explicitly show commands like vssadmin delete shadows (possibly done through API calls rather than spawning cmd.exe), the involvement of vssvc.exe and the malware’s known behavior suggest it was attempting to wipe backups. The sample’s internal configuration (exposed via debug strings) even showed flags like “autoconfirmation of UAC: on” (for auto-elevating privileges) and “network: on” (enabling network communication), indicating how it was geared for stealth and propagation. All these actions – killing security software, deleting backups, and using stealthy techniques – point to defense evasion and impact tactics that align with BlackMatter’s playbook.
Network Communication — Command & Control: Perhaps the most illuminating finding was the malware’s network traffic. Shortly after execution, the infected sandbox attempted to make an HTTP POST request to an external server. The destination domain was **mojobiden.com**, and it was contacted over port 80 (HTTP) at an IP address in the AWS cloud (15.197.148[.]33). ANY.RUN’s network panel flagged this domain as malicious, as it is not a normal OS behavior to post data to such a domain. In fact, mojobiden.com is a known BlackMatter C2 (Command-and-Control) domain – it has been identified in threat intelligence reports and is associated specifically with BlackMatter/DarkSide operations. The sandbox captured the full URL and query string being accessed, which likely contained encrypted telemetry or keys from the ransomware (common in ransomware is to send a unique ID or encryption key to the attackers’ server). This outbound connection is a critical IOC: any host reaching out to mojobiden.com (or related domains like paymenthacks.com, another BlackMatter domain) is very likely compromised by this ransomware.

Indicators Summary from the Sandbox:

The dynamic analysis provided a wealth of IOCs and clues about the malware. To summarize, some key IOCs and behaviors observed include:

File Indicators: The malicious executable’s hash (for our sample, SHA-256 520bd9...c42e57), and the dropped ransom note file (_README.txt on user desktop). In an incident, finding such a ransom note file on a system is a red flag of active ransomware.

Virustotal check for the hash value

Persistence Registry Keys: Creation of autorun entries in registry (e.g., Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\RunOnce) pointing to the malware executable. This ensures the ransomware runs again after reboot – an artifact defenders can check in registry hives.

Spawned System Processes: Execution of dllhost.exe with UAC bypass parameters and injection into svchost.exe (as observed with a #BlackMatter tag in ANY.RUN’s process graph). This indicates the malware attempted privilege escalation via a COM object exploit. Unusual instances of dllhost.exe (especially if it’s a child of a suspicious process) or abnormal svchost behavior could be detected via EDR telemetry.
File Access Patterns: Mass file reads and writes, and invocation of Volume Shadow Copy deletion. The spike in file I/O (with many file read events in a short time) is symptomatic of encryption ransomware. Likewise, any event of shadow copy deletion (via vssadmin or VSS service) on a user workstation is highly suspicious.

Virustotal — Activity summary

Network Indicators: The domain mojobiden.com (and its resolved IP, e.g. 15.197.148.33) contacted over HTTP by the malware. This domain is associated with BlackMatter’s C2 infrastructure, and seeing it in DNS logs or network traffic is a clear IOC. In our analysis, ANY.RUN marked this domain “malicious” on reputation, confirming it as an indicator. (Network traffic to other benign domains like Windows Update and certificate servers was also observed, but those were expected OS activity and flagged as whitelisted).

Sandbox Behavior graph

Figure: ANY.RUN sandbox “Process” view highlighting the BlackMatter sample’s behavior. The malware (red-outlined) launches via a UAC bypass (_CMSTPLUA_ and _dllhost.exe_) to gain high integrity, injects into a _svchost.exe_ process (labeled *#BLACKMATTER), and later spawns Notepad to display the ransom note. The sandbox also flags numerous suspicious behaviors at the bottom (e.g. low-level disk access, added to startup, network attacks detected, integrity level elevation).*

As shown above, the sandbox’s process graph and alerts make it clear that this is ransomware activity. We have identified the malware sample (and could submit its hash to VirusTotal for cross-reference), the artifacts it leaves (like the ransom note and registry keys), and the C2 communications it attempts. All of these pieces are invaluable for incident response. Now, let’s connect these findings to how an incident responder would use them in the context of NIST’s Incident Response phases.

Img Source: https://rhyno.io/blogs/cybersecurity-news/nist-incident-response-plan-steps-and-template/

Preparation: Laying the Groundwork for Analysis

The Preparation phase is all about being ready before an incident occurs — having the right tools, knowledge, and procedures in place. An organization cannot improvise an effective response on the fly; establishing capabilities ahead of time is critical. In our scenario, preparation would mean:

Establishing Tools & Environment: Ensure you have access to malware analysis tools (or services) and know how to use them. For example, setting up accounts with an online sandbox like ANY.RUN (or an on-premise sandbox solution) in advance, and having a process to safely detonate suspicious files, is part of preparation. The same goes for being ready to use resources like VirusTotal (for file and URL scanning) and having YARA tools available. NIST emphasizes acquiring and maintaining tools to detect and investigate incidents — in practice, this means having things like sandboxes, SIEM dashboards, EDR consoles, etc., at your disposal before you actually need them in an emergency.
Threat Intelligence and Knowledge Base: Preparation includes staying informed about current threats. Knowing about ransomware like BlackMatter ahead of time — its typical behavior, IOCs, and mitigation strategies — will significantly speed up detection and analysis. For instance, an organization might subscribe to threat intel feeds or read reports (CISA alerts, vendor blogs) about emerging threats. If you knew beforehand that BlackMatter uses certain domains (like mojobiden[.]com) or drops .README.txt notes, you could proactively add those indicators to your monitoring systems. Having YARA rules or signatures for BlackMatter on hand is another example. (Security researchers and vendors often publish YARA rules for new malware; Recorded Future, for example, provided a YARA rule and IOCs to help organizations hunt for BlackMatter.) Being prepared with this intel means when an alert fires, you can quickly recognize “aha, this looks like that BlackMatter ransomware behavior we read about.”
IR Plan and Team Readiness: On a broader level, the preparation phase entails having an incident response plan and team training. This includes defining roles (who analyzes malware? who communicates to management? etc.) and practicing procedures. A prepared team will have playbooks for common incidents like ransomware. For example, there should be a checklist for “suspected ransomware outbreak” that includes steps like isolating the host, preserving forensic data, and analyzing a sample of the malware in a sandbox. Regular drills and tabletop exercises can ensure the team is familiar with using tools like ANY.RUN or Splunk under pressure. As NIST guidance suggests, continuously improve your plan with lessons learned and ensure everyone knows their responsibilities.
Preventative Preparation: Although our focus here is on analysis, it’s worth noting that part of preparation is also implementing preventive measures (to reduce the likelihood or impact of ransomware). This includes maintaining reliable data backups (so that if encryption occurs, you can recover without paying ransom), using least-privilege principles (to slow down an attacker’s privilege escalation), and keeping systems patched (many ransomware gangs, including BlackMatter, often gain initial access through unpatched vulnerabilities or stolen credentials). While these don’t stop an attack already in progress, being prepared in these ways can limit damage and make incident response easier.

In summary, by the end of the Preparation phase, an organization should be “armed and ready” — with tools like sandbox environments available, detection content (like YARA rules or SIEM use-cases) developed for known threats, and an IR team that knows the game plan. This solid foundation enables a swift and confident move into the next phase when an incident (such as a suspicious ransomware file being detected) occurs.

Detection & Analysis: Identifying the Attack through Sandbox Findings

The Detection & Analysis phase is where an incident is detected, investigated, and confirmed. In our example, let’s say a security alert comes in — perhaps an EDR agent on a workstation flags that a process is exhibiting ransomware-like behavior (e.g., encrypting many files), or a user reports a strange ransom note on their screen. Once such an alert or precursor sign is received, the incident response team’s job is to analyze it and determine what’s happening. This is exactly where our ANY.RUN malware analysis fits in.

Using the sandbox, we were able to observe indicators of compromise that confirm the incident as a BlackMatter ransomware attack. Here’s how those analysis results tie into the Detection & Analysis process:

Confirming the Threat: Initially, an alert might not tell you which malware or threat actor is involved — only that something odd is occurring. By taking a sample of the suspicious file and running it in ANY.RUN, we quickly confirmed malicious activity and even identified it as ransomware. The sandbox’s verdict of “malicious activity: ransomware” and the behavior (encryption and ransom note) gave us high confidence that this is a ransomware incident. This analysis moves us from just detection of “an anomaly” to positive identification of BlackMatter ransomware. In NIST terms, we’ve taken an indicator and determined it is indeed part of a real incident, not a false alarm.
Severity and Scope Assessment: The details gathered (the IOCs and behaviors discussed) help gauge the severity and scope. For example, seeing communication to a known BlackMatter C2 domain tells us this is an active attack potentially involving data exfiltration or coordination with a human operator (common in “big game” ransomware cases). The presence of a ransom note indicates data has been encrypted and a ransom demand is in play. These factors elevate the incident to a critical severity requiring rapid containment (since ransomware can spread to shared drives or other systems). Additionally, by analyzing the malware, we learned how it persists and spreads (RunOnce keys, possible network propagation if enabled). This helps determine what to look for on other machines — for instance, we might suspect that if one machine is hit, the malware could attempt to spread via network shares (depending on its config). All this analysis feeds into how we’ll contain and eradicate (upcoming phases), but it starts here in Detection/Analysis by scoping the incident.
Indicators of Compromise for Hunting: The IOCs extracted from the sandbox run (file hash, file names, registry keys, IP/domain, etc.) can now be used to hunt across the environment and identify any other affected hosts. During analysis, we documented these IOCs thoroughly. For example, with the domain mojobiden.com identified, a security analyst can query DNS logs or a network monitoring system to see if any other host has attempted to reach that domain. Likewise, the knowledge that BlackMatter creates HKLM\\RunOnce entries can lead an analyst to check other systems’ registries (via an EDR query) for the presence of that specific autorun key pointing to the malware. This hunting process is part of analysis – figuring out if the incident is isolated to one machine or if it’s an outbreak affecting many. The sandbox’s quick revelation of those IOCs greatly accelerates this step.
Malware Sample Enrichment: In many cases, detection teams will also upload the malware sample to multi-scanner services like VirusTotal. Given the hash from our analysis, we could look it up on VirusTotal to see if it’s flagged as BlackMatter/DarkSide by other antivirus engines, or if other sandbox reports (from tools like Cuckoo or Intezer, which VirusTotal might show) corroborate our findings. This cross-verification can bolster confidence. Additionally, threat intelligence platforms could be used to see if the hash or domain was seen in previous incidents. All of this falls under analysis — gathering as much context as possible about the detected malware.
Communication of Findings: Part of the Detection & Analysis phase is also documenting and escalating the incident with the facts. The analysis we performed provides a clear narrative to communicate: “We have confirmed a ransomware attack (BlackMatter). The malware gained SYSTEM privileges, encrypted data, and attempted to call out to attacker infrastructure. IOCs X, Y, Z have been identified.” This would be recorded in an incident tracking system and reported to decision-makers so they understand the gravity. Having concrete data from the sandbox (screenshots of the ransom note, logs of the malicious traffic) can be extremely persuasive in galvanizing the response effort.

In essence, the ANY.RUN sandbox analysis transformed a nebulous alert into a well-defined incident. We pinpointed specific indicators and malicious behaviors — exactly what NIST calls for in this phase, to identify indicators and analyze them to confirm an incident. The result of the Detection & Analysis phase is a comprehensive understanding of the incident: we know we’re dealing with BlackMatter ransomware, how it operates, and what artifacts it leaves. Armed with this knowledge, we can now proceed to contain the attack and ultimately eradicate it. Before moving on to those next steps, let’s consider some practical tools and tips that can help analysts in environments with varying levels of resources achieve what we just did.

Tools and Tips for Malware Analysis & Detection in Any Environment

Every organization’s tooling and budget differ, but the good news is that effective malware analysis and threat detection can be accomplished with flexible approaches. Our walkthrough used ANY.RUN (which has a free community version), but even if you don’t have a paid sandbox or enterprise-grade tools, you can still investigate malware and gather IOCs using a combination of free or low-cost resources. Here are some practical suggestions, adaptable to your environment:

Interactive Sandboxes (Cloud-Based or Local): Leverage platforms like ANY.RUN (interactive sandbox) or other cloud sandboxes to safely run suspicious files. ANY.RUN’s community edition allows anyone to upload a malware sample and observe live behavior in a controlled VM, which is exactly how we uncovered BlackMatter’s actions. Other options include Triage (from Hatching), Joe Sandbox Cloud, or open-source solutions like Cuckoo Sandbox if you can host one. The key is to detonate the file in an isolated environment not connected to your production network. If using a cloud service, be mindful of uploading sensitive files (you wouldn’t upload proprietary data, but unknown malware binaries are usually fine). These sandboxes often provide detailed reports with process trees, network traffic, and even automatic IOC extraction, accelerating your analysis.
Static Analysis and Multi-Engine Scanning: If running the malware is not immediately possible, start with static analysis. A quick approach is to upload the file to VirusTotal (VT). VirusTotal will scan the file with dozens of antivirus engines — in the case of BlackMatter, many AV engines would likely flag it as some variant of DarkSide/BlackMatter, giving you an initial confirmation. VT also often provides behavioral snippets or sandbox report excerpts. Additionally, you can use hash searches on VT or other databases: since our sample had a known hash, we might find it was already seen and reported elsewhere. If you cannot share the file with an online service, you can use local AV scanners in a lab environment or tools like PE Studio for static insights (strings, imports, etc.). These static clues can complement dynamic analysis — for example, strings might reveal the ransom note text or the domain (sometimes domains like mojobiden.com can be found in the binary strings).
YARA Rules for Hunting: YARA is a tool that allows you to write rules to identify malware based on patterns (like strings or binary sequences). Security communities and vendors often publish YARA rules for notable malware. For BlackMatter, one could obtain a YARA rule from repositories (e.g., the Trellix/FireEye ATR team’s public YARA rules, or from CISA reports). You can use these rules to scan your environment for any files that match BlackMatter’s fingerprint. For instance, run YARA across file shares or endpoints to see if any other copies of the ransomware exist. YARA can also be used on memory dumps or process memory to catch injected code. If you have a SIEM, some support YARA or you could deploy a script via EDR to run YARA on endpoints. Even without writing your own rules, look to freely available rulesets — as an example, Recorded Future’s Insikt Group shared a YARA rule specifically to detect BlackMatter ransomware in August 2021. Such a rule could be run on any suspicious binaries to quickly identify them as BlackMatter. In summary, YARA adds a customizable detection layer that you control, which is very handy for new or targeted malware that might not be caught by traditional AV signatures yet.
IOCs and Threat Intelligence Feeds: Make use of public IOC feeds and reports. Our analysis surfaced IOCs like the domain and file hashes. Often, organizations like CISA publish these in alerts (for BlackMatter, see CISA Alert AA21–291A) and maintain lists of known bad domains, IPs, and hashes. Ensure your security controls (firewalls, DNS filters, endpoint agents) are ingesting these so they can automatically block or alert on them. For instance, you could plug the domain mojobiden.com into your DNS firewall or proxy block list as soon as you learn of it. If you don’t have automated feeds, you can manually input IOCs into tools: e.g., search your Splunk logs for occurrences of those IOCs (even before an incident, to see if perhaps it’s already in your historical logs). As a flexible approach, even free tools like Microsoft’s IOC Scanner (IoCs) or open-source ACE can be fed a list of IOCs and scan endpoints for matches. The main idea is to share and leverage knowledge: many indicators we found are not unique to our environment, they are part of BlackMatter’s global operations, so take advantage of community knowledge to bolster your detections.
Endpoint and Network Monitoring: If enterprise tools are limited, you can use built-in OS logging and free tools to monitor for suspicious events. For example, enabling Windows Defender (even the built-in AV) with cloud protection can sometimes catch ransomware behavior or known signatures. Defender, in fact, has a detection name for BlackMatter (e.g., Ransom:Win32/BlackMatter.MAK!MTB in Microsoft’s taxonomy), and it attempts to stop such processes. Ensure it’s up to date on all machines as a baseline. Additionally, you might use Sysmon (a free Sysinternals tool) to log process creations, file modifications, and registry changes on endpoints; combined with a log aggregator, this can help detect patterns like an unusual process adding itself to startup or deleting shadow copies. On the network side, if you don’t have a fancy IDS, even router/firewall logs or freeware IDS like Snort/Suricata with updated rules can catch known malicious domains or traffic patterns. For instance, an IDS might have a rule to flag HTTP posts with certain user-agent or URI patterns that BlackMatter uses. While these require some setup, they are cost-effective ways to achieve detection capabilities.

The bottom line: even a small team on a tight budget can replicate much of what we did by intelligently combining free tools and services. An analyst can get a lot of mileage out of a sandbox like ANY.RUN and community-curated intel. The key is to practice using these tools before an incident (tying back to Preparation) so that when something happens, you know exactly where to go — be it detonating a file in a sandbox, scanning it on VirusTotal, or pulling a YARA rule from GitHub to run a quick hunt.

Beyond Analysis: Containment, Eradication, and Post-Incident Actions

In a well-resourced environment (with solutions like Splunk for SIEM and Microsoft Defender for Endpoint as an EDR), the latter phases of incident response — Containment, Eradication & Recovery, and Post-Incident Activity — can be executed efficiently using those tools. Let’s assume our analysis has confirmed BlackMatter on one machine; here’s how a team might proceed in the next phases using enterprise tools:

Containment

Isolate infected host using Microsoft Defender for Endpoint (MDE) — prevents further spread and C2 communication (e.g., to mojobiden.com).
Terminate ransomware process or run a remote scan via MDE.
Block malicious domains/IPs with firewall rules.
Restrict access to shared drives to prevent ransomware from encrypting network data.
Disable compromised accounts or reset credentials, especially if attacker used admin accounts (e.g., BlackMatter tactics).
Use Splunk to investigate user behavior, login patterns, and detect lateral movement.

Eradication & Recovery

Reimage infected machines — safest route due to system corruption/encryption.
Preserve forensic evidence before wiping (e.g., via MDE investigation package or system snapshots).
Threat hunt across endpoints using EDR/Splunk: look for hashes, unusual connections to C2 domains.

Isolate/remediate any additional compromised hosts.

Restore data from clean backups — ensures business continuity without paying ransom.
Post-restore hardening:
Run full AV scans.
Remove persistence (e.g., RunOnce registry keys).
Reset critical credentials, revoke sessions/VPN tokens.

Post-Incident Activity

Root cause analysis with Splunk logs — determine initial attack vector (e.g., phishing, RDP, vulnerability).

Improve defenses based on findings:

Enhance patch management.
Implement MFA.
Train users.
Strengthen firewall rules.

Update incident response plans and playbooks.

Add detection logic (e.g., Splunk correlation searches for README.txt, suspicious process chains).

Upload IOCs to EDR tools (hashes, domains, IPs) for proactive alerting/blocking.

Coordinate with law enforcement (especially for BlackMatter or high-impact ransomware).

Share IOCs with information-sharing communities per NIST guidance.

In summary, Containment and Eradication of BlackMatter would rely on swift action using EDR/SIEM capabilities to isolate affected systems, remove the malware, and restore data. Post-Incident, the focus shifts to fortifying defenses: patching the holes, improving processes, and updating detection content so that if (or when) another attack comes, the team is even more prepared.

Conclusion

Dynamic malware analysis of ransomware like BlackMatter provides invaluable insights during an incident. In our walkthrough, using the ANY.RUN sandbox allowed us to witness the ransomware’s behavior first-hand — from privilege escalation tricks to file encryption and calling home to a C2 server — and to extract concrete IOCs that drove our response. We saw how these findings map to the NIST Incident Response lifecycle: thorough Preparation made such analysis possible, and the Detection & Analysis phase was greatly enriched by the sandbox data, enabling effective.

ANY.RUN REPORT:

https://any.run/report/520bd9ed608c668810971dbd51184c6a29819674280b018dc4027bc38fc42e57/598fc549-eeb4-4ae9-ac88-76980bc3d8d3?source=post_page-----adff20c2d9e0---------------------------------------

References

Projects

This post is licensed under CC BY 4.0 by the author.