Velociraptor is a great DFIR tool that becomes more and more popular amongst Incident Handlers. Velociraptor works with agents that are deployed on endpoints. Once installed, the agent automatically “phones home” and keep s a connection with the server… exactly like a malware with it’s C2 server but this time it’s for the good and not the bad. Because, I heard a lot of positive stories about Velociraptor, I decided to learn about the tool then deploy my own server and use it for investigations. There are two approaches: the first one, you proactively deploy the agent on every endpoints in your organization and you’re ready to investigate future incidents. The other one is a real incident response context and agents are deployed after the initial compromise to allow collecting evidences and keep an eye on the infrastructure for a shorter period. I’m using Velociraptor in the second approach. The agent is ready to be downloaded and deployed via a MSI package (full automation is possible through a GPO).
The first approach with Velociraptor could be sometimes a bit rocky. To interact with agents, you must use a specific query language called VQL. It looks like SQL queries but, once you understood the basics, it’s really powerful. By example, the following query returns DNS requests performed by an agent:
SELECT System.TimeStamp AS Timestamp,
EventData.QueryName AS Query,
EventData.QueryType AS Type,
EventData.QueryResults AS Answer
FROM watch_etw(guid="{95126€-7EEA-49A9-A3FE-A378B03DDB4D}")
WHERE System.ID = 3020
From a DFIR perspective, Velociraptor does the job. You can easily access the memory (take a memory image), access the filesystems, the registry, the Windows EventLogs and much more… Let’s imagine you’re working on an incident and you discover on the patient zero that the malware dropped a file in %APPDATA%. You can easily write a VQL query and search for this file on all your connected agents and discover more victims. And it’s possible to quarantine hosts where the suspicious file has been found. It’s not my goal here to explain Velociraptor deeper, if you’re interested, have a look at the documentation.
Another nice feature of Velociraptor is a way to deploy and run third-party tools on agents (and collect results of course). One of the tool I like to use to search for artefacts is the Loki IOC scanner. Loki is the small brother is a very powerful tool called Thor. Because Thor is a commercial product, I focused on Loki for this blog post. The idea is to use Velociraptor as an orchestrator to launch a scan on a suspicious endpoint:
- Download a Loki package
- Extract files
- Run Loki in “upgrade mode” to fetch the latest IOC & YARA rules
- Run Loki
- Send results back to Velociraptor
Once you select the target, you can configure some basic parameters before launching the scan:
Then you can follow the ongoing scan:
While I was writing this artifact, I found that another guy had the same project. I like the idea to upload the results back to Velociraptor for further processing, thank to Eduardo! The biggest difference between our scripts is the way Loki is deployed. When Loki is installed, the first operation it will perform is to download the latest IOC & rules. Eduardo took another approach: He prepared a stand alone Loki archive which already contains the required data. The good point: no Internet connectivity is required by the agent, everything will be downloaded from the Velociraptor server. I decided to keep the “online” approach and let Loki fetch some files from GitHub.com. It means that I don’t have to maintain a local package, every time Loki is launched it will have the latest rules but… Internet connectivity will be required.
Here is the command executed on the endpoint:
cmd.exe /c cd C:\Program Files\Velociraptor\Tools\tmp61649993\loki && \
loki-upgrader.exe --nolog && \
loki.exe --noindicator -p C:\ -l \
C:\Program Files\Velociraptor\Tools\tmp61649993\loki\win10vm-loki.csv \
--csv --dontwait
Once the scan is completed, results are available in Velociraptor for review:
Note that, by default, Velociraptor uses a timeout of 600 seconds to allow artifacts to successfully complete. Loki can be time consuming so don’t forget to increase this timeout! After many tests, I found that the best value for me was 14400 seconds (4 hours). But usually, 2 hours are more than enough.
If you’re interested in testing the artifact, it’s on my Github repository. This is a simple example of a third-party tool integration but it could give you (funny) ideas!