Skip to content

Beware of Tools that Hackers Repurpose for Command ’n’ Control

Velociraptor leveraged in ransomware attacks

Date: October 2025 Primary Source: Cisco Talos – Velociraptor leveraged in ransomware attacks (Cisco Talos Blog)

🧠 Overview

Cisco Talos reported threat actors abusing Velociraptor (a legitimate open-source DFIR tool) as part of ransomware intrusions—using it for remote command execution, persistence, and operational control as the attack progresses. (Cisco Talos Blog)

This is part of a broader trend: adversaries increasingly “live off the land” by repurposing legitimate admin/IR tooling to reduce the need for custom malware and to blend into normal IT workflows. (Cisco Talos Blog)

💡 What Is Velociraptor?

Velociraptor is an endpoint DFIR platform used by defenders to collect artifacts, hunt across fleets, and perform incident response tasks. Its power and legitimacy are exactly what makes it attractive to attackers once privileged access is obtained. (Cisco Talos Blog)

🔥 What Talos Observed

In the observed incidents, adversaries reportedly used Velociraptor in ransomware playbooks (including campaigns involving LockBit, Babuk, and Warlock), and Talos noted reporting that Velociraptor had been used to download/execute Visual Studio Code, likely to establish tunneling for attacker C2 workflows. (Cisco Talos Blog)

Talos assessed with moderate confidence that the activity aligned with a China-based threat actor tracked as Storm-2603. (BleepingComputer)

⚠️ Why “Legitimate Tooling C2” Breaks Traditional Defenses

RMM/DFIR tools are difficult for traditional controls because they are often:

  • Signed and broadly deployed in enterprises
  • Designed to execute commands remotely
  • Capable of persistence and fleet-wide action
  • Similar to legitimate admin activity (harder to separate “good” from “abuse”)

So even strong AV/EDR stacks can end up detecting abuse late (after tool install, after first remote commands, or after lateral movement), especially if the operator is using stolen admin credentials and “known good” binaries. (Dark Reading)

🛡 How White Cloud Security Trust Lockdown Stops This Attack Class

Least-Privilege Zero-Trust App Firewall

White Cloud Security Trust Lockdown enforces execution-level Zero Trust (default-deny) using a file’s explicit approval status, not the user’s privilege level.

In Trust Lockdown, “Administrator” does not mean “allowed to run anything.”

Core idea: identity and permissions do not automatically grant software execution authority. The OS may permit an admin to attempt an install/launch — but Trust Lockdown still evaluates the executable and blocks it if it’s not explicitly approved.

What This Means for RMM/DFIR Tool Abuse

If a threat actor tries to introduce Velociraptor (or any other remote-control tooling):

  • Drop the binary? Allowed (files can be written)
  • Attempt to run/install it? Blocked unless explicitly approved
  • Repack/rename it? Still blocked (approval is per-binary, not per-name)
  • “But I’m Domain Admin”? Still blocked

This breaks the ransomware workflow before the attacker can operationalize remote tooling for C2, lateral movement, or automated deployment.

🧬 Why the Block is Reliable: 6-Factor Cyber-Metric Handprint

Trust Lockdown identifies executables using WCS’s Cyber-Metric Handprint Technology (hashes + file length). That means approvals are tied to the exact binary, preventing common bypass strategies such as:

  • Renaming the tool
  • Repacking or patching the tool
  • Swapping versions
  • Delivering “look-alike” binaries

🔍 Prevention Before Execution

Trust Lockdown:

  • Logs the execution attempt
  • Records the full handprint
  • Identifies the initiating user and process
  • Surfaces the event for security review

🧭 Mermaid Sequence Diagram: Attack vs. WCS Block

sequenceDiagram
    autonumber
    participant TA as Threat Actor
    participant ADM as Compromised Admin Account
    participant EP as Endpoint (Windows/macOS/Linux)
    participant WCS as WCS Trust Lockdown (Zero-Trust App Firewall)
    participant RMM as Velociraptor/RMM Tool
    participant C2 as Attacker C2/Operator

    TA->>ADM: Steal creds / token / session
    ADM->>EP: Remote logon / RDP / PSRemoting / admin channel
    TA->>EP: Drop Velociraptor installer/binary to disk
    Note over EP: File write may succeed<br/>Execution is the control point

    TA->>EP: Attempt to install/launch Velociraptor (RMM)
    EP->>WCS: Intercept process creation (launch/install)
    WCS->>WCS: Compute 6-Factor Handprint & check approvals
    alt White Cloud Security Blocks Unapproved Tools
        WCS-->>EP: Deny execution (Default-Deny)
        WCS-->>EP: Log attempt + user/process + handprint
        EP-->>TA: Tool fails to run
        Note over TA: No operational RMM/C2 foothold established
    else Without a "Least Privilege" Zero Trust App Firewall
        WCS-->>EP: Allow execution
        EP->>RMM: RMM agent/service starts
        RMM->>C2: Beacon / remote command channel established
        TA->>C2: Remote command execution + lateral movement
    end

    Note over WCS: Zero Trust applies even to admins<br/>Privilege ≠ execution authority

⚖️ Side-by-Side Comparison: AV vs EDR vs Traditional Allow-Listing vs WCS Trust Lockdown

Capability / Outcome Traditional AV EDR / XDR Traditional Allow-Listing Competitors WCS Trust Lockdown (Least-Privilege Zero-Trust App Firewall)
Default posture Default-allow; block known bad Default-allow; detect/respond Often mixed; policy varies Default-deny (Zero-Trust execution)
Legitimate RMM/DFIR tools Often allowed (signed/known) Often allowed; may alert on behaviors Often allowed by publisher/cert/path rules Blocked unless explicitly approved
Admin runs unknown tool Frequently allowed Frequently allowed (then monitored) Often allowed if admin can install / if broad rules exist Blocked even for admins unless approved
Controls “execution” vs “detection” Mostly detection Detect + respond Depends (often rule-based allow) Prevention before execution
Repacked/modified tool variant May miss if not known May detect based on behavior (late) Often bypassable if rules are too broad Blocked (binary-specific approval)
Speed of protection After signature/reputation updates After suspicious activity is observed Policy dependent Immediate (no cloud reputation required)
Best at stopping Known commodity malware Post-compromise visibility & response Known/approved apps at scale Unknown/unapproved execution, including abused admin tooling
Typical failure mode “It’s signed/legit, so it runs” “We saw it after it started” “Publisher/path exceptions too broad” “Only runs if explicitly approved”

Bottom line: When attackers weaponize legitimate tooling (Velociraptor, RMM agents, remote shells), the winning control is the one that prevents unapproved execution up front—not the one that tries to interpret intent after the tool is already running. (Cisco Talos Blog)

✅ Key Takeaways

  • Threat actors are abusing Velociraptor as part of ransomware operations. (Cisco Talos Blog)
  • “Legitimate” tools can be repurposed for C2, remote execution, and persistence. (Cisco Talos Blog)
  • WCS Trust Lockdown blocks unauthorized software before execution, even when attackers operate through admin-level access.

🔗 References

  • Cisco Talos: Velociraptor leveraged in ransomware attacks (Cisco Talos Blog)
  • Rapid7: Identifying and Mitigating Potential Velociraptor Abuse (Rapid7)
  • BleepingComputer summary (Storm-2603 + ransomware families): (BleepingComputer)
  • Dark Reading coverage (context + detection considerations): (Dark Reading)