Most intrusions are found by asking the right question of every endpoint at once, not by waiting for an alert to fire. Velociraptor turns that idea into a query language. The value is not exotic zero-day detection; it is asking a precise question of ten thousand machines and getting evidence back before an attacker finishes what they started. This guide walks through the VQL hunt patterns that reliably surface real intrusions, and explains exactly what each one catches.
What is VQL, and why hunt with Velociraptor instead of grepping logs?
VQL (Velociraptor Query Language) is a SQL-like language that queries live endpoints, forensic artifacts, and event streams across an entire fleet at once. Instead of shipping logs to a SIEM and grepping, you push a question to thousands of machines and get structured answers back in minutes, with the raw evidence attached.
- ▸Artifacts are packaged, reusable VQL you run on demand or on a schedule.
- ▸Hunts fan an artifact out across the whole fleet and collect the results centrally.
- ▸Client monitoring runs VQL continuously so process, registry, and network events stream in as they happen.
- ▸Plugins such as pslist(), netstat(), yara(), pe_dump(), and authenticode() expose live system state to SELECT, WHERE, LET, and foreach. Velociraptor also underpins the collection workflow in Forensic Triage at Scale with Velociraptor and KAPE.
How do you find in-memory injection and fileless implants with VQL?
Hunt for executable memory that no file backs. VQL can enumerate each process's memory regions and flag private, executable pages, the signature of reflectively loaded or injected code, then run YARA against only those regions. The built-in Windows.Detection.Yara.Process artifact scans live process memory across the fleet.
- ▸Enumerate VAD regions and filter for private, committed, executable pages with no mapped file.
- ▸Scan only the unbacked regions with YARA to cut false positives dramatically.
- ▸Dump a suspicious region with pe_dump() for offline analysis, then pivot to full memory forensics if you need the complete picture.
- ▸This is the fleet-wide complement to single-host RAM analysis: one query, every endpoint.
Scanning every byte of every process is slow and noisy. The pattern that scales is to let VQL do the cheap filtering first, enumerate regions, keep only the private executable ones, and hand just those bytes to YARA, so a fleet-wide sweep finishes in minutes rather than hours.
Which VQL hunts catch persistence you would otherwise miss?
Persistence hides in far more than the Run keys. VQL artifacts enumerate scheduled tasks, services, WMI event subscriptions, BITS jobs, startup folders, and registry autostart locations in a single pass, then let you filter for unsigned binaries, world-writable paths, or ImagePaths pointing at temp directories.
- ▸WMI event subscriptions via Windows.Persistence.PermanentWMIEvents, a favorite fileless persistence spot.
- ▸Scheduled tasks with suspicious actions or hidden triggers.
- ▸Services whose ImagePath points at ProgramData, AppData, or a temp folder.
- ▸Run keys and startup items through the registry and startup artifacts.
- ▸Wrap the results with authenticode() to isolate the unsigned autostarts worth investigating first.
How do you hunt malicious process ancestry and LOLBins?
Attackers reuse trusted binaries, so hunt the relationships, not the names. With Windows.Events.ProcessCreation client monitoring, VQL captures every parent-child pair, letting you alert on Office spawning PowerShell, or on rundll32, regsvr32, mshta, certutil, and wscript launching with network activity or encoded arguments.
- ▸Anomalous ancestry: winword.exe or excel.exe spawning cmd.exe or powershell.exe.
- ▸LOLBins: rundll32, regsvr32, mshta, certutil, bitsadmin used to download or execute.
- ▸Encoded command lines: base64 or obfuscated arguments to interpreters.
- ▸Join to netstat() to see which of those short-lived processes also opened a connection. Turning these repeatable hits into standing detections is the purple-team loop in From Red Team Findings to Detections: Continuous Purple Teaming.
How do you surface network beaconing and rogue listeners?
Join live socket data to the process list. VQL's netstat() plugin, joined against pslist(), shows which process owns each connection; you then filter for external destinations owned by LOLBins, unbacked processes, or unexpected listening ports, the fingerprints of C2 beacons and backdoor listeners.
- ▸Join netstat() and pslist() so every socket carries its owning process and on-disk path.
- ▸Flag external connections owned by short-lived or unbacked processes.
- ▸Flag rare or high listening ports on servers that should not be listening.
- ▸Enrich with hash() and authenticode() to spot unsigned owners, and correlate against lateral movement across Active Directory and Kerberos attack paths.
True beaconing needs timing analysis, not just a point-in-time snapshot. That is where client monitoring earns its keep: stream connection events over hours, then group by destination and look for regular intervals with jitter, the classic signature of a command-and-control implant checking in on a schedule.
How do you run Sigma and YARA at fleet scale in Velociraptor?
Velociraptor runs YARA rules against files and process memory, and executes Sigma rules over Windows event logs through community artifacts such as Hayabusa and the Sigma project. One hunt applies thousands of detection rules across the fleet and returns only the hits, with the matching EVTX record or memory region attached as evidence.
- ▸Use the Windows.Detection.Yara artifacts for file and memory signature sweeps.
- ▸Run Sigma over EVTX through Hayabusa or the Sigma artifact for log-based detection.
- ▸Keep rule sets curated and hash-enrich results so hunts stay high-signal, not noisy.
- ▸Because only hits return with their evidence, triage starts with proof, not a haystack.
The discipline that keeps this useful is curation. Thousands of raw Sigma and YARA rules will bury your analysts in low-confidence hits, so treat detection content like code: version it, tune it against your baseline, and retire rules that only ever fire on benign software in your environment.
How do you detect DFIR tools like Velociraptor being turned against you?
Public reporting, notably from Huntress, has documented attackers deploying legitimate Velociraptor installers as covert remote-access and tunneling tooling inside victim networks. Hunt for the tool you did not deploy: unexpected Velociraptor services, MSI installs, rogue client configs, and outbound connections to unfamiliar frontends.
- ▸Baseline every remote-management and DFIR tool you legitimately run, then alert on anything else.
- ▸Treat AnyDesk, ScreenConnect, and Velociraptor as dual-use: powerful for defenders and attackers alike.
- ▸Look for client configs pointing at unknown servers and services you never installed.
- ▸The lesson is broader than one tool: any signed, trusted utility can become an implant.
How do you go from a hunt hit to containment?
A hunt hit is a lead, not proof. Pivot from the hit to full endpoint context, collect a triage package for preservation, then isolate the host. Velociraptor can quarantine an endpoint, keeping the agent reachable while cutting other traffic, and pull a KAPE-style collection, so you contain and preserve in one motion.
- ▸Pivot to the process, user, and timeline around the hit before acting.
- ▸Collect a triage package and preserve a memory image for later analysis.
- ▸Apply the host-isolation artifact to contain without losing the agent.
- ▸Hand off to the eradication and notification steps in Incident Response Playbooks That Teams Actually Use.
Order matters here. Isolating a host before you collect volatile evidence can tip off an attacker and destroy memory-resident artifacts, so the sequence is usually collect, then contain, unless active data theft demands you cut the connection immediately.
How TuniCyberLabs helps
We stand up Velociraptor properly, curated artifact and hunt libraries, continuous client monitoring, Sigma and YARA pipelines, and host-isolation runbooks, then train your team to write VQL that answers questions instead of generating noise. Explore our security services to see how threat hunting fits your detection and response program.
Want a hunt program that finds intrusions before they detonate? Talk to our team.