Velociraptor: Endpoint Visibility and Incident Response

When a cyber incident occurs, one of the first challenges is understanding what happened, which systems were involved, and what traces were left behind. In this context, Velociraptor is an open-source DFIR tool that can collect and examine endpoint data in a centralized, targeted, and repeatable way.

After completing a course focused on Velociraptor, I found it useful to summarize its main components and explain how they can be used during threat hunting and incident response activities.

What is Velociraptor?

Velociraptor is a platform for Digital Forensics and Incident Response, supporting both digital forensic analysis and incident handling.

Its operating model is built around two main components:

• Velociraptor Server: the central component that manages endpoints, collections, hunts, results, and the web interface;
• Velociraptor Client: the agent installed on the computers being investigated, including Windows, Linux, and macOS systems.

The client executes the requested queries and collection tasks locally, then sends the results back to the server. The server does not need to directly access every file on every system: it coordinates the work and collects the output produced by the endpoints.

Communication between the server and clients can be protected with mutual TLS, a mechanism in which both sides verify each other’s identity using certificates. In production environments, authentication, roles, and permissions are also important. An account that can only read results should not have the same privileges as an account that can create artifacts or launch collections across the entire organization.

What can Velociraptor collect?

Velociraptor is not limited to showing the current state of a computer. It can help reconstruct past activity, observe what is happening in real time, and collect information for the next stages of an investigation.

Examples of data that can be analyzed include:

• running processes and their parent-child relationships;
• network connections and DNS queries;
• files, hashes, and suspicious directories;
• browser history and downloads;
• the Windows Registry, Prefetch, Amcache, and Shimcache;
• system events, Sysmon, and ETW data;
• memory and other volatile information.

This distinction matters because not all data has the same lifespan. Processes, open connections, and memory contents can change quickly, while other artifacts may be overwritten or modified during normal system activity. During an incident, it is therefore advisable to collect volatile state early and analyze persistent data in more detail afterward.

Artifacts: the core building blocks

One of Velociraptor’s central concepts is the artifact. An artifact is a reusable definition containing one or more VQL queries, parameters, and instructions describing what should be collected.

An artifact can be thought of as an analysis recipe. Instead of writing the same commands repeatedly, the analyst selects an existing collection, configures its parameters, and runs it against one or more endpoints.

Artifacts are generally described in YAML. A simplified example could look like this:

name: Custom.Windows.ProcessSnapshot
description: Lists active processes on a Windows endpoint
type: CLIENT

sources:
  - query: |
      SELECT Name, Exe, CommandLine, Username
      FROM pslist()

In this example:

• name identifies the artifact;
• type: CLIENT indicates that the query runs on the endpoint;
• sources contains the queries to execute;
• pslist() returns information about running processes.

Artifacts can be client artifacts, which query the endpoint, or server artifacts, which perform tasks on the central server, such as preparing an MSI package or importing data. They can also be “one-shot” artifacts that finish after a collection, or client event artifacts that continue listening for new activity.

VQL: querying data with SQL-like logic

Velociraptor uses VQL, short for Velociraptor Query Language. Its syntax resembles SQL, but the queries are designed to retrieve information from the operating system, files, logs, and other artifacts.

A query can select only the fields that matter, filter results, and group data. For example, during a stacking analysis, processes observed across multiple endpoints can be grouped to identify what is common and what appears only rarely:

SELECT Name, Exe, CommandLine, count() AS Count
FROM source()
GROUP BY Name, CommandLine
ORDER BY Count

The result can help highlight a rare process or an unusual command line. Rarity alone does not prove compromise, of course: it should be correlated with the file path, digital signature, user, execution time, and other evidence.

Another important advantage is that collected results can be reprocessed with VQL without querying every endpoint again. This makes it possible to quickly narrow or expand the analysis as the investigation develops.

Hunts: collecting data at scale

Once a suspicious indicator has been confirmed, the analyst can launch a hunt. A hunt is a coordinated operation that runs one or more artifacts against a selected group of clients.

A typical workflow looks like this:

1. define the objective, such as searching for a file, hash, or Registry key;
2. select the most appropriate artifact;
3. configure parameters, timeouts, and resource limits;
4. select the endpoints or a client group using labels;
5. start the collection and review the results.

An offline client does not necessarily have to be excluded. It can receive the task when it reconnects to the server. It is important to remember, however, that a “selected client” is not automatically a “completed collection.” An endpoint may be powered off, unreachable, or return an error.

Hunts are particularly useful for incident scoping: determining whether activity observed on one computer is also present on other systems in the organization.

Autoruns hunts: hunting for persistence

Persistence is one of the most important areas of an incident investigation. An attacker may create a scheduled task, register a service, modify a Run key, add a Startup-folder entry, or use another autostart mechanism to execute code again after reboot or user logon.

Velociraptor includes the Windows.Sysinternals.Autoruns artifact, which runs the Sysinternals Autorunsc utility and returns configured autostart entries as rows that can be analyzed with VQL. In the course material, the artifact is configured with -a *, meaning that it collects all supported Autoruns categories rather than looking at only one persistence mechanism.

This is different from collecting scheduled-task event logs. Autoruns primarily shows the current autostart configuration, while scheduled-task logs can provide evidence of historical task activity, subject to event-log retention and rollover.

What the Autoruns artifact can reveal

A collection based on Windows.Sysinternals.Autoruns can help review several persistence locations, including:

• Logon entries: Registry Run and RunOnce keys and Startup folders;
• Scheduled Tasks: task definitions, actions, and configured triggers;
• Services and drivers: service startup configuration and driver registrations;
• Shell extensions and DLL loading;
• Application startup locations and other supported autostart categories.

The most important fields are not only the entry name. Analysts should inspect:

• Category: the persistence mechanism;
• Entry Location: where the configuration is stored;
• Image Path: the executable or DLL being loaded;
• Launch String: the complete command used to start it;
• Enabled: whether the entry is active;
• Signer and Company: available publisher and signature metadata;
• MD5 or SHA-256: hashes that can be used for enrichment and correlation.

A suspicious Autoruns entry might point to a binary in a user-writable directory, use an unusual command-line argument, reference a recently created file, or have no expected signer. These are prioritization signals, not proof of compromise. The entry should be correlated with file timestamps, process execution evidence, event logs, the user context, and the endpoint’s normal baseline.

Filtering Autoruns results with VQL

After collecting the artifact, the raw results can be filtered in a notebook or in a hunt result view. For example, the following query selects active entries without signer metadata and excludes Known DLLs located in the expected system directories:

SELECT
    Entry,
    Enabled,
    Category,
    Description,
    Signer,
    Company,
    `Image Path`,
    `Launch String`,
    MD5,
    IMP
FROM source()
WHERE Enabled = "enabled"
  AND NOT Signer
  AND NOT (
      Category =~ "Known DLLs"
      AND `Image Path` =~ "system32|syswow64"
  )

The backticks are used because fields such as Image Path and Launch String contain spaces. The query is designed to reduce the result set and identify entries worth manual review. Missing signer information should be treated as a lead for prioritization; it should not be interpreted as a definitive verdict that the file is malicious. Signature status should be verified separately.

Running an Autoruns hunt across the environment

A practical Autoruns hunt can be performed as follows:

1. select Windows.Sysinternals.Autoruns as the collection artifact;
2. configure the collection to include the required autostart categories;
3. target all clients, a department, or a label group such as investigation-2026-01;
4. launch the hunt and monitor per-client completion and errors;
5. open the hunt notebook and filter the results with VQL;
6. group entries by category, path, signer, hash, or hostname;
7. investigate the highest-priority candidates on the affected endpoints.

The hunt can be run broadly to build an enterprise-wide persistence baseline, or narrowly against compromised clients after an initial alert. Labels are useful in the second case because the response team can collect Autoruns first from a small affected group and then expand to additional systems if the same persistence mechanism is found.

Comparing Autoruns with other persistence artifacts

Autoruns should not be used in isolation. A useful persistence investigation combines several artifact types:

This distinction is important. A task can exist in the current configuration without having executed recently, while a task event log can show historical execution but may no longer contain the original task definition. Combining configuration and execution evidence gives a more complete picture.

Enriching suspicious entries

After filtering the Autoruns output, the analyst can enrich candidates with hashes, file metadata, signature information, and reputation data. For example, a candidate list may retain only enabled entries with a SHA-256 value and no signer:

SELECT
    Entry,
    Enabled,
    Category,
    Description,
    Signer,
    Company,
    `Image Path`,
    `Launch String`,
    `SHA-256` AS SHA256,
    MD5,
    IMP
FROM source()
WHERE Enabled = "enabled"
  AND NOT Signer
  AND SHA256

The resulting hashes can be compared with internal threat intelligence or an approved reputation service. Any external enrichment should follow the organization’s privacy and evidence-handling policy, because submitting a file hash or filename to a third-party service may disclose information about an incident.

The final validation step is always local correlation: inspect the file path, determine whether the entry is actually executed, identify the responsible user or service account, and compare the entry with the endpoint’s historical timeline.

Notebooks: evidence, queries, and investigative reasoning

Velociraptor’s integrated notebooks combine results, VQL queries, Markdown text, and analyst notes. This is useful because an investigation is not only about collecting data; it is also about explaining why a particular piece of evidence matters.

A notebook can contain:

• the results of a hunt;
• additional VQL queries used to filter the data;
• summary tables or visualizations;
• hypotheses and observations;
• references to affected endpoints;
• conclusions and next steps.

In practice, a notebook becomes a technical record of the investigation. It can be updated as the work progresses and shared with other analysts, reducing the need to rely on separate notes or manually executed commands that are difficult to reproduce.

One-time collections and real-time monitoring

A traditional collection captures a point in time, such as the list of active processes at 10:30. Event artifacts, on the other hand, remain active and collect new events as they occur.

They can be used to monitor:

• new process creation;
• DNS activity;
• Registry changes;
• process call chains;
• Sysmon events forwarded through ETW.

This capability is valuable during an incident when it is not enough to know what has already happened. The response team may also need to observe what the system does after isolation or when the user begins working on it again.

Continuous monitoring must be designed carefully. Every event generates data, and an overly broad configuration can increase storage, bandwidth, and resource consumption on both clients and the server.

Velociraptor in standalone mode

Velociraptor can also be used without a permanently running server through a standalone collector. This approach is useful when an endpoint must be acquired quickly or when it is not immediately possible to install an agent.

The collector runs a predefined configuration, creates an archive — for example, a ZIP file — and allows the collected data to be analyzed later. This is practical for initial triage, while the server-client model is better suited to continuous operations and investigations across many endpoints.

Technical deep dive: enriching a process snapshot

A process listing is only the starting point of an investigation. The same executable name can be legitimate or malicious depending on its path, command line, parent process, user, token, signature, and hash.

A more useful Velociraptor query can enrich each process with this context:

SELECT
    Pid,
    Ppid,
    TokenIsElevated,
    Name,
    CommandLine,
    Exe,
    token(pid=Pid) AS TokenInfo,
    hash(path=Exe) AS Hash,
    authenticode(filename=Exe) AS Authenticode,
    Username,
    Memory.WorkingSetSize AS WorkingSetSize
FROM pslist()

The query uses several VQL functions:

• pslist() returns the current process list;
• token(pid=Pid) retrieves information about the process security token;
• hash(path=Exe) calculates a hash for the executable path;
• authenticode(filename=Exe) checks Windows Authenticode information;
• Memory.WorkingSetSize exposes the approximate memory currently used by the process.

This makes it possible to ask more precise questions. For example, a suspicious row may show powershell.exe running from a temporary directory, with an encoded command line, an elevated token, and an untrusted signature. None of these facts alone proves malicious activity, but together they provide a much stronger lead than the process name alone.

The query can also be filtered with regular expressions:

SELECT Pid, Name, Exe, CommandLine, Username
FROM pslist()
WHERE Name =~ "powershell|rundll32|regsvr32"
   OR CommandLine =~ "-enc|javascript|http"

In a reusable artifact, the process names and command-line expressions would normally be parameters. This allows the analyst to change the search criteria from the GUI without editing the artifact definition every time.

From an indicator to a hunt

Suppose an analyst discovers a suspicious executable and calculates its SHA-256 hash. The next step is not only to investigate the original endpoint, but also to determine whether the same file exists elsewhere.

A hunt could use Windows.Search.FileFinder to search selected paths and calculate hashes. The investigation might include:

1. searching for the known filename or path;
2. calculating a cryptographic hash for matching files;
3. comparing the result with the original indicator;
4. collecting file metadata and timestamps;
5. recording which clients returned a match;
6. labelling affected clients for follow-up collections.

Labels are particularly useful in a longer investigation. Instead of selecting the same clients repeatedly, the analyst can assign a label such as compromised or case-2026-01 and target that group in later hunts.

It is also important to distinguish between selection and coverage. A client may be selected but offline. Another client may receive the request but fail during execution. A third may complete the collection but return no matching rows. These states should be reviewed separately when reporting the scope of an incident.

Event artifacts: from snapshots to telemetry streams

A one-shot artifact captures a point in time. A CLIENT_EVENT artifact stays active and produces rows as new activity occurs. This difference is fundamental during incident response.

For example, Windows.Events.ProcessCreation can listen for new process starts. A simplified VQL pattern can use the Windows Win32_ProcessStartTrace event source:

LET ProcessStarts = SELECT *
FROM wmi_events(
    query="SELECT * FROM Win32_ProcessStartTrace",
    wait=5000000,
    namespace="ROOT/CIMV2"
)

SELECT
    timestamp(winfiletime=atoi(string=TIME_CREATED)) AS Timestamp,
    ParentProcessID AS PPID,
    ProcessID AS PID,
    ProcessName AS Name
FROM ProcessStarts

A production-quality artifact can enrich the event with the process tracker. After a short delay, it may retrieve the command line of the new process, the command line of its parent, and the complete process call chain. A result such as:

wininit.exe <- services.exe <- VSSVC.exe

is much more informative than VSSVC.exe by itself. The parent-child relationship helps determine whether the process was started by a service, a script interpreter, an Office application, or another unexpected parent.

Other event artifacts can be used for focused monitoring:

This type of eventing can be useful when a SIEM is unavailable or when the response team needs short-term, targeted telemetry from a small set of affected endpoints. It should not be enabled indiscriminately: high-volume event streams can consume endpoint resources, bandwidth, and server storage.

Notebooks as an analytical workbench

A Velociraptor notebook combines Markdown, VQL, collection results, and investigation notes. This makes it possible to keep the technical evidence and the analyst’s reasoning together.

For example, a notebook might contain the following sequence:

1. a description of the initial alert;
2. the hypothesis that a suspicious PowerShell process was launched by an Office document;
3. the VQL used to collect processes and command lines;
4. the results of a hunt for the executable hash;
5. a query that groups the result by hostname or username;
6. a conclusion explaining which endpoints require containment.

The notebook can also be used to re-analyze collected data. Instead of querying each client again, the analyst can use source() to work on the existing result set:

SELECT Name, Exe, CommandLine, count() AS Count
FROM source()
GROUP BY Name, Exe, CommandLine
ORDER BY Count

This is useful for stacking analysis. Common processes form part of the baseline, while rare processes and unusual command lines become candidates for review. The result is not automatically a detection; it is a prioritization technique that reduces a large dataset to a manageable set of hypotheses.

A practical Velociraptor investigation workflow

Consider an EDR alert reporting that powershell.exe was launched from an unusual parent process. A structured workflow could be:

1. Preserve volatile state: collect running processes, command lines, logged-on users, network connections, services, and relevant memory information.
2. Enrich the process evidence: calculate the executable hash, inspect Authenticode status, examine the security token, and reconstruct the parent-child chain.
3. Review persistence: collect scheduled tasks, services, startup folders, Registry Run keys, UserAssist, Prefetch, Amcache, and other relevant forensic artifacts.
4. Search for the indicator: use FileFinder or another artifact to search for the hash, filename, path, or related command line across the environment.
5. Scope the incident: label matching clients and launch follow-up hunts against that label.
6. Monitor affected systems: enable process-creation, DNS, Registry, or Sysmon event artifacts on the affected group.
7. Document the outcome: record evidence, queries, timestamps, decisions, errors, and collection limitations in a notebook.

This workflow shows why Velociraptor is more than a remote command runner. The investigation progresses from a volatile snapshot, to enrichment, to fleet-wide searching, to continuous monitoring and documented conclusions.

Deployment, permissions, and scale

The Velociraptor server should be treated as a sensitive security system because it can collect data and execute queries across the organization. Strong authentication, HTTPS certificates, protected configuration files, and role separation are essential.

Typical permissions can be separated between administrators, read-only users, API users, analysts, investigators, and artifact writers. In particular, the ability to create or modify artifacts should be restricted and audited because a poorly written artifact can collect excessive data or create unnecessary load on endpoints.

Storage is another important operational constraint. A hunt that collects a small process table from every endpoint is very different from a hunt that downloads browser databases, event logs, memory-related data, or large file sets. Before launching a broad collection, estimate:

• the number of target clients;
• the amount of data expected per client;
• the available bandwidth;
• server storage and retention;
• whether clients are online simultaneously;
• the maximum acceptable CPU and I/O impact.

A good DFIR collection is not necessarily the largest one. It is the smallest collection that can answer the investigative question while preserving the evidence required for later analysis.

Standalone collection and triage

Velociraptor can also be used without a permanently running server through a standalone collector. This is useful when an endpoint is isolated, cannot reach the server, or must be collected before the normal deployment process is available.

A typical workflow is:

1. build or obtain the collector with the required artifact configuration;
2. execute it locally with the appropriate privileges;
3. retrieve the resulting ZIP archive;
4. preserve the archive and record its provenance;
5. analyze it locally or import it into a Velociraptor environment.

Standalone collection is practical for rapid triage, but it does not offer the same centralized scheduling, fleet-wide visibility, or live event monitoring as a server/client deployment. The collector configuration should therefore be designed carefully: a minimal triage pack is faster and easier to transport, while a broader forensic pack produces more evidence but requires more time, storage, and review.

Final thoughts

Velociraptor becomes most useful when its components are treated as parts of one investigation workflow:

• the client collects data locally;
• the server coordinates requests and stores results;
• artifacts package repeatable collection logic;
• VQL queries, filters, enriches, and correlates data;
• hunts scale the investigation across many endpoints;
• notebooks preserve both evidence and analytical reasoning;
• event artifacts provide focused real-time telemetry;
• standalone collectors support rapid triage when a server connection is not available.

Velociraptor does not automatically replace an EDR, SIEM, or incident-management platform. Its value is different: it gives responders a flexible way to ask precise questions directly to endpoints and turn the answers into repeatable, documented investigations.

The key idea is to move from a generic question — “What happened?” — to a structured technical process: preserve, collect, query, enrich, scope, monitor, and document.

Note: This article is an original technical summary of topics covered during the course. The examples are simplified for educational purposes and should be tested and adapted before use in production.

When a cyber incide

Alessio Dallaporta

Author

Alessio Dallaporta