Detecting Phobos: What a Ransomware Actually Does, and the Rule That Stops It

Most write-ups on a ransomware family just paraphrase someone else's report. We detonated it. A live Phobos sample, run in our isolated lab under full instrumentation. Here is exactly what it did, step by step, and the detection rule we forged from it, validated across several distinct samples.

The playbook, watched live

The moment the sample runs (from %Temp%), the chain unfolds:

1. The binary launches cmd.exe.
2. From cmd.exe, it calls vssadmin to delete the Volume Shadow Copies, your Windows restore points are wiped.
3. Still through cmd.exe, it disables the Windows firewall with netsh.
4. It encrypts files and drops dozens of artifacts to disk (encrypted files and the ransom note).

Our instrumentation confirmed the tell-tale behaviors without ambiguity: anomalous file deletion, access to public folders, anti-sandbox timeouts, and environment reconnaissance (computer name, keyboard layout, locale). The classic targeted-ransomware playbook.

Why it matters

The first two actions are the nastiest, and they happen before encryption:

• No more recovery. By deleting the shadow copies, Phobos strips away native Windows recovery. By the time the ransom note appears, a simple rollback is already off the table.
• Firewall down. Killing the firewall clears the path for lateral movement and exfiltration.

In other words: the ransomware sets the stage before it encrypts. And that window, right there, is exactly where you should catch it, not once the files are already gone.

The detection: target the behavior, not the sample

From this detonation we forged a Sigma rule that targets the signature sequence: cmd.exe orchestrating the destruction of backups and the firewall:

title: Phobos Ransomware Shadow Copy Deletion and Firewall Disabling via cmd.exe
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\cmd.exe'
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all: ['delete', 'shadows']
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains|all: ['shadowcopy', 'delete']
  selection_netsh_fw:
    Image|endswith: '\netsh.exe'
    CommandLine|contains|all: ['advfirewall', 'state off']
  condition: selection_parent and (selection_vssadmin or selection_wmic or selection_netsh_fw)
level: high
tags: [attack.t1490, attack.t1562.001, attack.t1562.004, attack.t1059.003]

ATT&CK: T1490 (Inhibit System Recovery), T1562.001/004 (Impair Defenses: tools & firewall), T1059.003 (Windows Command Shell).

What sets this rule apart

It does not look for a hash, a filename, or a mutex: those indicators change from one sample to the next and go stale within hours. It targets the family's behavioral DNA: deleting backups and tearing down defenses through the command shell.

The concrete result: forged from one sample, tested against four distinct Phobos detonations, it detects three out of four, with zero false positives on our corpus of legitimate binaries. (The fourth sample spotted the sandbox and never executed, which is exactly why you detonate multiple variants.) A rule that generalizes to the family, not to a single specimen.

And because these techniques (wiping shadow copies, disabling the firewall from the command line) are shared across many ransomware families, this rule catches far more than Phobos alone.

How to use it

This rule ships in the ThreatClaw detection feed, ready to load into your SIEM or EDR (Sigma, convertible to your backend). It is part of a batch forged from our own detonations, not copied from elsewhere, and validated against false positives.

We do not just list threats. We run them, watch what they do, and write the detection that holds.

Detonation performed in an isolated lab with no outbound connectivity. No victim credentials are published.