Velociraptor — Architecture Evaluation for Cirius DFIR

Purpose

Evaluate Velociraptor (open-source DFIR tool maintained by Rapid7 originally authored by Mike Cohen) as the Cirius DFIR and threat-hunting platform. This is decision input for Rory — it does not deploy anything. The recommendation at the bottom is a proposal, not an action taken.

Velociraptor is not currently deployed at Cirius. Today, DFIR-grade forensic collection relies on Cortex XDR forensics (limited scope), Arctic Wolf's on- demand data collection (SLA-bound, not analyst-driven), and manual PowerShell from Rory's workstation. The evaluation below asks whether Velociraptor closes the gap between those three at a cost/complexity level that makes sense for a ~20-node estate.

What Velociraptor Is

Velociraptor is an endpoint visibility and DFIR tool. Short version: a central server hosts a library of forensic collection "artifacts" (YAML definitions of what to collect). Agents on endpoints (velociraptor.exe / velociraptor on Linux/macOS) connect back to the server over TLS and execute collections on demand.

Key properties:

Single statically-linked Go binary — server and agent are the same binary, just different subcommands
Runs on Windows, Linux, macOS
Agents initiate outbound TLS to the server — no inbound firewall holes on endpoints
Communication protocol is gRPC over HTTP/2 with mutual TLS
Queries are written in VQL (Velociraptor Query Language — a SQL-like language for grep/find/parse-style operations across endpoint data)
Artifacts library covers: Windows Event Logs, registry, prefetch, Amcache, MFT, USN journal, browser history, scheduled tasks, services, persistence mechanisms, process listing, memory acquisition via DumpIt, KAPE target collection, and hundreds more
Client-side "monitoring" artifacts can run continuously (e.g., watch for process creation matching a pattern, stream results back)

What it is not:

Not an EDR. No real-time blocking, no behavioral detection. Velociraptor is for investigation, not prevention. Cortex XDR remains the EDR of record.
Not a SIEM. Results go to the Velociraptor server's artifact store; we forward selective results to LAW and/or SecOps, but Velociraptor is not where we do long-horizon detection.
Not a compliance tool. It is possible to build FIM-style artifacts, but that is not its purpose.

Why Consider It Now

Three recent pain points surfaced the question:

KAPE-style triage acquisition. In the April quarterly tabletop, we realized Cirius has no standard procedure for collecting the KAPE Targets set from a suspected-compromise Windows VM quickly. Options today are slow (manual RDP + PowerShell) or SLA-bound (request to Arctic Wolf).
Threat hunting. The kill chain agent work in progress relies on log data already landed in LAW. Hunting outside logged telemetry — running Windows.System.Pslist across the estate to look for a specific DLL, for instance — has no tooling today.
Evidence preservation. HIPAA audit expectation is that we can preserve evidence from a compromised endpoint with a defensible chain of custody. Ad-hoc PowerShell does not meet that bar.

Velociraptor addresses all three: fast triage collections, on-demand VQL hunts, and artifact-store chain of custody with hash-sealed outputs.

Server Deployment Options

Velociraptor server requires:

A reachable HTTPS endpoint for agents
A data directory for the artifact store and datastore (BoltDB or MySQL/Postgres)
~2 vCPU / 4-8 GB RAM for a ~20 node deployment (doubles during active collection)
TLS certificate — can be self-signed (agents pin it), Let's Encrypt, or an internal CA. Arctic Wolf and Cortex precedent: we use Let's Encrypt for public endpoints and an internal CA for tenant-internal ones.

Option A — Azure Linux VM (Ubuntu 24.04)

Run the server as a single Linux VM in Azure PROD, probably in a dedicated resource group rg-velociraptor-prod, on the management spoke VNET.

Pros.

Dead simple. Matches existing Cirius VM operational patterns (we already have SYSLOG*, Cloud PC is now EC2-class but conceptually identical).
Terraform module windows-server does not apply here, but an equivalent linux-server module exists.
Full control over the server — BoltDB on attached managed disk, backups via Recovery Services Vault.
Network topology straightforward: agents hit velociraptor.ciriusgroup.com (public DNS, Azure public IP, WAF-or-direct, Palo Alto inbound rule).

Cons.

Another VM to patch, monitor, and run an EDR on.
Server startup and long-running process management — we own systemd.
Scaling past a few hundred agents would require moving the datastore to managed SQL; at 20 nodes, a non-issue for years.

Cost estimate. B2s VM (~$30/mo) + 128 GB managed disk with backups (~$10/mo) + public IP (~$4/mo) + diagnostic settings to LAW (~$5/mo) = ~$50/month run-rate. Plus one-time setup.

Option B — Azure Container Apps

Package the Velociraptor server as a container image in ciriusagentsprod.azurecr.io and run it on Azure Container Apps in a dedicated environment, similar to the ca-secops-prod pattern.

Pros.

No VM to patch. Patches ship as image updates in CI.
Matches the ca-secops-prod operational pattern.
Scale-to-zero possible for the frontend, though the datastore container needs to stay up to receive agent check-ins.

Cons.

Velociraptor's default BoltDB datastore is filesystem-backed — Container Apps ephemeral filesystem does not work. Requires either Azure Files mount (works but adds latency and introduces a networked filesystem dependency on the critical path) or migrating to MySQL/Postgres datastore (supported by Velociraptor but not the default path and adds a managed DB dependency).
TLS cert management in Container Apps is painless (managed), but if we want mTLS agent pinning, it's an extra config layer.
Long-running collections that stream data back may bump against Container Apps request timeout behavior.
Less community precedent; most Velociraptor deployments are VM/bare-metal.

Cost estimate. Container Apps (~$60/mo baseline) + Azure Files premium (~$25/mo for the datastore volume) + PostgreSQL Flexible Server if going the managed-DB path (~$40/mo). Realistic total with the full managed-DB path: ~$120/month. Container-Apps-with-file-share path: ~$85/month.

Comparison

Dimension	Linux VM (A)	Container Apps (B)
Monthly run-rate	~$50	~$85–120
Operational familiarity	Higher (VM patterns)	Higher (Container Apps patterns)
Datastore complexity	Low (BoltDB local)	Medium-High (Files or MySQL)
Patching model	OS patch + app patch	Image rebuild
EDR required	Yes (Cortex)	No
Scale headroom	Sufficient for years at 20–200 nodes	Same
Recovery story	Restore VM from RSV	Rebuild from image + restore datastore
Community precedent	Dominant	Rare
Recommended for Cirius	YES	No

Recommended server option: A (Linux VM). The datastore-in-container-apps path is more friction than we gain back in deployment model parity. A single Ubuntu 24.04 VM with BoltDB, RSV backup, Cortex agent, auditd, forwarded to LAW is a known operational pattern.

Agent Deployment

Agents are the same binary as the server, just run with the client command and a tenant-specific config file (embedding the server URL and a server certificate fingerprint). Agents authenticate to the server via an enrollment token.

Windows — Azure VMs and laptops

Deployment via Intune:

Package the Velociraptor MSI with a pre-baked client.config.yaml wrapping the PROD server URL and cert fingerprint
Create Intune Win32 app velociraptor-client, assign to the existing dynamic groups AzureVMs-Prod, AzureVMs-DDE, ManagedLaptops
Agent installs as a Windows service (velociraptor, running as LocalSystem)
Config file protected by file system ACL; agent config contains no secrets other than the server URL and cert fingerprint (enrollment is one-time-token based)

For DDE tenant — same pattern, separate Intune tenant, separate AW-Agent-* analog group Velociraptor-Client-DDE.

Linux — ops hosts

Single package (DEB) via Ansible or cloud-init user-data. Systemd service. Config lives in /etc/velociraptor/client.config.yaml, readable by root only.

macOS — managed laptops

PKG via Intune MDM. LaunchDaemon config. Same client config pattern.

AWS EC2 — Windows and Linux

Windows EC2: SSM document velociraptor-install-win — same MSI pushed via SSM Run Command, bootstrapped during terraform apply for new instances (our Cloud PC onboarding pattern).

Linux EC2: user-data at launch pulls the DEB from an S3 bucket in the Logging account (s3://cirius-artifacts-logging/velociraptor/) and installs, same pattern we use for the syslog VMs.

Enrollment

Velociraptor uses a one-time-token enrollment model — tokens are generated server-side, embedded in the packaged client config, and consumed on first connect. Tokens are per-OS-class (all Windows laptops share a token; all Azure PROD VMs share a token; etc.) — this is acceptable because the token's job is gating enrollment not authorization. Post-enrollment, the agent is identified by its certificate.

Token rotation cadence: quarterly, fold into the quarterly security review.

Integration with SecOps

Velociraptor's own notebook/reporting interface is capable, but the Cirius operating model puts SecOps as the system of record for findings. Integration:

Findings pipeline

Velociraptor artifacts that represent a detection (e.g., a hunt that found Mimikatz on 2 hosts) post to SecOps via the Velociraptor server notebook's webhook action:

POST /api/ingest/findings
X-API-Key: <velociraptor-service-key from Key Vault>
{
  "source_system": "PROD",
  "source": "velociraptor_hunt",
  "ioc_key": "velociraptor:<hunt-id>:<host>",
  "severity": "HIGH",
  "finding_type": "dfir_hunt_match",
  ...
}

ioc_key includes source_system to prevent cross-tenant dedup collisions per the Cirius finding-ingestion standard.

Evidence archive

Artifact-store outputs that are worth preserving for audit (memory captures, KAPE collections, timeline deliverables) are exported as ZIP, hash-sealed, and uploaded to the 6-year HIPAA evidence archive (s3://cirius-evidence-logging/ velociraptor/<YYYY>/<incident-id>/). A SecOps evidence record points to the S3 object via POST /api/evidence.

Change management

Any Velociraptor hunt (a collection that runs across all agents) is logged in the CM tickets stream as type=dfir_hunt. This gives SecurityAgent visibility — a hunt is an authorized admin action, and the correlation dampens noise from the hunt itself.

Recommended Architecture for ~20 Nodes

Estate scale: approximately 20 active agent-capable endpoints — Windows VMs in PROD + DDE + AWS, handful of Linux VMs (syslog forwarders, Cloud PC), and managed laptops. Room to grow to 100 over the next couple of years without re-architecting.

                           ┌──────────────────────────┐
                           │ velociraptor.ciriusgroup │
                           │     .com  (Azure DNS)    │
                           └────────────┬─────────────┘
                                        │ HTTPS/TLS
                           ┌────────────▼────────────┐
                           │   Palo Alto PROD FW     │
                           │   inbound rule: allow    │
                           │   443 → VELOCIRAPTOR-VM │
                           └────────────┬────────────┘
                                        │
                           ┌────────────▼────────────┐
                           │   VELOCIRAPTOR-VM        │
                           │   Ubuntu 24.04, B2s      │
                           │   Cortex agent, auditd   │
                           │   BoltDB datastore       │
                           │   /var/lib/velociraptor  │
                           │   RSV daily backup       │
                           │   Diagnostic → LAW       │
                           └────────────┬────────────┘
                                        │ gRPC/mTLS
            ┌───────────────────────────┼───────────────────────────┐
            │                           │                           │
    ┌───────▼────────┐        ┌─────────▼────────┐         ┌────────▼────────┐
    │ PROD Windows   │        │ DDE Windows VMs  │         │ AWS EC2 Windows │
    │ VMs (Intune    │        │ (Intune DDE      │         │ (SSM install)   │
    │ PROD deploy)   │        │ deploy)          │         │                 │
    └────────────────┘        └──────────────────┘         └─────────────────┘

            ┌─────────────────────┐          ┌──────────────────────┐
            │ Managed laptops     │          │ Linux utility VMs    │
            │ (Intune MDM)        │          │ (Ansible / cloud-init│
            └─────────────────────┘          └──────────────────────┘

Sizing

Server: 1x B2s Ubuntu VM, 128 GB disk, RSV daily backups, in rg-velociraptor-prod, PROD subscription
Datastore: BoltDB on the VM's managed disk. Migration path to MySQL if we exceed 200 agents.
Agents: ~20 at go-live, expected growth to 50-100
Network: public DNS velociraptor.ciriusgroup.com, public IP, Palo Alto inbound allow for 443 only, scoped to VELOCIRAPTOR-VM. Agents on DDE and AWS reach the server via public DNS (simplest), with source IP allowlist on the Palo Alto rule restricting to known egress IPs of the three environments.
Auth: server SSO to Entra PROD via OIDC (Velociraptor supports OIDC — Entra PROD group SecOps DFIR controls access)
Logging: Velociraptor audit log forwarded to LAW via syslog-ng on the server (same pattern as other VMs)

Cost — annual

Item	Monthly	Annual
B2s VM (Ubuntu 24.04)	$30	$360
128 GB managed disk + RSV backup	$12	$144
Public IP + egress	$8	$96
Diagnostic forwarding to LAW	$5	$60
Cortex XDR agent license (existing seat)	$0	$0
Velociraptor software	$0 (open source)	$0
Total infrastructure run-rate	~$55	~$660

One-time setup: ~8 hours Kobe time for Terraform module, CI/CD, Intune packaging and assignment, initial artifact pack enabling. No licensing cost.

Risks and Mitigations

Risk	Impact	Mitigation
Single-server availability gap during agent check-ins	Temporary loss of hunt capability	RSV daily backup, rebuild-from-image SOP. No real-time detection dependency.
Agent misconfiguration blasting the server	DoS-style, full datastore, server OOM	Rate-limit at artifact scheduler, cap concurrent collections per host
Malicious use of Velociraptor for lateral movement	Adversary running VQL to exfiltrate if they compromise the server	Server in a restricted management subnet, SSH via Twingate only, Cortex + auditd on the VM, admin MFA via Entra, audit log forwarded to LAW
Key material / certs	Agent trust hijack if server cert stolen	Cert rotation annually, mTLS pinning on agent, cert issuance tracked in Key Vault
Scope creep into EDR territory	Overlap with Cortex, confusion about ownership	Clear charter in this document — Velociraptor is DFIR + hunting, Cortex remains EDR of record
Data residency / PHI in captures	Captures may contain PHI	Evidence archive is in the HIPAA-scoped S3 bucket with WORM and 6-year retention, same boundary as other forensic evidence

Recommendation

Proceed with Velociraptor deployment, Option A (Linux VM), as specified above. Scope the go-live work as its own epic:

Terraform module velociraptor-server producing the VM, NSG, public IP, backup, diagnostic settings
CI/CD: standard terraform plan on PR, apply on merge
Initial config: OIDC with Entra PROD, default artifact pack enabled, notebook webhook to SecOps /api/ingest/findings
Intune Win32 app + assignment for Windows agent (PROD + DDE)
SSM document for Windows EC2 bootstrap
Ansible play for Linux agent
Runbook velociraptor-operations.md authored alongside go-live (separate story — HUNT-007)
Tabletop: run a simulated KAPE triage collection as part of the next quarterly tabletop

Do not deploy until Rory approves. Cost is modest but the surface area (new service, new TLS endpoint, new agent across estate) is a real change and must go through change management and tabletop.

velociraptor-operations.md — day-to-day operator runbook (authored alongside go-live)
edr-cortex-xdr.md — EDR layer, complementary to Velociraptor DFIR
arctic-wolf-mdr-scope-gap.md — MDR scope boundary
incident-response.md — overall IR procedure
cmdb-guide.md — CMDB will gain has_velociraptor_agent column

Change History

Date	Change	Author
April 2026	Initial evaluation — recommend Linux VM deployment, ~$660/yr	Kobe

Velociraptor — Architecture Evaluation for Cirius DFIR ​

Purpose ​

What Velociraptor Is ​

Why Consider It Now ​

Server Deployment Options ​

Option A — Azure Linux VM (Ubuntu 24.04) ​

Option B — Azure Container Apps ​

Comparison ​

Agent Deployment ​

Windows — Azure VMs and laptops ​

Linux — ops hosts ​

macOS — managed laptops ​

AWS EC2 — Windows and Linux ​

Enrollment ​

Integration with SecOps ​

Findings pipeline ​

Evidence archive ​

Change management ​

Recommended Architecture for ~20 Nodes ​

Sizing ​

Cost — annual ​

Risks and Mitigations ​

Recommendation ​

Related Documents ​

Change History ​