Velociraptor: Bygg Endpoint-forensik i 13 Steg [2026]

I augusti 2026 släppte utvecklarna bakom Velociraptor version 0.77.2, en säkerhetsuppdatering som täpper till ett nätverksläckage i tre av verktygets uppladdningsmoduler. Samtidigt patchar releasen en separat behörighetsbrist i notebook-funktionen som publicerades som CVE-2026-64954 bara två dagar senare. För svenska säkerhetsteam som redan kämpar med resursbrist och en stadigt växande mängd larm är detta en påminnelse om att öppen källkod för incidenthantering kräver samma disciplin som kommersiella EDR-plattformar. Den här guiden visar hur du installerar, konfigurerar och driftsätter Velociraptor från grunden, skriver dina egna VQL-frågor och bygger en fungerande pipeline för digital forensik och incidenthantering (DFIR) på riktiga endpoints.

Guiden riktar sig till dig som redan arbetar med säkerhetsövervakning, IT-drift eller incidenthantering och vill ha ett verktyg som ger fullständig insyn i vad som faktiskt händer på en endpoint, snarare än att bara lita på färdiga larm från en extern leverantör. Vi går igenom installation på både server och klient, förklarar VQL i praktiken med kod du kan köra direkt, och avslutar med en färdig projektstruktur, vanliga fallgropar och en lista med åtta konkreta felsökningsscenarier. Räkna med cirka 90 minuter för att följa hela guiden från nedladdning till en fungerande hunt mot flera testmaskiner. Fler djupdykningar i verktyg för säkerhetsteam hittar du i vår samlade bevakning av säkerhet.

Vad är Velociraptor och varför är det relevant just nu

Velociraptor är en öppen källkodsplattform för endpoint-övervakning, digital forensik och incidenthantering, byggd av utvecklarna på Velocidex. Enligt den officiella dokumentationen är projektet en “unique, enterprise grade, open-source platform for endpoint monitoring, digital forensic and cyber response” (docs.velocidex.com). Till skillnad från många kommersiella EDR-lösningar kör Velociraptor frågorna direkt på klienten istället för att skicka all rådata till en central server. Projektet beskriver modellen så: man “push[ar] frågorna till endpoints och tolkar artefakter direkt på endpointen själv” i stället för att samla in allt centralt och köra frågor efteråt.

Arkitekturen bygger på en klient-server-modell där utredare styr insamling, hunts och notebooks via en webbaserad GUI eller ett API. Kärnan i systemet är VQL, Velociraptor Query Language, som enligt dokumentationen kan “collect, query, and monitor almost any aspect of an endpoint, groups of endpoints, or an entire network”. Verktyget täcker enligt projektet “the entirety of the attack life cycle, providing responders a powerful capability to address past, present and future events” vilket gör det användbart både för akut respons och löpande hotjakt.

Velociraptor distribueras under AGPL-licensen (GNU Affero General Public License), vilket betyder att om du modifierar koden och erbjuder den som en nätverkstjänst måste du också dela dina ändringar. För de flesta säkerhetsteam som kör verktyget internt utan att sälja det vidare som en tjänst spelar det mindre roll, men det är värt att känna till innan du bygger en kommersiell produkt ovanpå plattformen. Binärer finns för Windows, Linux och macOS, vilket täcker de flesta blandade företagsmiljöer.

Ett viktigt designval skiljer Velociraptor från många traditionella loggverktyg: plattformen samlar inte ständigt in allt från alla maskiner till en central databas. Istället definierar utredaren exakt vad som ska hämtas, kör frågan mot ett urval av endpoints, och tar bara emot de rader som matchar. Det håller ner både nätverkstrafiken och lagringskraven jämfört med lösningar som strömmar rå telemetri kontinuerligt. Samma modell gör verktyget lämpligt både för akut respons, där du behöver ett snabbt svar från hundratals maskiner samtidigt, och för planerad hotjakt, där du regelbundet kör om samma fråga för att upptäcka nya avvikelser över tid.

Förutsättningar: vad du behöver innan du börjar

Du behöver inte en stor labbmiljö för att komma igång, men några saker måste finnas på plats innan du kör de första kommandona. Nedan är kraven vi använder i den här guiden.

Komponent	Krav i denna guide	Anmärkning
Velociraptor-version	0.77.2 (senaste stabila, augusti 2026)	Innehåller fix för CVE-2026-18348
Serveroperativsystem	Linux (Ubuntu 22.04/24.04 eller liknande)	Fungerar även på Windows Server
Klientoperativsystem	Windows 10/11, macOS, Linux	Färdigbyggda binärer för alla tre
Minne på servern	Minst 4 GB RAM för labb, 16 GB+ för produktion	Skalar med antal endpoints och hunts
Diskutrymme	Minst 20 GB för labb	Bevisinsamling kräver betydligt mer i produktion
Nätverksåtkomst	Öppen port (standard 8000 för klienter, 8889 för GUI)	Justera brandväggsregler innan driftsättning
Behörighet	Root/administratörsrättigheter på servern	Krävs för konfiguration och tjänstinstallation
Kunskap	Grundläggande YAML och kommandoradsvana	VQL är enklare än SQL men kräver övning

Du behöver också ett testmål, till exempel en virtuell maskin med Windows eller Linux som du får distribuera klienter till. Kör aldrig de här stegen mot produktionsservrar innan du har testat dem i en isolerad miljö. Om du saknar en labbmiljö räcker det gott med en enda VM för att följa hela guiden.

Tänk också igenom vem i organisationen som ska ha åtkomst redan innan installationen. Velociraptor skiljer mellan administratörer, som kan skapa nya artefakter och hantera användare, och analytiker, som i normalfallet bara kör befintliga hunts och läser resultat. Om ni redan har en etablerad rollstruktur för incidenthantering, till exempel via en plattform som TheHive, är det klokt att spegla samma uppdelning i Velociraptor från start istället för att ge alla fulla rättigheter under labbfasen och sedan behöva strama åt senare.

Steg 1: Ladda ner och verifiera Velociraptor 0.77.2

Börja med att hämta den senaste binären från det officiella GitHub-repositoriet. Ladda alltid ner från releases-sidan snarare än tredjepartsspeglingar, eftersom flera falska paket har cirkulerat under åren.

# Ladda ner Linux-binären (byt ut versionsnumret om en nyare release finns)
wget https://github.com/velocidex/velociraptor/releases/download/v0.77.2/velociraptor-v0.77.2-linux-amd64

# Gör filen körbar
chmod +x velociraptor-v0.77.2-linux-amd64
mv velociraptor-v0.77.2-linux-amd64 /usr/local/bin/velociraptor

# Bekräfta versionen
velociraptor version

Kör alltid velociraptor version direkt efter installationen. Om utdatan inte visar 0.77.2 eller senare har du sannolikt laddat ner fel binär eller en cachead äldre version. Windows-användare hämtar motsvarande .exe-fil från samma sida, och macOS-binären finns som universal build för både Intel och Apple Silicon.

Samma binär används för både server och klient, bara med olika kommandoradsflaggor och konfigurationsfiler. Det förenklar underhållet betydligt jämfört med verktyg som kräver separata installationspaket för varje roll. Spara gärna binären i en versionerad katalog, till exempel /opt/velociraptor/0.77.2/, så att du kan rulla tillbaka snabbt om en framtida uppgradering skulle orsaka problem i er miljö.

Steg 2: Generera server- och klientkonfiguration

Velociraptor styrs helt av konfigurationsfiler i YAML-format. Kommandot config generate skapar en fullständig serverkonfiguration med självsignerade certifikat, vilket räcker för de flesta interna driftsättningar.

# Generera serverkonfiguration interaktivt
velociraptor config generate -i

# Detta skapar två filer:
# server.config.yaml  (används av servern)
# client.config.yaml  (distribueras till endpoints)

# Kontrollera att filerna skapades korrekt
ls -la *.config.yaml

Under den interaktiva processen väljer du organisationsnamn, vilken port GUI:t ska köra på och om du vill använda Let’s Encrypt för publika certifikat. För ett internt labb räcker de självsignerade certifikaten, men i produktion bör du peka mot en riktig certifikatkedja så att klienterna inte behöver ignorera TLS-varningar. Spara server.config.yaml på ett ställe med begränsad åtkomst, eftersom filen innehåller privata nycklar som ger full kontroll över hela installationen.

Steg 3: Testa lokalt med velociraptor gui

Innan du rullar ut något mot riktiga maskiner är det värt att köra en helt lokal demo. Kommandot velociraptor gui startar frontend, server och en klient på samma maskin, vilket gör det möjligt att testa insamlingar mot dig själv.

# Starta en helt lokal testmiljö (server + GUI + lokal klient)
velociraptor gui

# Öppna sedan i webbläsaren
# https://localhost:8889

Standardinloggningen skapas automatiskt vid första körningen och visas i terminalen. Använd den här lokala miljön för att bekanta dig med GUI:t, testa artefakter och förstå hur notebooks fungerar innan du distribuerar till fler maskiner. Det här steget är också bra att återkomma till varje gång du vill testa en ny VQL-fråga utan att röra produktionsmiljön.

Steg 4: Distribuera servern i produktion med Docker

När du är redo att gå bortom labbet stödjer projektet containerbaserad driftsättning. Det gör uppgraderingar enklare och isolerar servern från övriga tjänster på maskinen.

# Kör Velociraptor-servern i en container
docker run -d \
  --name velociraptor-server \
  -p 8000:8000 \
  -p 8889:8889 \
  -v /opt/velociraptor/config:/config \
  -v /opt/velociraptor/data:/data \
  velocidex/velociraptor \
  --config /config/server.config.yaml frontend -v

Montera alltid konfigurations- och datakatalogerna som volymer så att du inte förlorar insamlade bevis eller certifikat om containern startas om. I en riktig produktionsmiljö bör du lägga en omvänd proxy framför port 8889 och terminera TLS där, samt begränsa vilka IP-adresser som får nå administrationsgränssnittet.

Fundera också på hur ni ska säkerhetskopiera datakatalogen. Den innehåller inte bara konfiguration utan även alla insamlade bevis, hunt-resultat och notebooks, vilket i praktiken gör den till en del av er forensiska bevisked. Ett enkelt schemalagt jobb som kopierar volymen till en separat lagringsyta räcker långt, men se till att backupen själv skyddas med samma åtkomstbegränsningar som originaldatan, eftersom den innehåller lika känslig information.

Steg 5: Distribuera klienter till Windows, Linux och macOS

Klienten är den agent som körs på varje endpoint och kontinuerligt lyssnar på instruktioner från servern. Du bygger ett anpassat klientpaket med den client.config.yaml-fil du genererade i steg 2.

# Bygg en Windows-klient (körs på en Linux-byggserver eller lokalt på Windows)
velociraptor --config client.config.yaml config repack \
  velociraptor-v0.77.2-windows-amd64.exe \
  velociraptor_client_windows.exe

# Installera som tjänst på en Windows-endpoint (körs på klienten)
velociraptor_client_windows.exe service install

# På Linux/macOS installerar du binären och kör som systemd-tjänst
sudo velociraptor --config client.config.yaml service install

För storskalig utrullning fungerar klienten precis som andra agentbaserade verktyg. Paketera den med ditt befintliga MDM- eller GPO-system för Windows, eller använd Ansible eller Puppet för Linux-flottor. Klienten ringer hem till servern på den adress som är inbäddad i konfigurationen, så se till att brandväggsregler tillåter utgående trafik på rätt port innan du rullar ut till hela flottan.

Rulla alltid ut till en liten pilotgrupp innan du täcker hela organisationen. En handfull maskiner från olika avdelningar och med olika hårdvarukonfigurationer ger dig en realistisk bild av hur agenten beter sig i er specifika miljö, inklusive eventuella konflikter med befintlig antivirus- eller EDR-programvara som redan är installerad. Vissa säkerhetsprodukter flaggar initialt Velociraptor-klienten som misstänkt beteende eftersom den har liknande systemåtkomst som skadlig kod, så förbered undantagsregler i er befintliga skyddsprogramvara innan den fullskaliga utrullningen påbörjas.

Steg 6: Logga in i webbgränssnittet och utforska GUI:t

Logga in på https://din-server:8889 med det administratörskonto du skapade. Gränssnittet är uppdelat i några huvuddelar: en lista över anslutna klienter, ett hunt-manager-läge för insamlingar över flera maskiner, notebooks för analys och ett artefaktbibliotek med hundratals fördefinierade VQL-frågor för allt från processlistor till webbläsarhistorik och registeranalys.

Kontrollera under “Server Events” att klienterna du distribuerade i steg 5 faktiskt visas som online. Om en klient inte dyker upp inom några minuter, gå direkt till felsökningsavsnittet längre ner i den här guiden innan du fortsätter, eftersom resten av arbetsflödet bygger på att endpoints faktiskt hör av sig.

Ta dig tid att klicka igenom artefaktbiblioteket innan du börjar skriva egna frågor. Projektet levererar redan hundratals färdiga artefakter organiserade efter operativsystem och kategori, och en stor del av det ni behöver för en första utredning, som insamling av körande processer, nätverksanslutningar, installerade program och webbläsarhistorik, finns oftast redan där. Att återanvända en befintlig, testad artefakt är nästan alltid ett bättre startläge än att skriva om samma logik från noll.

Steg 7: Grunderna i VQL, frågespråket som driver Velociraptor

VQL, Velociraptor Query Language, är hjärtat i hela plattformen. Det liknar SQL men är byggt specifikt för att fråga ut operativsystemtillstånd, filer, register och processer i realtid. En enkel VQL-fråga för att lista aktiva processer ser ut så här:

SELECT Name, Pid, Ppid, Exe, CommandLine
FROM pslist()
WHERE Name =~ "powershell|cmd|wscript"
ORDER BY Pid

Frågan filtrerar fram misstänkta interpretatorer bland alla körande processer, vilket är ett vanligt första steg vid en incidentutredning. VQL stödjer även plugins för filsystemsökning, registerläsning, nätverksanslutningar och parsning av loggformat som EVTX och Windows-registerfiler. Eftersom frågorna körs lokalt på klienten skickas bara resultatet, inte all rådata, tillbaka till servern, vilket sparar både bandbredd och lagringsutrymme.

VQL skiljer sig från vanlig SQL på ett par praktiska sätt som är värda att känna till innan du börjar skriva egna frågor. Funktioner som pslist() och glob() kallas plugins, och de agerar som datakällor snarare än tabeller i en traditionell databas. Du kan även kedja plugins med underfrågor, till exempel genom att först lista processer och sedan slå upp nätverksanslutningarna för varje matchande process i samma fråga. Den här kompositionen är det som gör VQL kraftfullt för forensik: du bygger stegvis mer specifika frågor istället för att förlita dig på en enda fördefinierad rapport.

Steg 8: Skriv din första VQL-artefakt

En artefakt är en återanvändbar YAML-fil som paketerar en eller flera VQL-frågor tillsammans med metadata, parametrar och dokumentation. Så här ser en enkel egen artefakt ut som letar efter körbara filer i temporära mappar, ett klassiskt tecken på skadlig kod som försöker gömma sig.

name: Custom.System.SuspiciousTemp
description: |
  Letar efter körbara filer (.exe, .dll, .ps1) i temporära
  kataloger på Windows-endpoints, ett vanligt gömställe för
  skadlig kod under initial åtkomst.
parameters:
  - name: TempGlob
    default: C:/Users/*/AppData/Local/Temp/**

sources:
  - query: |
      SELECT FullPath, Size, Mtime, Ctime
      FROM glob(globs=TempGlob)
      WHERE FullPath =~ "\\.(exe|dll|ps1)$"
      ORDER BY Mtime DESC

Ladda upp artefakten via “Artifacts” i GUI:t, klicka på “New Artifact” och klistra in YAML-koden. Efter det kan du köra den precis som de fördefinierade artefakterna, både mot en enskild endpoint och som en hunt över hela flottan. Bygg gärna vidare med fler parametrar så att samma artefakt kan återanvändas för olika sökvägar och filtyper utan att du behöver skriva om VQL-koden varje gång.

Steg 9: Kör en hunt över flera endpoints

En hunt är en insamling som skickas ut till flera eller alla anslutna klienter samtidigt, istället för att köras mot en enskild maskin. Det är det här som gör Velociraptor användbart för verklig incidenthantering, där du snabbt behöver veta om en indikator på intrång (IOC) förekommer på fler än en maskin i nätverket.

Gå till “Hunt Manager” i GUI:t, välj din nya artefakt (eller en fördefinierad, till exempel Windows.System.Pslist), sätt ett urval av klienter baserat på taggar eller operativsystem, och starta jakten. Velociraptor köar frågan mot varje matchande endpoint och samlar in resultaten allteftersom klienterna checkar in. Ett typiskt utdata från en hunt mot 40 Windows-maskiner kan se ut ungefär så här i notebook-vyn:

ClientId	Hostname	FullPath	Mtime
C.a1b2c3d4	WKST-0042	C:/Users/anna/AppData/Local/Temp/update.exe	2026-09-18 14:22:07
C.e5f6g7h8	WKST-0117	C:/Users/erik/AppData/Local/Temp/setup.ps1	2026-09-19 09:03:44
C.i9j0k1l2	SRV-FILE02	C:/Users/svc_backup/AppData/Local/Temp/tmp2a.dll	2026-09-20 02:15:11

Resultaten kan sorteras, filtreras och exporteras direkt i gränssnittet, vilket gör det enkelt att gå från en bred hunt till en handfull maskiner som kräver djupare granskning.

Ett bra arbetssätt är att alltid börja en hunt begränsad till en liten testgrupp, till exempel fem till tio maskiner, innan du skickar samma fråga till hela flottan. Det ger dig en chans att upptäcka felformulerade VQL-frågor eller oväntat höga svarstider innan de påverkar produktionen i stor skala. När testomgången ser rimlig ut kan du utöka urvalet till alla klienter som matchar rätt operativsystem eller tagg, och låta Velociraptor köa resten automatiskt allteftersom maskinerna checkar in.

Steg 10: Samla in och exportera bevis

När en hunt eller enskild insamling identifierat intressanta filer kan du be Velociraptor hämta hem själva filerna för vidare analys, inte bara metadata. Detta görs via upload()-funktionen i VQL, som stödjer flera mål inklusive lokal disk, SFTP, SMB och molnlagring som Azure. Kom ihåg att just de här uppladdningsmodulerna, upload_azure, upload_sftp och upload_smb, var källan till nätverksläckaget i CVE-2026-18348, så uppdatera till 0.77.2 innan du använder dem mot externa mål.

Exportera resultat från en notebook som CSV eller JSON för vidare bearbetning i ett SIEM eller en ärendehanteringsplattform. Velociraptor har inga inbyggda kopplingar till specifika SIEM-produkter, utan integration sker via API:et, schemalagda exporter eller genom att skicka hunt-resultat vidare till ett mellanled som Wazuh eller TheHive. Om du redan använder TheHive för ärendehantering kan du bygga en enkel export-pipeline som skapar observabler direkt från Velociraptor-resultat.

Steg 11: Bygg kontinuerlig övervakning med monitoring-artefakter

Utöver enstaka insamlingar och hunts stödjer Velociraptor kontinuerlig övervakning, där en artefakt körs löpande på klienten och skickar händelser till servern i realtid. Det används till exempel för att bevaka nya processer, nätverksanslutningar eller filändringar utan att behöva starta en ny hunt varje gång.

name: Custom.System.MonitorNewProcess
type: CLIENT_EVENT
sources:
  - query: |
      SELECT Name, Pid, CommandLine, Timestamp
      FROM watch_pslist()
      WHERE Name =~ "psexec|mimikatz|certutil"

Lägg till artefakten under “Server Monitoring” eller “Client Monitoring” beroende på om du vill samla in på serversidan eller direkt på varje endpoint. Händelser strömmas löpande till servern och kan kopplas till larm i din befintliga övervakningsstack, ungefär på samma sätt som du redan gör med regelbaserad detektion i Wazuh eller nätverkssensorer.

Var återhållsam med hur många monitoring-artefakter som körs samtidigt på varje klient. Varje aktiv övervakningsfråga tar upp en liten mängd processorkraft och minne på endpointen, och kör du för många parallella event-frågor på en gång, särskilt på äldre bärbara datorer, riskerar du att märkbart påverka prestandan för användaren. Börja med en eller två kritiska indikatorer och utöka gradvis, snarare än att aktivera hela biblioteket av tillgängliga monitoring-artefakter direkt.

Steg 12: Härda behörigheter och rollbaserad åtkomst

Ett verktyg som kan hämta filer och köra kod på varenda endpoint i organisationen är i sig självt en attraktiv måltavla. Velociraptor har inbyggd rollbaserad åtkomstkontroll som styr vem som får skapa hunts, komma åt notebooks eller ladda upp anpassade artefakter. Begränsa administratörsrollen till ett fåtal konton, ge de flesta analytiker rollen “Analyst” och inaktivera möjligheten att köra godtyckliga VQL-frågor för konton som bara ska granska färdiga rapporter.

Nätverksåtkomsten till GUI:t bör begränsas till administrativa nät eller ett VPN, inte exponeras direkt mot internet. Det här är precis den typen av begränsning som rekommenderades som åtgärd mot CVE-2026-64954, där notebook-behörigheter kunde missbrukas för att eskalera rättigheter. Granska regelbundet vilka konton som har analytikerroller och ta bort åtkomst för de som inte längre behöver den, särskilt efter personalförändringar.

Överväg också att koppla inloggningen till er befintliga identitetsleverantör via SSO istället för att hantera lokala Velociraptor-konton separat. Det gör det enklare att omedelbart återkalla åtkomst när en anställd slutar, eftersom kontot stängs av centralt snarare än att behöva städas bort manuellt i varje enskilt verktyg ni driftsätter. Aktivera dessutom loggning av vem som kör vilka hunts och notebooks, så att ni själva kan granska hur plattformen används över tid, inte bara vad den hittar hos era endpoints.

Steg 13: Patcha kända sårbarheter i Velociraptor

Precis som alla verktyg som körs med hög behörighet på tusentals endpoints har Velociraptor haft sina egna säkerhetsbrister. Att hålla koll på dessa är en del av att driva plattformen ansvarsfullt, inte en engångsinsats vid installationen.

CVE	Typ	Publicerad	Fix
CVE-2026-18348	Nätverks-ACL-kringgående via upload_azure/upload_sftp/upload_smb	Augusti 2026	Uppgradera till 0.77.2
CVE-2026-64954	Behörighetseskalering via notebook-permissions och mallhantering	12 augusti 2026	Kommit d7de958, begränsa notebook-åtkomst
CVE-2025-14728	Directory traversal	2025	Uppgradera till fixad release
CVE-2025-6264	Behörighetseskalering via klientartefakter	20 juni 2025	Uppgradera till 0.74.3 eller senare

Enligt projektets säkerhetsrådgivningar rekommenderas alla användare att uppgradera till 0.77.2 eller senare, oavsett vilken av de äldre sårbarheterna som är relevant för din installation. Prenumerera på GitHub-releasesidan eller RSS-flödet för säkerhetsrådgivningar så att du får en notis nästa gång en ny CVE dyker upp, snarare än att upptäcka det via en extern rapport månader senare.

Komplett exempelprojekt: en fungerande IR-pipeline

Sätter du ihop stegen ovan får du en fungerande grundstruktur för incidenthantering. Servern körs i en container med volymer för konfiguration och data, klienter är utrullade till Windows-arbetsstationer och Linux-servrar via befintlig systemhantering, och tre anpassade artefakter är på plats: en för att leta misstänkta temp-filer, en för kontinuerlig processövervakning och en tredje som samlar in och exporterar bevisfiler till er ärendehanteringsplattform.

Server: Docker-container med 0.77.2, TLS termineras av en omvänd proxy, GUI nås endast via VPN.
Klienter: distribuerade till samtliga Windows- och Linux-endpoints via GPO respektive Ansible.
Artefakter: en sökartefakt, en övervakningsartefakt och en exportartefakt anpassade efter er miljö.
Behörigheter: administratörsrollen begränsad till två konton, övriga analytiker på rollen Analyst.
Integration: hunt-resultat exporteras som JSON till TheHive för ärendespårning och korrelation mot MISP-indikatorer.
Patchrutin: uppgradering till senaste stabila version schemalagd varje kvartal, med akut patchning vid kritiska CVE:er.

Den här grundstrukturen skalar från en handfull maskiner i ett litet labb till tusentals endpoints i en större organisation, förutsatt att du dimensionerar servern och lagringen därefter. Nästa naturliga steg är att koppla ihop artefakterna med hotintelligens från en plattform som MISP, så att nya indikatorer automatiskt triggar en hunt över hela flottan.

Testa hela kedjan från start till slut innan ni litar på den i en riktig incident. Skapa en känd testfil i en temp-katalog på en testmaskin, kör er sökartefakt och bekräfta att filen dyker upp i hunt-resultatet, exporteras korrekt till JSON och når fram till ärendehanteringsplattformen. Den övningen tar en bråkdel av den tid det skulle ta att upptäcka ett brustet led mitt i en verklig utredning, när varje timme faktiskt räknas och ett tystnat larm kan innebära att en angripare hinner sprida sig vidare i nätverket innan ni märker något.

Velociraptor mot andra DFIR- och EDR-verktyg

Det finns inga aktuella, oberoende prestandasiffror som direkt jämför Velociraptor med andra plattformar, så jämförelsen nedan bygger på funktionalitet snarare än hastighetsmätningar. Välj verktyg utifrån vad ditt team faktiskt behöver, inte utifrån ett enskilt marknadsargument.

Verktyg	Typ	Licens	Styrka
Velociraptor	DFIR / endpoint-övervakning	AGPL (öppen källkod)	Flexibel VQL, djup forensik, hunts över hela flottan
osquery	Endpoint-frågemotor	Öppen källkod	Enkel SQL-liknande frågemodell, brett ekosystem
GRR Rapid Response	DFIR-ramverk	Öppen källkod (Apache 2.0)	Utvecklat av Google, stark Python-integration
Wazuh	SIEM/XDR	Öppen källkod	Bred loggkorrelation, inbyggd regelmotor
Kommersiell EDR (t.ex. CrowdStrike, Defender for Endpoint)	EDR/XDR	Proprietär, licenskostnad	Färdig support, molnbaserad analys, leverantörsdrivna detektionsregler

Velociraptor konkurrerar sällan direkt med en fullskalig kommersiell EDR eftersom det saknar inbyggd hotintelligens och molnbaserad maskininlärning. Där det istället utmärker sig är i djupet på den forensiska insamlingen och friheten att skriva exakt den fråga du behöver, vilket gör det till ett naturligt komplement snarare än en ersättning för en befintlig SIEM- eller EDR-stack.

osquery och GRR Rapid Response ligger konceptuellt närmast Velociraptor, eftersom alla tre är öppen källkod och bygger på att fråga ut endpoints direkt snarare än att förlita sig på färdiga signaturer. Skillnaden ligger ofta i mognadsgrad och community: GRR har funnits längre och är utvecklat av Google, medan Velociraptor har byggt ett större och mer aktivt bibliotek av färdiga artefakter för Windows-forensik specifikt. Många säkerhetsteam som redan kör Wazuh för loggkorrelation lägger till Velociraptor som ett kompletterande verktyg för djupare endpoint-utredningar, snarare än att välja det ena eller det andra.

Resursplanering: vad en Velociraptor-driftsättning kräver av teamet

Själva mjukvaran är gratis, men det betyder inte att en driftsättning är kostnadsfri i praktiken. Den största kostnaden ligger i personaltid, inte licenser. Någon i teamet behöver äga serverdriften, hålla koll på säkerhetsrådgivningar och underhålla de anpassade artefakterna över tid, ungefär på samma sätt som ett internt SIEM eller en egen loggplattform kräver löpande ägarskap. Räkna med att avsätta åtminstone en del av en tjänst till detta, snarare än att se det som en engångsinsats vid installationen.

Infrastrukturkostnaden beror i hög grad på hur många endpoints ni täcker och hur ofta ni kör breda hunts. En server dimensionerad för ett par hundra klienter i ett labb eller en mindre organisation kräver betydligt mindre kapacitet än en installation som ska täcka tusentals arbetsstationer i en global koncern. Lagringen växer i takt med hur mycket rådata, som filer och minnesdumpar, ni faktiskt hämtar hem via upload()-funktionen, snarare än i takt med antal klienter i sig. Planera lagring efter förväntad utredningsvolym, inte bara efter antal endpoints.

Jämfört med en kommersiell EDR-lösning, där licenskostnaden vanligtvis skalar per skyddad enhet och år, flyttar Velociraptor kostnaden från en återkommande licensavgift till internt arbete med drift, artefaktutveckling och patchning. För organisationer som redan har ett kompetent säkerhetsteam och vill ha full kontroll över exakt vilka frågor som körs kan det vara en fördel. För mindre team utan dedikerad säkerhetspersonal kan samma modell istället bli en black om foten, eftersom ingen extern leverantör tar ansvar för drift och support på samma sätt som vid en kommersiell prenumeration.

Vanliga fallgropar

De flesta problem med Velociraptor uppstår inte i själva VQL-koden utan i hur plattformen driftsätts och behörighetssätts. Här är de misstag vi ser oftast.

Exponerad GUI mot internet. Att publicera administrationsgränssnittet öppet gör hela plattformen till en attraktiv måltavla. Begränsa alltid åtkomsten till VPN eller administrativa nät.
Gamla klientversioner mot ny server. Kör inte en server på 0.77.2 med klienter kvar på 0.74.x under lång tid, eftersom det ökar risken att missa fixar som kräver matchande versioner på båda sidor.
Alla analytiker får administratörsroll. Det är enklare i ett labb men farligt i produktion. Separera roller redan från start istället för att städa upp behörigheter efter en incident.
Ingen plan för lagringstillväxt. Bevisinsamling från hundratals endpoints kan snabbt fylla en disk. Övervaka lagringsutrymme och sätt policyer för hur länge insamlade artefakter sparas.
Anpassade artefakter utan versionshantering. Om du skriver egna VQL-artefakter men aldrig sparar dem i ett gitrepo tappar du historiken när någon råkar redigera fel version i GUI:t.
Att lita blint på självsignerade certifikat i produktion. Fungerar fint i labbet men skapar onödig risk och varningsmeddelanden i en skarp driftsättning med många klienter.

Felsökning: vanliga problem och lösningar

Nedan är de problem som dyker upp oftast när team sätter upp Velociraptor för första gången, tillsammans med hur du löser dem.

Klienten visas aldrig som online. Kontrollera att brandväggen tillåter utgående trafik från klienten till serverns port (standard 8000) och att klientkonfigurationen pekar på rätt hostnamn eller IP.
Certifikatfel vid anslutning. Om du bytt serverns adress efter att konfigurationen genererades måste du regenerera både server- och klientkonfigurationen, eftersom certifikaten är knutna till den ursprungliga adressen.
GUI svarar inte efter uppstart. Vänta minst 30 sekunder efter att containern eller tjänsten startat innan du testar, eftersom Velociraptor bygger index vid uppstart på större installationer.
Hunt fastnar på “pending” för vissa klienter. Klienten kan vara offline, avstängd eller sakna nätverksåtkomst. Kontrollera senaste incheckningstid i klientlistan.
VQL-fråga returnerar tomt resultat trots att data borde finnas. Testa frågan mot en enskild känd klient innan du kör den som en hunt, och dubbelkolla reguljära uttryck i WHERE-satsen, som är skiftlägeskänsliga i vissa plugins.
Uppladdning av bevisfiler misslyckas mot molnmål. Om du kör en version äldre än 0.77.2 kan detta bero på det ACL-kringgående som beskrivs i CVE-2026-18348. Uppgradera innan du felsöker vidare.
Hög CPU-belastning på servern vid stora hunts. Begränsa antal parallella klienter per hunt eller dela upp insamlingen i mindre batcher, särskilt vid insamling av stora filer.
Administratörskontot är låst eller lösenordet borttappat. Återställ via kommandoraden med velociraptor --config server.config.yaml user add adminuser --role administrator direkt på servern.

Avancerade tips för skarpt bruk

När grundinstallationen fungerar finns det flera sätt att få mer värde ut av plattformen i en produktionsmiljö. Automatisera hunts via API:et istället för att alltid klicka i GUI:t, till exempel genom ett schemalagt skript som startar en insamling varje natt och skickar resultatet till en delad lagringsyta för granskning nästa morgon.

Bygg en artefaktbank i ett internt gitrepo med granskning via pull request innan nya VQL-frågor rullas ut brett, precis som du skulle hantera annan infrastrukturkod. Kombinera Velociraptor med en extern SOAR-plattform genom att låta webhooks trigga hunts automatiskt när en ny indikator dyker upp i ert hotintelligens-flöde, snarare än att en analytiker manuellt startar varje insamling. Testa slutligen regelbundet era egna detektionsartefakter mot en känd, kontrollerad simulering av skadligt beteende, så att ni vet att larmen faktiskt triggar innan en riktig incident inträffar.

Skapa dedikerade taggar för klienterna redan vid utrullning, till exempel efter avdelning, geografisk plats eller kritikalitet. Det gör det mycket snabbare att rikta en hunt mot exakt de maskiner som är relevanta vid en specifik incident istället för att behöva välja bland en lång, otaggad lista med tusentals endpoints. Många team lägger även till en artefakt som körs en gång per dygn och rapporterar grundläggande hälsostatus, som diskutrymme och senaste omstart, vilket ger ett tidigt varningstecken om en klient har slutat fungera korrekt innan den behövs akut i en utredning.

Slutligen, dokumentera varje anpassad artefakt med en tydlig beskrivning av vad den letar efter och varför, direkt i YAML-filens description-fält. Sex månader senare, mitt i en stressad incident klockan tre på natten, är det stor skillnad mellan att öppna en artefakt med en tydlig förklaring och att försöka minnas eller reverse-engineera vad en kollega menade med en kryptisk VQL-fråga utan kommentarer.

Om er organisation redan lyder under NIS2 är det värt att koppla ihop Velociraptor-drivna insamlingar med er formella incidentplan, så att bevisinsamlingen sker enligt samma tidslinje som kraven på rapportering till myndigheter.

Vanliga frågor

Är Velociraptor gratis att använda?

Ja, Velociraptor är öppen källkod under AGPL-licensen och kostar inget att ladda ner eller köra. Tänk på att AGPL kräver att du delar dina ändringar om du erbjuder en modifierad version som en nätverkstjänst till andra.

Behöver jag agenter installerade på alla endpoints?

Ja, Velociraptor bygger på en klient-server-modell där en liten agent måste vara installerad på varje endpoint du vill kunna fråga ut eller övervaka. Utan klienten kan servern inte samla in data från den maskinen.

Kan Velociraptor ersätta en kommersiell EDR-lösning?

Sällan helt och hållet. Velociraptor saknar inbyggd hotintelligens och molnbaserad maskininlärning som många kommersiella EDR-produkter erbjuder. Det fungerar bäst som ett komplement för djup forensik och anpassad hotjakt, ofta parallellt med en befintlig EDR- eller SIEM-plattform.

Vad är skillnaden mellan en artefakt och en hunt?

En artefakt är en återanvändbar definition av vad som ska samlas in, skriven i VQL och YAML. En hunt är själva handlingen att skicka ut en artefakt till en eller flera endpoints och samla in resultatet. Du kan köra samma artefakt både som en enskild insamling och som en bred hunt.

Hur ofta släpps nya versioner av Velociraptor?

Projektet har haft en aktiv releasetakt under 2026, med version 0.77.1 i juni och 0.77.2 i augusti. Följ releasesidan på GitHub för att inte missa säkerhetsuppdateringar mellan de större versionerna.

Är det säkert att köra Velociraptor mot internetexponerade servrar?

Administrationsgränssnittet bör aldrig exponeras direkt mot internet utan VPN eller motsvarande skydd. Flera av de tidigare sårbarheterna, inklusive CVE-2026-64954, handlade om behörighetseskalering via just GUI:t och notebook-funktionen.

Kan jag använda Velociraptor för löpande övervakning, inte bara vid en incident?

Ja, via monitoring-artefakter av typen CLIENT_EVENT eller SERVER_EVENT kan Velociraptor strömma händelser kontinuerligt, till exempel nya processer eller nätverksanslutningar, snarare än att bara köras vid enstaka insamlingstillfällen.

Vilket programmeringsspråk behöver jag känna till för att skriva egna artefakter?

Du behöver grundläggande YAML för själva artefaktstrukturen och VQL för frågelogiken. VQL liknar SQL men med tillägg av plugins för systemdata, så tidigare erfarenhet av SQL eller liknande frågespråk gör inlärningskurvan betydligt kortare.

Velociraptor: Bygg Endpoint-forensik i 13 Steg, 90 Min [2026]