
velociraptor answers how many machines are infected
velociraptor query "SELECT Name,Pid,Exe FROM pslist() WHERE Exe =~ 'Temp'"the question every incident responder dreads
someone reports "weird popups" on their machine, you check it out, find a process running from a temp folder that has no business existing, and now you have The Question. how many other machines have this. is it one laptop or is it three hundred. you cannot answer that by remoting into boxes one at a time while the clock runs. this is where velociraptor stops being a fancy log viewer and starts acting like a database you can just ask.
what velociraptor actually is
velociraptor is an open source endpoint monitoring and forensic tool built by rapid7 alum turned independent devs. you install a lightweight agent on your endpoints (or push it during an active incident) and it lets you run structured queries against live systems using something called VQL, velociraptor query language. it looks and feels like SQL because that was the point. you're not writing custom scripts per OS, you're asking a question and every connected endpoint answers it.
breaking down the command
velociraptor query "SELECT Name,Pid,Exe FROM pslist() WHERE Exe =~ 'Temp'"
let's take this apart piece by piece so it's not just magic incantation.
pslist() is a velociraptor function that pulls the live process list off an endpoint, basically what you'd get from task manager or ps aux, but structured as rows and columns so you can filter it.
SELECT Name,Pid,Exe tells it which columns matter to you right now: the process name, the process id, and the full path to the executable. you don't need every field, you need the ones that answer your question.
WHERE Exe =~ 'Temp' is the actual detection logic. the =~ is a regex match, and it's filtering for any process whose executable path contains "temp." legit software almost never runs its main binary out of a temp directory long term. malware droppers, on the other hand, love temp folders because they're writable by everyone and get cleaned up eventually, which also conveniently destroys evidence if you're not fast.
so in plain english: "show me every running process, on this machine, whose exe is sitting in a temp folder." one line, one answer, no manual folder browsing.
test one, then scale to all
the workflow that matters here is test small, deploy big. you run that exact query against the patient zero machine first to confirm it actually flags the bad process and doesn't just catch some installer's leftover cache file. once you trust the query, you don't rerun it by hand on every endpoint, you dispatch it as a hunt.
a hunt in velociraptor terms is the same query broadcast to every enrolled endpoint at once. instead of vpn'ing into fifty machines, you fire one hunt and every agent checks in, runs the query locally, and reports back. seconds later you have a table: hostname, process, pid, path. that table is your scope. that's the list you hand to leadership when they ask "how bad is it." not a guess, not "we think it's contained," an actual queried list.
why this matters for defenders specifically
the reason this beats manual triage isn't speed alone, it's that it doesn't touch the box. you're not logging in, not running unfamiliar tools on a potentially compromised machine, not risking tipping off an attacker who's watching for interactive logins. the agent already sitting there does the work and reports facts. that's a much smaller footprint during an active incident, and it means your evidence is consistent across every machine because it's the exact same query every time, not fifty analysts eyeballing task manager slightly differently.
the takeaway
you don't need velociraptor mid-breach to get value from this idea. deploy it now, before anything's on fire, so the agents are already enrolled when you need them. build a small library of your own sanity-check queries: processes in temp, processes with no signed binary, unexpected listening ports, whatever your environment considers weird. practice turning a single-host query into a hunt while things are calm so you're not learning the syntax during an incident. the goal isn't to memorize VQL, it's to have the muscle memory to turn "how many machines are affected" from a guess into a number you can defend in the postmortem.