Velociraptor → Carbon Black
Velociraptor ↔ Carbon Black: integration to migration path.
Velociraptor co-installs alongside the Carbon Black sensor first — idle and read-only, with the Cb tamper-protection allow-list updated so the two never fight. Then it progressively takes over IR collection, proactive hunting and, optionally, continuous monitoring. No flag day, no sensor removal, and every phase rolls back in minutes.
The honest exception is the headline: Velociraptor is not a prevention engine, so this is a partial migration. Cb keeps prevention and Watchlist detection on every host — we say so up front, because the rest only matters if you can trust it.
The idea
Own hunt and IR. Keep Cb for prevention.
The topology that makes this zero-downtime: the Velociraptor client runs co-resident with the Cb sensor on every in-scope host, idle by default, with the Cb tamper-protection allow-list including the Velociraptor binary by path, hash and signing cert — and Velociraptor's exec capabilities disabled except for the IR responder role. Cb keeps owning prevention, Watchlists and cloud analytics; Velociraptor owns artifact-level forensic depth, VQL hunts, memory acquisition and offline collectors. That co-installed pair is both the overlap topology and the realistic end-state.
The phases
Six steps. Each one reversible.
Baseline & inventory
We document Cb sensor count by OS and Linux kernel diversity, the Cb policy tiers and active Watchlists, Live Response audit volume, average IR cycle time, current forwarder destinations and cost, and which hosts need offline triage. The IR runbook is captured as it works today, so we know exactly what we are replicating. Read-only.
Stand up Velociraptor; canary
A Velociraptor server cluster (frontend, GUI, S3/MinIO filestore) goes live in-region. Between 50 and 200 canary endpoints across each OS class get the Velociraptor client co-installed beside the Cb sensor, with the Cb tamper-protection allow-list updated for the Velociraptor binary by path, hash and signing cert. Read-only artifacts only — no monitoring enabled yet.
Move IR collection to Velociraptor
The default IR runbook step — collect artifacts from a suspect host — routes through Velociraptor: event logs, prefetch, the $MFT, browser history, memory triage with in-memory YARA. The Velociraptor client rolls to 100% of in-scope endpoints, still idle. Remote shell stays on Cb Live Response; Velociraptor exec is gated to the IR responder role and audited.
Move proactive hunting to Velociraptor
Threat-hunting's primary surface becomes Velociraptor hunts — VQL across the fleet against a hypothesis, scoped by client label. Cb Process Search is retained as the corroborating process-history source. Each hunt artifact is tagged with its ATT&CK technique manually in the artifact YAML.
Monitoring artifacts to SIEM (optional)
A defined set of monitoring artifacts — process create, DNS, PowerShell, scheduled tasks — is enabled per client label and forwarded to the SIEM, on a 10% slice first then ramped over two to three weeks. SIEM rules author against this shape in addition to Cb Watchlist alerts. Cb Watchlist detection is not removed; this is addition, not substitution.
Stable partial co-existence
This is the end-state, not a retirement. Cb is retained on every in-scope endpoint as the prevention agent and Watchlist detection source; Velociraptor is the hunt and IR forensic agent, plus optional continuous telemetry. The split of responsibility for SOC, IR and hunting teams is documented and exercised in quarterly tabletops. No further phase removes Cb.
Feature parity
Where each tool genuinely leads.
| Capability | Velociraptor | Carbon Black | Parity |
|---|---|---|---|
| Continuous event collection | Monitoring artifacts (Windows.Events.ProcessCreation, DNSQueries) — ETW/WMI-backed, not kernel-mode depth | Cb sensor kernel telemetry to cloud endpoint.event | Partial |
| Prevention (NGAV / ML) | None — not a prevention engine | Cb Defense NGAV: ML pre-execution + behavioural kill | SaaS only |
| Detection content | None vendor-curated; author your own monitoring artifacts | Cb Watchlists (vendor-curated, cloud-evaluated) | SaaS only |
| Ad-hoc query | VQL hunts (forensic plugins: parse_evtx, ntfs_*, winreg_get_value) | Cb Live Query (osquery SQL, point-in-time) | At parity |
| File collection at scale | Hunts, parallel chunked upload; raw NTFS reads locked files | Cb Live Response get — per-host, sequential, audited | Partial |
| Response (remote shell / exec) | Generic.Client.VQL execve() (gated to IR role) | Cb Live Response audited shell put/get/exec | Partial |
| Threat hunting | VQL fleet hunts scoped by client.labels | Cb Process Search + Cb Threat Hunter (managed service) | Partial |
| Memory acquisition / analysis | Windows.Memory.Acquisition (WinPmem) + Generic.Detection.Yara.Process | No memory-acquisition workflow; manual dump via Live Response | OSS only |
| Forensic timeline | Generic.Forensic.Timeline MFT/USN/EVTX merge | Cb Process Search timeline (process-centric only) | OSS only |
| Offline / air-gapped triage | Standalone collector (single binary to .zip) | Sensor degrades to local-only offline | OSS only |
| ATT&CK tagging | None native — manual constant column in artifact YAML | Watchlist attack_tactic/attack_technique fields | SaaS only |
| Audit transparency | Server.Audit.Logs JSONL, you own retention + WORM | Cb console audit log, vendor-controlled retention | Partial |
| Data retention | Your S3/MinIO filestore + budget | Cb Cloud managed retention with vendor SLA | SaaS only |
| Managed hunting / SOC backstop | None | Cb Threat Hunter + Broadcom support SLA | SaaS only |
| Deployment & HA | Single-master by default; federation is operational glue | Cb Cloud multi-tenant, vendor-operated | Partial |
| Cost model | Self-hosted compute + filestore ops | Per-endpoint per-year licensing | Partial |
What we're honest about
The caveats most vendors leave out.
Velociraptor is not a prevention engine
There is no ML pre-execution scoring, no behavioural block-on-execution, no kernel-mode prevention. If anyone reads this migration as replacing Carbon Black, prevention disappears. We position Velociraptor as an add-on, not a replacement, in every communication — the Cb sensor stays installed and in active prevention mode at the end of Phase 5.
Cb Watchlist content is not portable
Vendor-curated detection content — the Cb Watchlist feed and advanced behavioural signatures — cannot be exported as VQL. Roughly 70% can be re-authored manually; the remaining 30% is genuinely vendor-proprietary. So Cb stays the detection source-of-record in the end state, and we never promise Watchlist parity.
You own retention and the SOC backstop
There is no vendor-managed retention and no 24/7 human hunt service on the Velociraptor side. You build retention yourself — monitoring artifacts to SIEM to cold storage (S3 IA / Glacier) — and source Cb Threat Hunter's equivalent from a third-party MDR layered on Velociraptor, as separate procurement. Be explicit about the storage budget before you commit.
Chain-of-custody is your responsibility
Velociraptor does not transparently encrypt the filestore at the application layer, and without S3 Object Lock plus KMS its evidence is not court-defensible. We wire WORM storage into the Phase 1 server build, not later, and the client is single-master by default — so frontend, GUI and filestore are separated, the DB is managed, and a documented RTO and DR rebuild are tested end-to-end.
Why this beats a flag day
Reversible at every layer.
Every per-phase change rolls back in under 15 minutes — revert the IR runbook to Cb Live Response, stop hunts in under a minute, or disable monitoring artifacts so clients quiesce within the next poll cycle. Before any continuous-monitoring set goes fleet-wide, it soaks at least 30 days, fires at parity-or-better against Atomic Red Team techniques, and shows no client perf regression beyond 5%. The Cb sensor is never removed — so prevention coverage never has a cutover to bet on.
See which IR and hunt workflows move to Velociraptor — and what Cb keeps.
A call with a senior DFIR engineer. We map your Cb sensor estate and kernel diversity, baseline your IR cycle time, plan offline-collector packaging where you need it, and tell you exactly where Carbon Black stays — before you commit to anything.
Map my migration →