Ett dataintrång upptäcks sällan i samma ögonblick det sker. I snitt tar det veckor innan ett företag ens vet att något hänt, och när larmet väl går är det den tekniska utredningen som avgör om ni kan säga vad som faktiskt inträffade. Den här guiden visar hur du använder Autopsy och The Sleuth Kit, två av de mest spridda open source-verktygen inom digital forensik, för att gå igenom en diskavbild steg för steg: från installation till färdig rapport. Du får kommandon du kan köra direkt, en komplett skriptbaserad triage-pipeline och en lista över de misstag som oftast sänker en utredning i efterhand.
Guiden passar både dig som jobbar på ett internt säkerhetsteam och behöver göra en första bedömning själv, och dig som vill förstå vad en extern incidentresponsleverantör faktiskt gör med er data när de kopplar in sig efter en attack. Allt nedan går att följa på en vanlig arbetsstation, det krävs inget dyrt labb eller särskild hårdvara utöver en skrivblockerare när du ska säkra det ursprungliga beviset.
Varför dataintrångsutredningar kräver rätt verktyg
Kostnaden för att göra fel vid en utredning av dataintrång är hög, och den syns i siffrorna. Enligt IBM:s rapport Cost of a Data Breach 2025 landade den globala snittkostnaden per intrång på 4,44 miljoner dollar. Phishing stod för 16 procent av alla intrång som startpunkt, vilket gör det till den vanligaste ingångsvägen i datasetet, tätt följt av attacker mot leveranskedjan som låg bakom 15 procent av fallen och i snitt kostade 4,91 miljoner dollar att städa upp efter. Värst av allt var intrång kopplade till illvilliga insiders, med en snittkostnad på 4,92 miljoner dollar, den högsta siffran av samtliga kategorier IBM mätte.
Tiden spelar också roll. Intrång med en livscykel längre än 200 dagar kostade i snitt 5,01 miljoner dollar enligt samma rapport, medan organisationer som tog in brottsbekämpande myndigheter i utredningen sparade cirka 1 miljon dollar jämfört med de som inte gjorde det. Det är här en strukturerad forensisk process gör skillnad. Ni behöver kunna visa exakt vilka filer som berördes, när åtkomsten skedde och om data faktiskt lämnade systemet, inte bara gissa utifrån loggfragment. Autopsy byggdes för just det här: att ta en rå diskavbild och göra den sökbar, tidsordnad och begriplig för en människa som ska fatta beslut utifrån den.
I Sverige och övriga Norden skärper NIS2-direktivet kraven på incidentrapportering för leverantörer av samhällsviktiga och viktiga tjänster, och GDPR kräver fortsatt att en personuppgiftsincident anmäls till Integritetsskyddsmyndigheten utan onödigt dröjsmål och normalt inom 72 timmar. Den klockan börjar ticka så fort ni bekräftat intrånget, vilket gör det ännu viktigare att ha en utredningsprocess som går snabbt utan att tumma på bevisvärdet.
Många av de senaste årens större incidenter i Norden har varit en kombination av utpressningsattacker och stöld av data, vilket betyder att den tekniska frågan sällan längre är bara “krypterades filerna”, utan också “lämnade data systemet innan krypteringen slog till”. Det är en helt annan utredningsfråga, och den går inte att besvara genom att bara titta på en lösenanteckning på skrivbordet. Du behöver gå igenom nätverksartefakter, utgående anslutningar och komprimerade arkiv som skapats strax innan incidenten upptäcktes, vilket är precis den typen av spår Autopsys Timeline- och Communications-vyer är byggda för att fånga upp.
Vad är Autopsy och The Sleuth Kit
Autopsy är ett grafiskt gränssnitt byggt ovanpå The Sleuth Kit, ett bibliotek med kommandoradsverktyg för att läsa filsystem direkt från diskavbilder utan att montera dem i ett levande operativsystem. Det är skillnaden som gör forensik möjlig: du rör aldrig originaldatan, du läser en skrivskyddad kopia och varje åtgärd går att upprepa och verifiera. Projektet används av brottsbekämpande myndigheter, militära utredningsenheter och privata incidentresponsteam världen över, och är helt gratis.
Den senaste stabila versionen är Autopsy 4.23.1, släppt i maj 2026. Den bygger vidare på 4.23-serien som introducerade en AI-assistent byggd på Model Context Protocol (MCP) samt integration mot Cyber Triage för snabbare initial bedömning av misstänkta enheter. The Sleuth Kit levereras paketerat med Autopsy-installationen, men om du kör Linux eller macOS kan du installera CLI-verktygen separat. Observera att projektets egna kanaler för tillfället visar olika versionsnummer för Sleuth Kit (4.14.0 på GitHub, 4.15.0 på nyhetssidan), så kontrollera alltid vilken version som faktiskt följer med din Autopsy-installation innan du dokumenterar den i ett ärende.
Verktyget skapades ursprungligen av Brian Carrier och har växt till ett fullskaligt analysverktyg genom ett plugin-baserat system skrivet i Java. Det betyder att du kan lägga till externa moduler för allt från att tolka specifika appdatabaser till att koppla in egna skript, utan att röra kärnkoden. Autopsy konkurrerar i praktiken med dyra kommersiella produkter som EnCase och FTK, men utan licenskostnaden, vilket är en stor anledning till att verktyget blivit standard på många utbildningar och mindre incidentresponsteam som inte har budget för ett helt forensiklabb.
Säkra beviset: imaging och beviskedja innan analysen börjar
Allt arbete i Autopsy förutsätter att du redan har en diskavbild att analysera, och hur den avbilden togs påverkar hela utredningens trovärdighet. Beviskedjan, eller chain of custody, är dokumentationen som visar exakt vem som hanterat beviset, när, och vad de gjorde med det. Brister här kan göra att en annars solid teknisk analys blir värdelös om saken någonsin hamnar i en tvist eller rättsprocess.
I praktiken innebär det att du kopplar in originaldisken via en hårdvarubaserad skrivblockerare, som fysiskt förhindrar att något skrivs till disken under imaging-processen. Därefter skapar du en bitvis kopia, inte en vanlig filkopiering, så att även raderade filer och oallokerat utrymme följer med i avbilden. Verktyget dc3dd, en forensiskt anpassad variant av standardkommandot dd, loggar samtidigt hashsumman medan kopieringen pågår.
# Skapa en forensisk bitvis avbild med integrerad hashloggning
dc3dd if=/dev/sdb hash=sha256 log=imaging.log of=bevisfil.dd
# Exempel på utdata i imaging.log:
# dc3dd 7.2.646 started at 2026-10-05 09:12:03
# input block size = 512, output block size = 512
# sha256 = 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
# 500118192 sectors (+0) in, 500118192 sectors (+0) out
# dc3dd completed at 2026-10-05 10:41:55Dokumentera i samma veva vem som fysiskt hanterade enheten, vilket serienummer disken hade och var den förvarats mellan beslag och imaging. Den här pappersdokumentationen (eller det digitala motsvarande formuläret) är minst lika viktig som själva hashvärdet, eftersom den visar att ingen obehörig haft tillgång till originalbeviset under tiden.
Förutsättningar: detta behöver du innan du börjar
Du behöver inte en avancerad labbmiljö för att följa den här guiden, men ett par saker måste vara på plats innan du öppnar Autopsy för första gången. Tabellen nedan sammanfattar vad som krävs.
| Komponent | Krav | Kommentar |
|---|---|---|
| Autopsy | 4.23.1 eller senare | Windows 64-bit har bäst stöd, Linux-byggen finns via källkod |
| Java-runtime | Medföljer installationen | Ingen separat JDK behövs i 4.23.x-serien |
| RAM | Minst 8 GB, 16 GB rekommenderas | Större avbilder och fler ingest-moduler kräver mer minne |
| Diskutrymme | Minst tre gånger avbildens storlek | Autopsy skapar index och temporära filer under analysen |
| Diskavbild | E01, EWF eller raw/dd | Ta alltid avbilden via en skrivblockerare mot originalmediet |
| Hashverktyg | hashdeep eller md5deep | Används för att verifiera avbildens integritet före och efter analys |
Skaffa en testavbild att öva på innan du rör skarpt material. Autopsy-projektet länkar till flera gratis övningsavbilder via sin dokumentation, och det är ett bättre sätt att lära sig gränssnittet än att experimentera på en avbild som faktiskt ska användas i en utredning.
Steg 1–3: Installera Autopsy och skapa ditt första fall
Första delen av processen handlar om att få verktyget på plats och säkerställa att själva beviset är intakt innan du rör det. Hoppa inte över hashverifieringen, det är den som bevisar att din analys gäller samma data som togs i beslag.
- Steg 1: Ladda ner Autopsy 4.23.1 från det officiella projektet och verifiera installationsfilens checksumma mot den publicerade hashen innan du kör installationsprogrammet.
- Steg 2: Kopiera diskavbilden till en separat analysdisk med gott om utrymme, aldrig till samma volym som operativsystemet kör på.
- Steg 3: Beräkna och spara en SHA-256-hash av avbilden innan du öppnar den i Autopsy, så du kan verifiera integriteten igen efter avslutad analys.
# Verifiera avbildens hash innan analys påbörjas
sha256sum bevisfil.E01 > bevisfil.sha256
# Jämför mot den hash som dokumenterades vid beslag
sha256sum -c bevisfil.sha256
# Förväntat resultat:
# bevisfil.E01: OKNär hashen stämmer öppnar du Autopsy och väljer “New Case”. Ange ett case-namn utan mellanslag eller specialtecken (det undviker sökvägsproblem senare), fyll i utredarens namn och ärendenummer, och peka ut en dedikerad mapp för caset. Autopsy skapar en SQLite-databas och en katalogstruktur som håller all analysdata separat från själva beviset, vilket gör det enkelt att arkivera eller flytta hela ärendet senare.
Så ser gränssnittet ut: viktiga vyer i Autopsy
Innan du går vidare till att mata in data är det värt att orientera dig i gränssnittet, eftersom en stor del av tiden i en riktig utredning går åt till att hoppa mellan ett fåtal centrala vyer snarare än att klicka runt slumpmässigt. Till vänster hittar du trädstrukturen med datakällor, där varje tillagd avbild bryts ner i partitioner, kataloger och filer precis som i en vanlig filutforskare, fast skrivskyddad.
Vyn Keyword Lists håller dina sparade sökprofiler, vilket är användbart om ni återanvänder samma uppsättning indikatorer i flera ärenden, till exempel kända C2-domäner eller interna kodnamn för en pågående kampanj. Vyn Communications samlar e-post, chattmeddelanden och samtalsloggar i ett gemensamt gränssnitt när sådana data finns i avbilden, medan Accounts extraherar inloggningsuppgifter, kreditkortsnummer och andra kontorelaterade artefakter som hittats i filsystemet. Tagged Results fungerar som din arbetsyta: varje gång du hittar något relevant taggar du objektet direkt i vyn, vilket sedan blir grunden för rapporten i steg 13.
Steg 4–6: Lägg till datakällor och förstå bildformat
Med caset skapat är nästa fas att peka Autopsy mot själva beviset och välja vilka analysmoduler som ska köras. Det här är ofta där nybörjare kör fast, eftersom fel val här kostar timmar senare.
- Steg 4: Välj “Add Data Source” och peka ut avbildfilen. Autopsy stödjer E01/EWF (vanligast från kommersiella imaging-verktyg), raw/dd-format och direkta diskar via skrivblockerare.
- Steg 5: Ange rätt tidszon för caset manuellt. Autopsy använder annars värdmaskinens lokala inställning, vilket ger en felaktig tidslinje om beviset kommer från en annan tidszon.
- Steg 6: Välj ingest-moduler. Börja med Hash Lookup, File Type Identification och Timeline, och lägg till Keyword Search samt E-mail Parser i en andra omgång när du vet vad du letar efter.
Att köra alla moduler samtidigt på en stor avbild (över 100 GB) kan ta flera timmar och gör det svårt att se vilken modul som faktiskt hittar något relevant. En stegvis ingest ger dig snabbare feedback och gör det enklare att felsöka om något hänger sig.
Steg 7–9: Tidslinjeanalys och återställning av raderade filer
Det här är kärnan i själva utredningsarbetet. Timeline-vyn i Autopsy slår samman tidsstämplar från filsystemet, loggar och metadata till en enda kronologisk vy, vilket gör det möjligt att se vad som hände före och efter den misstänkta händelsen i en kontext du annars aldrig skulle fånga genom att bläddra fil för fil.
- Steg 7: Öppna Timeline-vyn och filtrera på det tidsintervall där intrånget misstänks ha skett. Zooma in stegvis från vecka till timme för att hitta den exakta händelsekedjan.
- Steg 8: Markera filer med onormala tidsstämplar (till exempel en ändringstid som ligger före skapandetiden) som tecken på manipulation eller tidsstämpelförfalskning.
- Steg 9: Använd “File Carving”-funktionen i Deleted Files-vyn för att återställa raderade filer vars metadata fortfarande finns kvar i filsystemet men vars innehåll bara delvis skrivits över.
Om du hellre vill arbeta via kommandoraden för en snabb kontroll innan du går in i GUI:t kan du använda The Sleuth Kit direkt. Kommandot mmls visar partitionslayouten på avbilden, vilket du behöver för att räkna ut rätt offset till filsystemet.
# Visa partitionstabellen i avbilden
mmls bevisfil.E01
# Exempelutdata:
# Slot Start End Length Description
# 000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
# 001: ----- 0000000000 0000002047 0000002048 Unallocated
# 002: 000:000 0000002048 0020971519 0020969472 NTFS (0x07)Steg 10–12: Nyckelordssökning, hashfiltrering och artefakter
När du vet ungefär vad som hänt och när, är nästa fas att leta efter specifika bevis: inloggningsuppgifter som exfiltrerats, skadlig kod som planterats, eller dokument som öppnats av en angripare. Hashfiltrering mot kända databaser gör det möjligt att snabbt sortera bort kända, ofarliga systemfiler och fokusera på det som faktiskt är unikt för just den här maskinen.
- Steg 10: Importera NIST:s NSRL-hashdatabas (Reference Data Set) under Hash Databases, så markerar Autopsy automatiskt kända, legitima systemfiler som “Known Good” och filtrerar bort dem från vyn.
- Steg 11: Kör en nyckelordssökning mot termer som är specifika för incidenten: användarnamn, domännamn från en misstänkt C2-server, eller filnamn som nämnts i ett internt larm.
- Steg 12: Granska artefakter som webbhistorik, nyligen öppnade dokument och registernycklar (på Windows-avbilder) under modulen Recent Activity för att bygga en bild av användarens eller angriparens beteende.
Vill du extrahera en specifik fil direkt via kommandoraden, till exempel en raderad fil du identifierat via dess inode-nummer i Deleted Files-vyn, använder du icat från The Sleuth Kit.
# Lista filer och kataloger i filsystemet på rätt offset
fls -o 2048 bevisfil.E01
# Exempelutdata:
# r/r 45-128-1: schedule_task.exe
# r/r 46-128-3: users_export.csv
# Extrahera innehållet i en specifik fil via dess inode
icat -o 2048 bevisfil.E01 46 > users_export_recovered.csvSteg 13: Generera och exportera den forensiska rapporten
En utredning som bara finns i ditt huvud är värdelös för ledningen, juristerna eller en eventuell domstol. Autopsy har en inbyggd rapportgenerator som paketerar dina fynd, taggade artefakter och kommentarer till ett format andra kan läsa utan att öppna verktyget själva.
Gå till “Generate Report” och välj HTML-mallen om du vill ha ett läsbart dokument med klickbara länkar till bifogade filer, eller Excel-mallen om mottagaren vill filtrera och sortera fynden själv. Se till att kryssa i alternativet för att inkludera bifogade filer över standardgränsen, annars exkluderas större bevisfiler automatiskt ur den slutgiltiga rapporten. Spara alltid en kopia av rapporten tillsammans med den ursprungliga hash-filen, så hela kedjan från bevis till slutsats går att följa i efterhand.
Kommandoraden: Sleuth Kit-verktyg för snabb triage
Autopsys GUI är bra för djupanalys, men när du behöver ett snabbt svar, till exempel mitt i natten när ett larm kommit in, är kommandoradsverktygen i The Sleuth Kit ofta snabbare. De körs direkt mot avbilden utan att du behöver vänta på att ett helt case ska byggas upp.
# Verifiera filsystemtyp och grundläggande metadata
fsstat -o 2048 bevisfil.E01 | head -20
# Räkna alla raderade men ej överskrivna filer
fls -o 2048 -d -r bevisfil.E01 | wc -l
# Jämför beräknad hash mot NSRL eller en egen baslinje
hashdeep -r -c sha256 /mnt/bevis > baslinje.sha256
hashdeep -r -a -k baslinje.sha256 /mnt/bevisKombinationen av fsstat, fls och hashdeep ger dig en komplett bild av filsystemets tillstånd, antalet misstänkta raderade filer och integriteten på beviset, allt innan du ens behöver öppna det grafiska gränssnittet. Två ytterligare verktyg är värda att känna till: ils listar metadata för alla inoder i filsystemet, inklusive de som pekar på raderade filer utan namn kvar, medan blkcat extraherar rådata direkt från specifika diskblock när du redan vet vilket blocknummer som är intressant, till exempel efter att ha hittat en referens till det i en loggfil. Dessa två kommandon används sällan i en första genomgång, men blir ovärderliga när du behöver gräva djupare i ett enskilt fynd utan att vänta på att hela caset ska indexeras om i Autopsy.
Bygg ett komplett forensiskt triage-projekt
För att knyta ihop hela processen till något du faktiskt kan återanvända, här är ett bash-skript som automatiserar de första stegen i en utredning: hashverifiering, partitionsanalys, filsystemstatus och en lista över raderade filer, allt sparat till en triage-rapport du kan bifoga till caset i Autopsy.
#!/bin/bash
# triage.sh - Snabb forensisk triage innan full Autopsy-analys
# Användning: ./triage.sh bevisfil.E01 utredare_namn
set -euo pipefail
EVIDENCE="$1"
INVESTIGATOR="$2"
OUTDIR="triage_$(basename "$EVIDENCE")_report"
mkdir -p "$OUTDIR"
echo "== Steg 1: Hashverifiering ==" | tee "$OUTDIR/triage.log"
sha256sum "$EVIDENCE" | tee -a "$OUTDIR/triage.log" > "$OUTDIR/evidence.sha256"
echo "== Steg 2: Partitionslayout ==" | tee -a "$OUTDIR/triage.log"
mmls "$EVIDENCE" | tee -a "$OUTDIR/triage.log"
OFFSET=$(mmls "$EVIDENCE" | grep -i ntfs | awk '{print $3}' | head -1)
echo "== Steg 3: Filsystemstatus (offset: $OFFSET) ==" | tee -a "$OUTDIR/triage.log"
fsstat -o "$OFFSET" "$EVIDENCE" | tee -a "$OUTDIR/filesystem_status.txt"
echo "== Steg 4: Raderade filer ==" | tee -a "$OUTDIR/triage.log"
fls -o "$OFFSET" -d -r "$EVIDENCE" | tee -a "$OUTDIR/deleted_files.txt"
DELETED_COUNT=$(wc -l < "$OUTDIR/deleted_files.txt")
echo "Utredare: $INVESTIGATOR" >> "$OUTDIR/triage.log"
echo "Antal raderade filer funna: $DELETED_COUNT" >> "$OUTDIR/triage.log"
echo "Triage klar. Resultat sparade i: $OUTDIR"Kör skriptet så snart ni fått avbilden, bifoga mappen triage_*_report som en extern fil i Autopsy-caset, och använd listan över raderade filer som utgångspunkt när du jobbar vidare i Deleted Files-vyn. Det här sparar ofta 30–45 minuter jämfört med att vänta på att en fullständig ingest ska bli klar innan du ens vet var du ska leta.
Fem vanliga nybörjarmisstag i Autopsy-utredningar
- Att analysera originalbeviset direkt. Så fort du öppnar originaldisken i stället för en skrivskyddad kopia bryter du beviskedjan, och resultatet går inte längre att använda rättsligt. Det spelar ingen roll hur rätt dina slutsatser är om motparten kan visa att originalet riskerat att ändras under analysen.
- Att hoppa över hashverifiering. Utan en hash tagen före analysen kan ingen, inklusive du själv, bevisa att avbilden inte ändrats under arbetets gång. Gör det till en fast rutin snarare än något du kommer ihåg ibland.
- Att låta flera personer jobba i samma case samtidigt. Autopsys SQLite-databas hanterar inte samtidig skrivning bra, vilket leder till korrupta case eller tappade kommentarer. Dela i stället upp arbetet så att en person äger caset och andra bidrar med separata anteckningar som sedan sammanställs.
- Att lita blint på tidsstämplar. Klockdrift, felaktig tidszon och medveten manipulation gör att rådata måste kontrolleras mot minst en oberoende källa innan den blir en slutsats. En brandväggslogg eller en extern autentiseringstjänst är ofta ett bättre facit än filsystemets egna klocka.
- Att inte dokumentera löpande. Fynd som inte skrivs ner i caseloggen när de upptäcks glöms bort eller blir omöjliga att förklara för någon som läser rapporten sex månader senare. Skriv ner varför du drog en slutsats, inte bara vad slutsatsen blev.
- Att köra en fullständig ingest innan du vet vad du letar efter. Det är frestande att aktivera alla moduler direkt, men en bred sökning utan riktning förlänger analysen och begraver de viktiga fynden bland hundratals irrelevanta träffar. Starta smalt, bredda sedan sökningen när du har en hypotes att testa.
Felsökning: 10 vanliga problem och lösningar
De flesta problem i Autopsy går att lösa snabbt om du vet vad du letar efter. Tabellen nedan samlar de fel som dyker upp oftast i praktiken, baserat på vanliga trådar i projektets egna supportkanaler och erfarenheter från löpande utredningsarbete. Innan du felsöker något av det här, kontrollera alltid att du kör den senaste patchversionen av 4.23.x, eftersom flera av de vanligaste buggarna redan är åtgärdade i senare delversioner.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| Autopsy kraschar vid uppstart | Föråldrad grafikdrivrutin eller saknade Visual C++ Redistributables | Uppdatera GPU-drivrutin och installera senaste Redistributable-paketet |
| Ingest fastnar på “Analyzing…” | Alla moduler körs samtidigt på en stor avbild | Kör moduler i omgångar, börja med Hash Lookup och Timeline |
| E01-filen går inte att lägga till | Saknade segmentfiler eller skadad avbild | Kontrollera att alla .E01/.E02-segment finns, verifiera hash mot originalet |
| Tidslinjen visar fel tid | Fallet använder systemets lokala tidszon som standard | Ange korrekt tidszon manuellt under fallinställningarna före ingest |
| Nyckelordssökning hittar inget | Indexeringsmodulen avbröts eller kördes aldrig | Kontrollera ingest-loggen och kör om Keyword Search separat |
| icat returnerar en tom fil | Fel partitionsoffset angivet | Kör mmls igen och bekräfta rätt offset innan du upprepar kommandot |
| Rapporten saknar bifogade filer | Standardmallen exkluderar stora bilagor | Växla till HTML-rapport med fullständiga bilagor aktiverat |
| Caset låser sig med “already open” | Lock-filen rensades inte efter en krasch | Stäng alla Autopsy-processer och radera lock-filen manuellt i casekatalogen |
| Minnet tar slut på stora avbilder | Java-heapen är satt för lågt som standard | Öka heap-storleken i konfigurationen eller kör på en maskin med mer RAM |
| Hashvärden matchar inte NSRL | Föråldrad NSRL-databas importerad | Ladda ner senaste NSRL RDS från NIST och importera om under Hash Databases |
Avancerade tips för erfarna utredare
När grunderna sitter finns det flera sätt att korta ner tiden från avbild till slutsats. Autopsy 4.23.x introducerade en AI-assistent byggd på Model Context Protocol, där du kan ställa frågor om fyndet direkt i gränssnittet och få förslag på vilka artefakter som är värda att granska vidare. Behandla förslagen som en utgångspunkt, inte en slutsats, och verifiera alltid manuellt innan något hamnar i en rapport som ska stå sig juridiskt.
Komplettera diskforensiken med minnesforensik när det är möjligt. Volatility 3, version 2.28.2 (släppt i september 2026), analyserar RAM-dumpar och hittar processer, nätverksanslutningar och skadlig kod som aldrig skrivs till disk och därför aldrig dyker upp i en Autopsy-avbild. Tar du en minnesdump i samband med imagingen av disken får du en betydligt mer komplett bild av vad som hände vid intrångstillfället.
Autopsy 4.23.x har också en integration mot Cyber Triage för snabbare initial bedömning innan du går in i full djupanalys, vilket är värt att testa om du regelbundet behöver göra en första sållning av misstänkta enheter innan ett helt case byggs upp. Sätt till sist upp en standardiserad mapp- och namnstruktur för alla era case redan nu, innan ni har fler pågående ärenden samtidigt än ni orkar hålla reda på manuellt.
Bygg vidare på triage-skriptet från föregående avsnitt genom att låta det automatiskt skapa ett ärende i ert ärendehanteringssystem eller skicka en notis till incidentresponsteamet så fort det hittar ett visst antal raderade filer eller en misstänkt filtyp. Ett team som kör flera parallella utredningar vinner mycket på att standardisera namngivning av case, taggar och exportmappar redan från start, eftersom det gör det möjligt att söka tvärs över gamla ärenden när samma angripare eller samma tekniker dyker upp igen i ett senare fall. Spara även en kopia av varje triage-rapport i en central mapp separat från de enskilda casen, så byggs över tid en egen kunskapsbas över vilka mönster som återkommer i er organisation.
Så tolkar du resultaten: från enskilda fynd till en sammanhängande slutsats
Den tekniska delen av en utredning, att hitta en raderad fil eller en misstänkt tidsstämpel, är bara halva jobbet. Det som avgör om utredningen håller är hur väl du kan koppla ihop enskilda fynd till en sammanhängande berättelse som förklarar vad som faktiskt hände, i vilken ordning, och varför just de spåren pekar på den slutsatsen. Ett enskilt fynd, som en fil med en misstänkt tidsstämpel, betyder sällan något isolerat. Det är korrelationen mellan flera oberoende källor, filsystemets metadata, en inloggningslogg, en nätverksanslutning, som gör en slutsats trovärdig.
Ett vanligt arbetssätt är att bygga en hypotes tidigt (“angriparen fick åtkomst via ett läckt lösenord den 2 oktober”) och sedan aktivt leta efter bevis som motsäger den, inte bara bevis som bekräftar den. Om du bara letar efter bekräftande spår riskerar du att bygga en slutsats som ser solid ut men som faller samman så fort någon ställer en motfråga. Dokumentera därför även de spår som inte stödjer din första hypotes, det gör den slutgiltiga rapporten mer robust och trovärdig för alla som ska läsa den i efterhand, oavsett om det är en teknisk kollega, en jurist eller en domare.
Skilj också tydligt mellan vad diskavbilden faktiskt visar och vad du drar för slutsats av det. En tom papperskorg betyder inte automatiskt att bevis förstörts medvetet, det kan lika gärna vara ett schemalagt städskript. Formulera dina slutsatser med den grad av säkerhet som bevisningen faktiskt ger, och var tydlig i rapporten när något är en observation och när något är en tolkning.
Autopsy jämfört med andra forensiska verktyg
Autopsy är inte det enda verktyget du bör ha i din verktygslåda. Beroende på vad utredningen handlar om kompletterar andra open source-projekt bilden på olika sätt.
| Verktyg | Primärt användningsområde | Datatyp | Distribution |
|---|---|---|---|
| Autopsy / The Sleuth Kit | Diskforensik, filsystem, tidslinjer | Diskavbilder | Fristående GUI, CLI på Linux/macOS |
| Volatility 3 | Minnesforensik, RAM-analys | Minnesavbilder | CLI, Python-ramverk |
| GRR Rapid Response | Fjärrforensik över stora miljöer | Endpoints i nätverk | Agent/server-arkitektur |
| Velociraptor | Endpoint-forensik och hotjakt | Endpoints i nätverk | Agent/server, VQL-frågor |
| Timesketch | Aggregering av tidslinjer från flera källor | Loggar, tidsstämplar | Webbaserad plattform |
I en större utredning används de här verktygen tillsammans snarare än som alternativ till varandra. Autopsy ger dig diskbilden, Volatility ger dig det som bara fanns i RAM, och om intrånget spänner över flera maskiner tar Velociraptor eller GRR hand om insamlingen från varje endpoint innan Timesketch slår ihop allt till en gemensam tidslinje.
Dataintrång, NIS2 och svensk rapporteringsplikt
En teknisk utredning existerar inte i ett vakuum. Så fort ni bekräftat ett dataintrång som involverar personuppgifter börjar GDPR:s klocka för anmälan till Integritetsskyddsmyndigheten, normalt inom 72 timmar från det att ni fått kännedom om incidenten. NIS2-direktivet lägger till ytterligare krav för organisationer som klassas som leverantörer av samhällsviktiga eller viktiga tjänster, med kortare initiala varningsfrister och krav på uppföljande rapportering.
Det här är ännu en anledning att bygga in forensiken i er incidentresponsplan redan innan något händer, inte improvisera den när larmet går. En triage-pipeline likt skriptet ovan, kombinerad med ett standardiserat caseformat i Autopsy, gör att ni kan lämna ett första underlag till juridik och ledning inom timmar i stället för dagar, vilket direkt påverkar hur mycket tid ni har kvar för den faktiska rapporteringsfristen.
Utöver GDPR och NIS2 kan en polisanmälan bli aktuell om intrånget innefattar dataintrång i brottsbalkens mening eller utpressning, och då blir den dokumenterade beviskedjan från din Autopsy-utredning det material Polisen och eventuellt Åklagarmyndigheten utgår från. En tydlig, hashverifierad kedja från originaldisk till slutrapport gör den processen betydligt smidigare än att i efterhand försöka rekonstruera vad som gjordes när ingen skrev ner det. Om organisationen omfattas av CER-direktivets krav på fysisk och operativ motståndskraft tillkommer ytterligare dokumentationskrav kring hur incidenten påverkade kritisk verksamhet, vilket är ännu ett skäl att inte se den tekniska utredningen som skild från den juridiska och regulatoriska uppföljningen.
Exportera och arkivera caset för långtidsförvaring
En utredning är sällan helt klar bara för att rapporten är skickad. De flesta organisationer behöver spara hela caset, inklusive den ursprungliga avbilden, i flera år efter avslutad utredning, både av juridiska skäl och för att kunna gå tillbaka om samma angripare eller samma teknik dyker upp i en senare incident. Autopsy gör det enkelt att packa ihop hela casekatalogen, inklusive SQLite-databasen, exporterade filer och den genererade rapporten, i en enda arkivfil.
Innan arkivering bör du rensa bort temporära indexfiler som bara behövs medan caset är aktivt öppet, eftersom de ofta är större än själva analysresultatet och inte tillför något värde i ett arkiv. Spara i stället: den ursprungliga diskavbilden tillsammans med dess hashfil, SQLite-databasen för caset, alla exporterade bevisfiler, och den slutgiltiga rapporten i både HTML- och Excel-format. Lagra arkivet på en plats med egen åtkomstkontroll och loggning, separat från den vanliga filservern, eftersom caseinnehållet i sig ofta innehåller känsliga personuppgifter och interna systemdetaljer som inte ska vara tillgängliga för hela organisationen.
Sätt en tydlig gallringsrutin redan från start. Hur länge ni måste spara materialet styrs ofta av en kombination av försäkringsvillkor, avtal med kunder och interna säkerhetspolicyer, inte bara av GDPR:s krav på lagringsminimering. En vanlig modell är att spara den tekniska avbilden i minst så lång tid som en eventuell civilrättslig process kan bli aktuell, och att dokumentera beslutet om lagringstid i samma mapp som resten av caset, så att ingen i efterhand behöver gissa varför materialet fortfarande finns kvar eller redan har raderats.
Vanliga frågor
Är Autopsy gratis att använda kommersiellt?
Ja, Autopsy är öppen källkod och kostar inget att installera eller använda, även i en kommersiell eller myndighetsmiljö. Projektet erbjuder också betald support och utbildning för organisationer som vill ha det.
Kan Autopsy analysera Mac- och Linux-filsystem?
Ja, The Sleuth Kit stödjer flera filsystem utöver NTFS, bland annat HFS+, APFS och ext2/3/4, men stödet varierar mellan versioner. Kontrollera alltid release-anteckningarna för den version du kör innan du förlitar dig på stöd för ett specifikt filsystem i en skarp utredning.
Hur stor diskavbild klarar Autopsy av att hantera?
Det finns ingen hård gräns inbyggd i verktyget, men i praktiken styrs det av din maskins RAM, diskutrymme och tilldelad Java-heap. Avbilder över 100 GB kräver att du höjer heap-storleken och helst kör ingest-modulerna i omgångar i stället för alla samtidigt. Flera utredare rapporterar att avbilder i terabyte-klassen går att hantera, men då förutsätter det en maskin med betydligt mer minne och diskutrymme än vad som räcker för en vanlig bärbar dator.
Går det att återställa alla raderade filer med Autopsy?
Nej. Autopsy kan bara återställa filer vars datablock ännu inte skrivits över av ny data. Ju längre tid som gått och ju mer disken använts efter raderingen, desto sämre chans att filen går att återskapa intakt.
Behöver jag en skrivblockerare för att följa den här guiden?
Om du analyserar en avbild (E01 eller raw/dd) som redan tagits behöver du ingen skrivblockerare för själva Autopsy-analysen. Skrivblockeraren behövs vid det ursprungliga imaging-tillfället, när du kopierar data från originaldisken för första gången.
Hur skiljer sig Autopsy från Volatility 3?
Autopsy analyserar diskavbilder, alltså data som finns lagrad permanent på en hårddisk eller SSD. Volatility 3 analyserar minnesdumpar, det vill säga vad som fanns i RAM vid ett givet ögonblick. De kompletterar varandra snarare än konkurrerar, och en fullständig utredning bör helst inkludera båda.
Räcker Autopsy som enda verktyg vid ett misstänkt dataintrång?
För en utredning begränsad till en enskild maskin och dess diskinnehåll, ja. Men om intrånget spänner över flera system i nätverket behöver du komplettera med endpoint-verktyg som Velociraptor eller GRR Rapid Response för att samla in bevis från samtliga berörda maskiner innan du bygger en gemensam tidslinje.
I vilken ordning bör jag köra ingest-modulerna?
Börja med Hash Lookup och File Type Identification, som snabbt sorterar bort kända systemfiler och flaggar misstänkta filtyper. Kör därefter Timeline för att få en översikt över händelseförloppet, och lägg till Keyword Search och E-mail Parser i en andra omgång när du har en konkret hypotes att testa. Att köra allt i ett enda svep på en stor avbild gör ofta resultatet svårare att tolka, inte lättare.
