Digital forensics tools give responders god-level control of an endpoint: remote shell, file collection, and arbitrary queries across a whole fleet. That is exactly why attackers have started deploying Velociraptor themselves. Through late 2025, public reporting from Huntress described intrusions where threat actors installed this open-source DFIR platform as covert remote access and a staging point for ransomware. The lesson is uncomfortable but clear: the same capabilities that make a DFIR agent invaluable to defenders make it a near-perfect intrusion tool once an attacker controls the server.
What is Velociraptor, and why are attackers abusing it?
Velociraptor is a free, open-source DFIR platform (now maintained under Rapid7) that lets responders hunt across thousands of endpoints using its own query language, VQL. Attackers abuse it as a living-off-the-land remote access tool: it is signed, widely trusted, and gives them remote shell, file transfer, and fleet-wide execution without deploying obvious malware.
- ▸It is a legitimate, digitally signed binary, so it often sails past allowlists and looks benign to analysts.
- ▸One server can control many agents, giving an intruder instant command-and-control at scale.
- ▸It joins the broader trend of RMM and admin-tool abuse (AnyDesk, Atera, ScreenConnect), but with forensic-grade collection built in.
- ▸VQL is expressive by design, letting an operator query files, registry, processes, and event logs, or run commands, from one console across Windows, Linux, and macOS agents.
- ▸The agent normally runs as a persistent service, so once enrolled it survives reboots and gives durable access with almost no additional footholds to detect.
How do attackers weaponize Velociraptor in an intrusion?
Reported intrusions follow a familiar RMM-abuse pattern: after initial access, the attacker installs a Velociraptor client, points it at their own server, then uses VQL and the built-in shell to move laterally, pull tooling, and stage encryption. Public analysis tied at least some activity to an outdated build carrying a known privilege-escalation flaw.
- ▸Install: a silent MSI or standalone executable, often via msiexec or a script, registering a Windows service that runs as SYSTEM.
- ▸Connect: the client configuration points to attacker infrastructure, frequently fronted by a tunneling service to blend outbound traffic.
- ▸Operate: VQL runs remote commands, exfiltrates files, and drops further payloads; in ransomware cases it maintained access alongside the encryption stage.
- ▸Public reporting linked some incidents to an older version affected by a privilege-escalation vulnerability (associated with CVE-2025-6264), a reminder to watch versions, not just presence.
What does Velociraptor abuse look like on disk and on the wire?
The tool leaves distinct artifacts. On disk you will find its YAML configuration and a service; on the network you will see TLS to an unfamiliar server, often with a self-signed certificate whose issuer names the Velociraptor CA. The strongest single signal is simple: a Velociraptor server or client you did not deploy.
- ▸Service install: Windows Event ID 7045 recording a new service, commonly named Velociraptor, with an image running as SYSTEM.
- ▸Config artifacts: client.config.yaml or server.config.yaml on disk, containing embedded CA certificates, a nonce, and server URLs (those URLs are attacker infrastructure and gold for indicators of compromise).
- ▸Registry writeback: keys under HKLM\SOFTWARE\Velocidex\Velociraptor holding client state.
- ▸Process and command line: velociraptor.exe invoked with client, service install, or config flags.
- ▸Install traces: MSI cache entries, Prefetch for velociraptor.exe, and script or scheduled-task remnants used to deploy it silently.
- ▸Network: outbound TLS to ports such as 8000 for client communications, or a GUI on 8889, terminating at a domain that is not yours.
One caution: renaming is trivial. A capable operator may rename the binary, the service, and the config paths, so pair name-based rules with behavioral signals such as the self-signed CA subject and the fleet-of-one egress pattern below.
Which detections catch a rogue Velociraptor deployment?
Build detections around unexpected presence and anomalous configuration rather than the binary alone, since the binary is legitimate. Combine EDR telemetry, Sysmon, and Windows logs, and hunt with the same DFIR tooling you already run. Alert on any install you did not initiate.
- ▸Service creation: alert on Event ID 7045 (and the Sysmon service-install event) where the service name or image path references Velociraptor or Velocidex.
- ▸Process creation (Sysmon Event ID 1): velociraptor.exe or unusual signed binaries running with client or config arguments.
- ▸Certificate and JA3/JA4 hunting: self-signed TLS whose subject or issuer contains Velociraptor CA.
- ▸File and registry hunts: client.config.yaml, server.config.yaml, and the Velocidex registry path.
- ▸Egress anomaly: a workstation opening long-lived outbound TLS to a single external host it has never contacted, especially through a tunneling provider, is worth an alert on its own.
- ▸Publicly available Sigma rules and Velociraptor's own hunts can flag rogue instances; treat all DFIR and RMM tooling as a monitored category of unexpected admin software. Our continuous purple teaming loop is where these detections get written and validated.
How do you harden a legitimate Velociraptor deployment?
If you run Velociraptor for real, make an unauthorized instance impossible to hide. Lock down who can deploy it, pin approved versions, and treat every install event as security-relevant. The goal is that only your one sanctioned server and its enrolled clients ever exist, and any deviation pages someone.
- ▸Application control: WDAC or AppLocker allowlists so only your approved, version-pinned binary runs; block unknown copies.
- ▸Patch and version-pin: track the version to avoid known flaws like the privilege-escalation issue above, and alert on any other build appearing.
- ▸Server hardening: restrict GUI and API access, enforce SSO/OIDC with MFA, segment the server, and rotate API keys.
- ▸Egress control: allow client traffic only to your Velociraptor server domains, and block unsanctioned tunneling services.
- ▸Deployment governance: require change tickets and named approvers for any DFIR-agent rollout, so an undocumented install is suspicious by definition.
- ▸Baseline and monitor: inventory every legitimate agent so a rogue enrollment stands out immediately. For the wider control set, see Runtime Security with eBPF.
What should you do if you find an unauthorized Velociraptor server?
Treat it as an active, hands-on-keyboard intrusion, not a stray tool. Preserve the configuration before you remove anything: the embedded server URLs are attacker infrastructure and the enrolled-client list scopes the compromise. Then isolate, hunt for ransomware staging, and run your full response.
- ▸Preserve: copy the configuration and certificates for indicators of compromise before deletion.
- ▸Scope: enumerate every enrolled client to map how far the attacker reached.
- ▸Contain and eradicate: isolate affected hosts, revoke credentials, and remove the service, following playbooks your team actually uses.
- ▸Investigate: pull memory and disk artifacts to confirm what ran; memory forensics often reveals the payloads and C2. If encryption was staged, work your ransomware resilience plan.
- ▸Report: if personal data was in scope, factor regulatory clocks such as the GDPR 72-hour notification and NIS2 incident reporting into your timeline from the first hour, not the last.
How TuniCyberLabs helps
We help teams tell legitimate DFIR tooling from weaponized copies: version-pinned deployments, application-control policies, detection engineering for RMM and DFIR abuse, and rapid response when the tool has already turned hostile. We also run the forensic investigation across endpoint and cloud so you can prove scope rather than guess it.
Worried a defensive tool is being used against you? Contact our DFIR team for a rapid triage.