Mandiants M-Trends 2026-rapport visar att den globala medianen för hur länge en angripare rör sig obemärkt i ett nätverk steg till 14 dagar under 2025, upp från 11 dagar året innan. IBM:s Cost of a Data Breach 2025 räknar den genomsnittliga livscykeln för ett intrång till 241 dagar, varav 181 dagar går åt bara till att upptäcka att något är fel. Den tiden kostar pengar, kunder och i värsta fall kritisk infrastruktur. Det som faktiskt kortar den här tiden är sällan ett nytt dyrt verktyg, utan förmågan att läsa den trafik som redan passerar nätverket.
Wireshark är fortfarande det verktyg flest säkerhetsteam och nätverksadministratörer landar i när trafiken behöver granskas paket för paket. Det är gratis, öppen källkod, och senaste stabila versionen 4.6.8 släpptes 12 augusti 2026 med rättningar för flera dissector-buggar som upptäckts via AI-assisterad sårbarhetsjakt. Den här guiden går igenom hur du installerar Wireshark, fångar rätt trafik, hittar tecken på intrång i en pcap-fil och bygger ett komplett labbprojekt för att öva på en rekonstruerad attackkedja. Du behöver ingen tidigare erfarenhet av nätverksforensik, bara grundläggande kommandoradsvana och en dator att testa på.
Vi täcker 14 konkreta steg, från installation till bevissäkring, och avslutar med ett eget labb där du får bygga en analysprocess du kan återanvända skarpt. Längs vägen pekar vi ut de vanligaste misstagen nya analytiker gör, och listar lösningar på de tekniska problem som stoppar de flesta första gången de öppnar ett stort fångstfilt.
Vad är nätverksforensik och varför Wireshark fortfarande vinner
Nätverksforensik handlar om att rekonstruera vad som faktiskt hände på ett nätverk genom att analysera trafiken som passerade det, snarare än att lita på loggar som en angripare kan ha manipulerat eller raderat. Till skillnad från ett SIEM som samlar redan tolkade händelser, ger en pakethistorik den råaste och svåraste formen av bevis att förfalska. Om en angripare exfiltrerar data eller kommunicerar med en command-and-control-server måste den trafiken passera nätverket i klartext eller krypterad form, och den lämnar spår som går att fånga.
Wireshark, tidigare känt som Ethereal, har funnits sedan 1998 och är i dag standardverktyget som lärs ut på i princip varje utbildning inom nätverkssäkerhet, inklusive material från SANS Institute. Styrkan ligger inte bara i gränssnittet utan i de över 3 000 protokolldissectorerna som tolkar rå binärdata till läsbara fält. Det gör verktyget användbart både för en nätverkstekniker som felsöker en trög applikation och en incidenthanterare som jagar ett intrång.
Ett vanligt missförstånd är att Wireshark bara passar för djupdykningar i enskilda paket. I praktiken används verktyget lika ofta för att snabbt triagera stora datamängder genom statistikvyer, hitta avvikande mönster i grafer, och sedan zooma in på de paket som faktiskt är intressanta. Den arbetsordningen, från översikt till detalj, är kärnan i hela den här guiden.
Wireshark, tshark, tcpdump eller Zeek: vilket verktyg passar din situation
Wireshark är inte det enda alternativet, och ett moget forensikarbetsflöde använder ofta flera verktyg tillsammans snarare än ett enda. tcpdump är det äldre kommandoradsverktyget som finns förinstallerat på nästan alla Linux-distributioner och är oslagbart för att snabbt fånga trafik på en server utan grafiskt gränssnitt. tshark, som följer med Wireshark-installationen, ger samma dissectorer och filtermotor som det grafiska verktyget men i kommandoradsform, vilket gör det idealiskt för skript och automatisering. Zeek, tidigare Bro, är ett helt annat djur: i stället för att visa paket bygger det strukturerade loggar av nätverksbeteende och passar bättre för kontinuerlig övervakning av stora nätverk än för punktanalys av en enskild pcap-fil.
| Verktyg | Gränssnitt | Bäst för | Svaghet |
|---|---|---|---|
| Wireshark | Grafiskt (GUI) | Djupanalys av enskilda flöden och protokoll | Tungrott på mycket stora filer utan filter |
| tshark | Kommandorad | Skript, automatisering, fjärranslutna servrar | Kräver att du redan kan Wireshark-filtersyntax |
| tcpdump | Kommandorad | Snabb fångst på servrar utan extra beroenden | Begränsad protokolltolkning jämfört med Wireshark |
| Zeek | Loggbaserat | Kontinuerlig övervakning av stora nätverk | Brantare inlärningskurva, ingen paket-för-paket-vy |
En vanlig arbetsmodell är att låta tcpdump eller dumpcap sköta själva fångsten på servern där incidenten inträffade, flytta filen till en analysstation, och sedan öppna den i Wireshark eller köra den genom tshark för automatiserad extraktion. Den modellen är också den vi följer i resten av den här guiden.
Förkunskaper: mjukvara, hårdvara och behörigheter du behöver
Du behöver inte en kraftfull maskin för att komma igång. En bärbar dator med 8 GB RAM klarar de flesta pcap-filer under några hundra megabyte utan problem, men om du planerar att analysera fångster på flera gigabyte bör du räkna med minst 16 GB RAM och gärna en SSD, eftersom Wireshark läser in stora delar av filen i minnet för indexering.
| Komponent | Minimum | Rekommenderat för stora fångster |
|---|---|---|
| Wireshark-version | 4.4.18 (äldre stödgren) | 4.6.8 (aktuell stabil, 12 augusti 2026) |
| Operativsystem | Windows 10, macOS 13 eller Ubuntu 22.04 | Windows 11, macOS 15 eller Ubuntu 24.04 LTS |
| RAM | 4 GB | 16 GB |
| Diskutrymme | 2 GB ledigt | 50 GB+ SSD för ringbuffer-fångster |
| Fångstdrivrutin (Windows) | Npcap 1.79 eller senare | Senaste Npcap med loopback-stöd |
Kunskap du bör ha innan du börjar
- Grundläggande förståelse för TCP/IP, portar och den vanligaste protokollstacken (HTTP, DNS, TLS)
- Kommandoradsvana i Linux eller macOS-terminalen, eller PowerShell på Windows
- Behörighet att installera mjukvara och, om du fångar på en server, root- eller administratörsrättigheter
- Tillgång till en testmiljö eller virtuell maskin där du får generera trafik fritt utan att störa produktion
Se till att all fångst och analys sker inom ramarna för din organisations policy och gällande lagstiftning. Att fånga trafik på ett nätverk du inte äger eller saknar tillstånd för är olagligt i Sverige liksom i resten av Norden, oavsett hur god avsikten är.
GDPR och personuppgifter i en paketfångst
En pcap-fil innehåller nästan alltid personuppgifter i GDPR:s mening, eftersom IP-adresser, e-postadresser i klartext och ibland till och med inloggningsuppgifter räknas som identifierbar information. Det gäller oavsett om syftet med fångsten är legitimt säkerhetsarbete. Innan du sparar en fångst längre än nödvändigt bör du fråga dig vem i organisationen som faktiskt behöver komma åt filen, och för hur länge.
Många organisationer löser det genom att begränsa åtkomst till pcap-filer till en definierad grupp incidenthanterare, lagra dem krypterat, och sätta en tydlig gallringstid som skiljer sig från vanlig loggretention. En incident kopplad till en pågående utredning kan behöva sparas längre, medan rutinmässig felsökningstrafik bör rensas betydligt snabbare. Dataskyddsförordningens princip om lagringsminimering gäller paketdata precis som all annan personuppgiftsbehandling, även om syftet är säkerhet snarare än marknadsföring eller kundhantering.
Ett praktiskt knep är att aktivt undvika att fånga mer än nödvändigt redan i fångstfiltret. Om utredningen bara rör en enskild värd finns sällan skäl att spegla hela nätverkets trafik, vilket både minskar filstorleken och begränsar hur mycket oberoende personuppgifter som samlas in i onödan. Tänk också på att om fångsten ska delas med en extern part, till exempel ett incidentresponsteam eller en myndighet, bör du sanera bort trafik som uppenbart saknar relevans för utredningen innan filen lämnar organisationen.
Steg 1–2: Installera Wireshark 4.6.8 och konfigurera fångsträttigheter
Ladda ner installationspaketet från Wiresharks officiella nedladdningssida snarare än tredjepartskällor, eftersom manipulerade paket har dykt upp på andra ställen tidigare. På Windows installerar guiden automatiskt drivrutinen Npcap, som krävs för att fånga trafik på nätverkskortet. På macOS används i stället det inbyggda BPF-gränssnittet, och på Linux beror det på distributionens paketsystem.
# Ubuntu/Debian: installera Wireshark och tshark
sudo apt update
sudo apt install -y wireshark tshark
# Under installationen väljer du "Yes" på frågan om
# icke-privilegierade användare ska få fånga paket
# Lägg till din användare i wireshark-gruppen manuellt om du missade dialogen
sudo usermod -aG wireshark $USER
# Logga ut och in igen (eller kör nedan för att slippa omstart av sessionen)
newgrp wireshark
# Verifiera installerad version
wireshark --version | head -1
tshark --version | head -1Att köra Wireshark som root för att slippa behörighetsproblem är en vanlig genväg, men avråds starkt eftersom det ger ett komplext program med historik av dissector-buggar full åtkomst till systemet. Wnpa-sec-databasen listar flera denial-of-service-sårbarheter under 2025 och 2026, bland annat CVE-2026-5402, en heap-baserad buffertöverskridning i TLS-dissectorn som påverkade version 4.6.0 till 4.6.4 och som i värsta fall kunde möjliggöra kodkörning. Gruppmedlemskapet ovan löser behörighetsproblemet utan att du behöver köra programmet med förhöjda rättigheter varje gång.
Steg 3–4: Välj rätt gränssnitt och skriv ett fångstfilter i BPF-syntax
När Wireshark startar visas en lista över tillgängliga nätverksgränssnitt med en liten graf som visar aktivitet i realtid. På en bärbar dator är det oftast Wi-Fi-adaptern eller ett kabelanslutet Ethernet-kort som är rätt val, men på en server med flera nätverkskort är det värt att dubbelkolla med ip addr vilket gränssnitt som faktiskt bär den trafik du vill undersöka.
Ett fångstfilter (capture filter) skrivs i BPF-syntax (Berkeley Packet Filter) och avgör vilka paket som överhuvudtaget sparas till disk. Det skiljer sig från visningsfilter, som appliceras efter att fångsten redan är gjord. Att filtrera vid fångsttillfället är avgörande på ett högtrafikerat nätverk, eftersom det håller filstorleken hanterbar och undviker att oberoende trafik, till exempel andra användares webbsurf, sparas i onödan.
# Fånga bara trafik till/från en misstänkt värd
host 10.20.30.40
# Fånga bara trafik på port 443 (TLS) till/från ett subnät
net 192.168.1.0/24 and port 443
# Exkludera störande bakgrundstrafik som SSH-övervakning
not port 22
# Fånga endast DNS-trafik, ofta första ledtråden vid C2-kommunikation
udp port 53Referensen för BPF-syntax finns dokumenterad i Wiresharks wiki om fångstfilter, och den är värd att bokmärka eftersom syntaxen skiljer sig från visningsfiltrens mer läsbara format.
Steg 5: Fånga stora trafikmängder utan att fylla disken med dumpcap
Att låta Wiresharks grafiska gränssnitt fånga trafik under en längre period är sällan en bra idé eftersom hela fångsten hålls i minnet för realtidsvisning. För längre övervakningsperioder, till exempel när du misstänker pågående exfiltrering men behöver flera timmars data för att bekräfta mönstret, är dumpcap rätt verktyg. Det är samma fångstmotor som Wireshark använder under huven, men utan det tunga gränssnittet ovanpå.
# Fånga med ringbuffer: 10 filer à 100 MB, äldsta skrivs över
dumpcap -i eth0 -f "not port 22" -b filesize:100000 -b files:10 -w incident.pcap
# Filerna namnges automatiskt incident_00001_20260905120000.pcap osv.
ls -lh incident_*.pcap
# Slå ihop flera delfiler till en sammanhängande fångst för analys
mergecap -w incident_full.pcap incident_*.pcapRingbuffer-tekniken löser ett problem många upptäcker för sent: en fångst utan gräns kan fylla en hel disk på timmar om trafiken är hög, vilket i värsta fall kraschar den server du försöker övervaka. Genom att sätta ett tak på totalt antal filer garanterar du att fångsten aldrig växer okontrollerat, samtidigt som du behåller ett rullande fönster av den senaste trafiken.
Fånga trafik i molnmiljöer: AWS, Azure och GCP
En stor del av trafiken i en modern Nordic-organisation passerar aldrig ett fysiskt nätverkskort du kan koppla in Wireshark på direkt, eftersom arbetslasten körs i en molnmiljö. Samtliga tre stora molnleverantörer erbjuder i dag inbyggda funktioner för trafikspegling som gör paketfångst möjlig även där. AWS kallar sin funktion VPC Traffic Mirroring, som kopierar trafik från ett nätverksgränssnitt till en målinstans där dumpcap eller Wireshark sedan kan köras som vanligt. Azure har en motsvarande funktion i Virtual Network TAP, och Google Cloud erbjuder Packet Mirroring inom GCP-nätverk.
Gemensamt för alla tre är att speglingen måste konfigureras innan en incident inträffar, precis som nämns i förberedelsefasen ovan. Att sätta upp trafikspegling reaktivt mitt under en pågående attack är fortfarande möjligt i samtliga tre plattformar, men kostar värdefull tid jämfört med att bara starta en redan konfigurerad mållyssnare. En annan skillnad mot lokala nätverk är kostnaden: molnleverantörerna tar ofta betalt per gigabyte speglad trafik, vilket gör det värt att begränsa speglingen till specifika undernät eller instanser snarare än att spegla en hel VPC kontinuerligt.
Containermiljöer lägger till ytterligare ett lager komplexitet, eftersom trafik mellan poddar i ett Kubernetes-kluster ofta aldrig lämnar klustrets interna nätverk och därför inte fångas av traditionell spegling på VPC-nivå. Där används i stället sidecar-mönster eller verktyg som fångar trafik direkt på nod-nivå, men principerna för filtrering, hashning och analys som beskrivs i resten av den här guiden gäller oavsett var fångsten faktiskt sker.
Steg 6–7: Visningsfilter och första triage av en pcap-fil
När en fångst är klar öppnar du filen i Wireshark och börjar med visningsfilter, som skiljer sig från fångstfiltren genom en mer läsbar syntax byggd på fältnamn. En bra vana är att alltid starta bredare än du tror behövs, till exempel genom att titta på Statistics-menyn innan du skriver ett enda filter, för att få en känsla för vilka protokoll och värdar som dominerar trafiken.
# Visa endast HTTP-förfrågningar (klartext, ofta läckta lösenord)
http.request
# Hitta TLS-handskakningar för att kartlägga vilka domäner klienten pratar med
tls.handshake.extensions_server_name
# Filtrera på ovanligt stora DNS-svar, ett tecken på DNS-tunnling
dns and frame.len > 300
# Kombinera flera villkor: trafik till en specifik IP som inte är HTTPS
ip.addr == 10.20.30.40 and not tcp.port == 443Full referens för samtliga fältnamn finns i Wiresharks Display Filter Reference, som listar alla protokoll och fält Wireshark känner till. Den är sökbar och betydligt snabbare att slå upp i än att gissa sig fram i gränssnittet.
Steg 8: Följ TCP-strömmen och hitta klartextuppgifter
Ett av de mest praktiska verktygen i Wireshark är funktionen Follow TCP Stream, som slår ihop alla paket i en session till en läsbar konversation. Högerklicka på ett paket i ett misstänkt flöde och välj Follow, sedan TCP Stream, för att se hela utbytet mellan klient och server i klartext där det är möjligt.
Det här är ofta stunden då en analytiker hittar det första konkreta beviset: ett FTP-, Telnet- eller ohärdat HTTP-formulär som skickar användarnamn och lösenord okrypterat. Även om moderna applikationer i regel krypterar autentisering med TLS, förekommer äldre interna system, felkonfigurerade IoT-enheter och illa underhållna admin-paneler fortfarande i nordiska nätverk, och de är exakt den typen av svaghet en angripare letar efter för att röra sig i sidled.
Om trafiken är TLS-krypterad ser du bara handskakningen i klartext, inte innehållet, vilket vi återkommer till i avsnittet om avancerade tips längre ner där du får en metod för att dekryptera din egen testtrafik.
Steg 9: Upptäck DNS-tunnling och beaconing-mönster
DNS är ett av de mest missbrukade protokollen för att smuggla ut data eftersom de flesta brandväggar tillåter utgående DNS-trafik utan att ifrågasätta den. Tecken på DNS-tunnling inkluderar ovanligt långa subdomäner, en hög volym TXT- eller NULL-recordsökningar, och upprepade uppslag mot samma ovanliga domän med korta intervall.
Beaconing, där skadlig kod regelbundet ringer hem till en C2-server för att hämta instruktioner, syns bäst genom att titta på tidsintervallet mellan anrop snarare än enskilda paket. Ett flöde som slår upp samma domän exakt var 60:e sekund, dygnet runt, är ett betydligt starkare tecken på automatiserad kommunikation än enstaka trafiktoppar. Statistics > Conversations i Wireshark, sorterat på antal paket och varaktighet, gör den typen av mönster synligt utan att du behöver bläddra manuellt genom tusentals rader.
Steg 10: Hitta C2-trafik med Statistics och IO Graph
Menyn Statistics > IO Graph ritar upp trafikvolym över tid och gör det möjligt att lägga flera filter som separata linjer i samma graf. Det är särskilt användbart för att jämföra normal trafik mot en misstänkt destination med resten av nätverkets aktivitet, och för att hitta exakt tidpunkten då ett avvikande mönster började.
Statistics > Endpoints ger en sammanställning av alla IP-adresser i fångsten, sorterbar efter datavolym, vilket snabbt avslöjar om en enskild intern värd skickat en ovanligt stor mängd data till en extern adress. Kombinerat med Statistics > Protocol Hierarchy, som bryter ner trafiken per protokoll i procent, kan du på några minuter avgöra om en misstänkt värd främst pratar HTTP, ett obskyrt protokoll på en icke-standardport, eller okänd binärdata som inte matchar något känt dissectormönster alls, vilket i sig är en varningssignal.
Steg 11: Extrahera exfiltrerade filer med Export Objects
Om trafiken innehåller filöverföringar över HTTP, FTP eller SMB kan Wireshark plocka ut de faktiska filerna direkt ur fångsten via File > Export Objects. Välj rätt protokoll i undermenyn, bläddra i listan över identifierade objekt, och spara de filer som ser intressanta ut för vidare analys, till exempel i en sandlåda eller mot en virustotal-liknande tjänst.
Den här funktionen är ovärderlig när du behöver bevisa exakt vad som lämnade nätverket, inte bara att något gjorde det. En exporterad fil du kan hasha, analysera och jämföra mot kända hot är ett betydligt starkare underlag i en incidentrapport än en rad i en logg som bara säger att en överföring ägde rum.
Steg 12–13: Automatisera analysen med tshark och säkra bevisen
Manuell analys i det grafiska gränssnittet fungerar bra för enstaka fångster, men skalar dåligt när du behöver gå igenom flera pcap-filer eller köra samma kontroller upprepade gånger under en pågående incident. tshark löser det genom att exponera samma filtermotor via kommandoraden, vilket gör det enkelt att bygga skript som körs automatiskt.
# Extrahera alla unika DNS-uppslagningar från en fångst
tshark -r incident_full.pcap -Y "dns.flags.response == 0" \
-T fields -e dns.qry.name | sort -u
# Räkna paket per källadress, sorterat fallande, för snabb triage
tshark -r incident_full.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -20
# Exportera fynd som JSON för vidare bearbetning i ett skript
tshark -r incident_full.pcap -Y "http.request" -T json > http_requests.jsonNär analysen är klar och du identifierat relevanta filer är nästa steg att säkra dem som bevis. Det innebär att beräkna en kryptografisk hash av varje originalfil innan någon vidare bearbetning sker, så att du senare kan bevisa att filen inte manipulerats mellan fångst och rapport.
# Beräkna SHA-256-hash av originalfångsten och logga tidpunkt
sha256sum incident_full.pcap > incident_full.pcap.sha256
date -u +"%Y-%m-%dT%H:%M:%SZ" >> chain_of_custody.log
echo "Analytiker: [namn], hash sparad i incident_full.pcap.sha256" >> chain_of_custody.log
# Verifiera integriteten senare genom att jämföra hash igen
sha256sum -c incident_full.pcap.sha256Den här beviskedjan, ofta kallad chain of custody, är inte bara god praxis utan ofta ett krav om fyndet någonsin ska användas i en polisanmälan eller rättsprocess. NIST SP 800-61 revision 3, publicerad i april 2025 under namnet “Incident Response Recommendations and Considerations for Cybersecurity Risk Management”, lyfter fram dokumentation och spårbarhet som en av de mest underskattade delarna av ett fungerande incidentsvar.
Så här ser verklig utdata ut i praktiken
Det är lätt att läsa kommandon i en guide utan att veta vad de faktiskt ska producera. Nedan är exempel på hur utdata ser ut från kommandona i föregående steg, körda mot en typisk pcap-fil från en simulerad DNS-tunnling. Jämför alltid din egen utdata mot ett exempel som detta för att snabbt avgöra om filtret fungerade som tänkt eller om du behöver justera syntaxen.
$ tshark -r incident_full.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort -u
a8f3e91c2b7d4f.data-exfil.example-c2.net
b2c4a018ef39dd.data-exfil.example-c2.net
d91fa237c0b81e.data-exfil.example-c2.net
mail.google.com
safebrowsing.googleapis.com
www.microsoft.comDe tre första raderna sticker ut direkt: långa, slumpmässiga subdomäner mot samma huvuddomän är ett klassiskt fingeravtryck för DNS-tunnling, medan resten av listan är helt normal bakgrundstrafik från operativsystem och webbläsare. Den typen av visuell kontrast är precis vad du letar efter i triage-fasen, långt innan du behöver öppna ett enda paket i det grafiska gränssnittet.
$ tshark -r incident_full.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -5
4821 10.20.30.15
932 10.20.30.1
411 8.8.8.8
287 10.20.30.40
94 172.217.21.14Här syns att värden 10.20.30.15 dominerar trafiken med god marginal, vilket motiverar att den blir nästa mål för en djupare filtrering med ip.addr == 10.20.30.15 i det grafiska gränssnittet. Att alltid gå från den här typen av räkneövning till ett riktat filter, snarare än att bläddra planlöst, är det som skiljer en effektiv triage från en som tar hela dagen.
Wireshark i NIST:s fyra faser för incidentrespons
NIST SP 800-61 revision 3 delar in incidentarbete i fyra övergripande faser: förberedelse, detektion och analys, begränsning och återställning, samt efterarbete. Att förstå var i den cykeln paketanalys faktiskt hör hemma gör det lättare att motivera tidsåtgången för ledningen och att undvika att fastna i teknisk detalj när organisationen egentligen behöver ett snabbt beslutsunderlag.
I förberedelsefasen handlar Wiresharks roll om att se till att fångstinfrastruktur, som SPAN-portar eller nätverkstappar, redan finns på plats innan en incident inträffar. Att första gången konfigurera trafikspegling mitt under en pågående attack kostar dyrbara timmar som analytikern annars kunde lagt på faktisk utredning.
Detektions- och analysfasen är där merparten av den här guiden befinner sig: fångst, filtrering, statistik och extraktion av bevis, som beskrivits i stegen ovan. Fynden från den här fasen matas sedan in i begränsningsfasen, där paketanalysen ofta avgör vilka värdar som behöver isoleras från nätverket och vilka brandväggsregler som behöver läggas till akut för att stoppa pågående exfiltrering. Slutligen, i efterarbetsfasen, blir de hashade pcap-filerna och den dokumenterade beviskedjan underlag för rapportskrivning och för att uppdatera detektionsregler så att samma beteende fångas snabbare nästa gång.
Steg 14: Mappa fynden mot MITRE ATT&CK v19.2
Ett paketfynd blir mer värdefullt när det sätts i sammanhang, och MITRE ATT&CK-ramverket är branschstandarden för att beskriva angriparbeteende med ett gemensamt språk. Den aktuella versionen, v19.2, uppdaterades 6 augusti 2026 och byggde vidare på v19-släppet från april samma år, som delade upp den tidigare taktiken Defense Evasion i två separata taktiker: Stealth (TA0005) och Defense Impairment (TA0112).
I praktiken betyder det att DNS-tunnling du hittar i steg 9 kan mappas mot tekniken Application Layer Protocol under taktiken Command and Control, medan onormalt stora dataöverföringar till en extern värd hör hemma under Exfiltration. Att konsekvent tagga varje fynd med rätt ATT&CK-teknik gör det enklare att jämföra en incident mot tidigare händelser och att kommunicera fyndet till kollegor som redan känner till ramverket, snarare än att beskriva samma beteende med olika ord varje gång.
Bygg ett komplett labbprojekt: rekonstruera en intrångskedja
Teori fastnar sämre än övning, så den här sektionen går igenom ett fullständigt labbprojekt du kan bygga på en egen virtuell maskin för att träna hela arbetsflödet från fångst till rapport. Målet är en självständig miljö där du både genererar och analyserar trafik, helt isolerad från produktionsnät.
- Sätt upp två virtuella maskiner i ett isolerat internt nätverk (till exempel via VirtualBox eller VMware), en som spelar “offer” och en som spelar “angripare”.
- Installera en enkel webbserver utan HTTPS på offermaskinen och ett formulär som skickar inloggningsuppgifter med POST över klartext-HTTP.
- Starta dumpcap på offermaskinens gränssnitt med en ringbuffer enligt kommandot i steg 5.
- Från angriparmaskinen, logga in via formuläret, och kör därefter ett enkelt skript som slår upp en lång, slumpad subdomän var 30:e sekund mot en domän du kontrollerar, för att simulera DNS-tunnling.
- Ladda ner en godartad testfil (till exempel en textfil med påhittat innehåll) från offermaskinen till angriparmaskinen via HTTP för att simulera exfiltrering.
- Stoppa fångsten, slå ihop delfilerna med mergecap, och öppna resultatet i Wireshark.
- Använd Follow TCP Stream för att hitta inloggningsuppgifterna i klartext från steg 2.
- Filtrera på DNS och identifiera det upprepade uppslagsmönstret från steg 4 med hjälp av Statistics > Conversations.
- Exportera testfilen från steg 5 via File > Export Objects och verifiera att den matchar originalet med en hash.
- Skriv en kort incidentrapport på en sida som sammanfattar vad som hände, vilka IP-adresser och tidsstämplar som var inblandade, och vilka ATT&CK-tekniker beteendet motsvarar.
Kör gärna labbet flera gånger med olika variationer, till exempel genom att lägga till brus i form av vanlig webbsurf i bakgrunden, för att öva på att skilja ut den relevanta trafiken ur en större mängd normal aktivitet. Det är precis den färdigheten som skiljer en analytiker som klarar en verklig incident från en som bara klarar ett rent labb.
Vanliga fallgropar när du analyserar paket
De flesta nya analytiker gör samma handfull misstag, och att känna igen dem i förväg sparar timmar av frustration.
- Fångar utan filter på ett högtrafikerat nätverk. Resultatet blir en flera gigabyte stor fil som tar minuter att öppna och är omöjlig att navigera utan att systemet hänger sig.
- Förväxlar fångstfilter och visningsfilter. Syntaxen ser liknande ut men fungerar helt olika, och ett visningsfilter skrivet i fångstrutan ger bara ett felmeddelande.
- Litar blint på tidsstämplar utan att kontrollera tidszon och klocksynk. Om offer- och angriparmaskin har olika systemklockor blir hela händelseförloppet förskjutet i rapporten.
- Analyserar en kopia som redan manipulerats. Att öppna och spara om en pcap-fil i fel verktyg kan ändra metadata, vilket är exakt varför hashning av originalet i steg 13 är obligatoriskt, inte valfritt.
- Missar krypterad trafik helt. En analytiker som bara letar efter klartext missar att en stor del av modern skadlig kod kommunicerar över TLS, vilket kräver andra tekniker än Follow Stream.
- Drar slutsatser från ett enda paket. Ett enskilt udda paket kan vara brus, en felkonfiguration eller en normal retransmission. Mönster över tid, inte enstaka händelser, är det som håller i en incidentrapport.
Felsökning: 8 vanliga problem och lösningar
| Problem | Trolig orsak | Lösning |
|---|---|---|
| Inga gränssnitt syns i listan | Saknar behörighet eller Npcap/BPF är inte installerat | Kör om installationen och kryssa i drivrutinsstödet, eller lägg till användaren i wireshark-gruppen på Linux |
| “Permission denied” vid start av fångst | Användaren saknar rättighet till rådata-sockets | Kör sudo usermod -aG wireshark $USER och logga in igen, undvik att köra som root |
| Wireshark fryser vid öppning av stor fil | För lite RAM för filstorleken, eller ingen filtrering vid fångst | Använd tshark för första genomgången, eller dela upp filen med editcap innan den öppnas grafiskt |
| Ser bara krypterad TLS, ingen nyttolast | Trafiken är korrekt krypterad, förväntat beteende | Använd SSLKEYLOGFILE för egen testtrafik, se avancerade tips nedan |
| Filtret ger inga träffar trots synlig trafik | Stavfel i fältnamn eller fel logisk operator | Slå upp exakt fältnamn i Display Filter Reference innan du skriver om filtret |
| dumpcap avslutas oväntat under lång fångst | Disken blev full eftersom ringbuffer inte konfigurerats | Sätt alltid -b filesize och -b files tillsammans, aldrig fångst utan gräns |
| Export Objects listar inga filer trots synlig filöverföring | Protokollet är inte ett av de Wireshark stödjer för extraktion, eller trafiken är krypterad | Kontrollera vilka protokoll som stöds under menyn och bekräfta att trafiken faktiskt är oskyddad |
| tshark-kommandot ger “capture permission denied” | Samma behörighetsproblem som i GUI, men syns tydligare i terminalen | Kör samma gruppkonfiguration som för Wireshark, tshark delar samma fångstmotor |
Avancerade tips för erfarna analytiker
När grunderna sitter finns det tre tekniker som lyfter analysen från grundläggande triage till djupare utredning. Den första är att dekryptera din egen TLS-trafik i testmiljö genom miljövariabeln SSLKEYLOGFILE, som får webbläsare som Chrome och Firefox att logga sessionsnycklar till en fil Wireshark sedan kan läsa in under Edit > Preferences > Protocols > TLS. Det fungerar bara på trafik du själv genererar med kontroll över klienten, aldrig på trafik från tredje part, men är ovärderligt för att förstå hur en applikation faktiskt beter sig bakom krypteringen.
Den andra tekniken är att skriva en egen Lua-dissector för ett internt eller obskyrt protokoll som Wireshark inte känner till. Wiresharks User’s Guide innehåller ett helt kapitel om Lua-scripting, och även en enkel dissector som bara namnger okända fält gör en tidigare oläslig binärström betydligt lättare att arbeta med.
Den tredje är att kombinera tshark med jq för att bygga snabba, återanvändbara analyspipelines. Genom att exportera fynd som JSON, som visas i steg 12, går det att filtrera, gruppera och räkna resultat med samma verktygslåda som redan används för loggbearbetning i de flesta säkerhetsteam, i stället för att bygga en helt separat process bara för pakethantering.
En fjärde teknik som ofta förbises är att bygga egna coloring rules under View > Coloring Rules. Standardfärgerna i Wireshark är byggda för allmän nätverksfelsökning, inte för intrångsjakt, så en regel som färgar all trafik mot en lista misstänkta IP-adresser i klarröd gör det möjligt att skumma tusentals rader och ändå fånga varje relevant paket med blicken. Spara gärna en egen uppsättning regler som standard för incidentarbete, separat från de regler du använder vid vanlig nätverksfelsökning, så slipper du bygga om filtren varje gång en ny utredning startar.
Den som tar sig igenom alla 14 steg och labbprojektet ovan har byggt en arbetsprocess som går att skala upp direkt i en skarp incident, inte bara en isolerad övning. Nästa naturliga steg är att koppla den processen till organisationens befintliga verktyg, till exempel genom att låta ett SIEM som Wazuh trigga en automatisk fångst så fort en regel slår till, i stället för att förlita dig på att någon manuellt startar dumpcap efter att larmet redan gått. Kombinationen av snabb detektion och en färdig forensikprocess är det som i praktiken kortar de 14 dagar Mandiant mäter som global median ner mot de timmar en väl förberedd organisation faktiskt klarar av.
Vanliga frågor
Är det lagligt att fånga nätverkstrafik i Sverige?
Ja, förutsatt att du fångar trafik på ett nätverk du äger eller har uttryckligt tillstånd att övervaka. Att avlyssna trafik på ett nätverk utan tillstånd, till exempel ett öppet Wi-Fi du inte administrerar, kan utgöra brott mot både dataskyddslagstiftning och brottsbalken.
Kan Wireshark läsa krypterad TLS-trafik utan nycklar?
Nej. Wireshark visar handskakningen och metadata som vilken domän klienten ansluter till, men kan inte läsa den krypterade nyttolasten utan tillgång till sessionsnycklarna, till exempel via SSLKEYLOGFILE eller serverns privata nyckel i vissa äldre TLS-versioner.
Hur stor pcap-fil klarar Wireshark att öppna?
Det finns ingen hård gräns i programmet, men praktiken styrs av tillgängligt RAM. Filer över några gigabyte bör i första hand bearbetas med tshark eller delas upp med editcap innan de öppnas i det grafiska gränssnittet.
Vad är skillnaden mellan ett fångstfilter och ett visningsfilter?
Ett fångstfilter avgör vilka paket som sparas till disk och skrivs i BPF-syntax. Ett visningsfilter appliceras efter fångsten och styr bara vad du ser i gränssnittet, utan att påverka den underliggande filen.
Behöver jag Wireshark om jag redan har ett SIEM som Wazuh eller Splunk?
Ett SIEM analyserar redan tolkade loggar och händelser, medan Wireshark ger tillgång till rå nätverksdata som aldrig passerar en logg om ingen agent eller sensor fångar den. De kompletterar varandra snarare än att ersätta varandra, särskilt för trafik från enheter som saknar agentstöd.
Vilken version av Wireshark bör jag använda 2026?
Den aktuella stabila versionen är 4.6.8, släppt 12 augusti 2026, som innehåller säkerhetsrättningar för flera dissector-sårbarheter. Äldre stödgrenar som 4.4.18 får fortfarande säkerhetsuppdateringar men saknar de senaste protokollstöden.
Kan jag använda Wireshark för att uppfylla NIS2-krav på incidenthantering?
Wireshark ger dig ett tekniskt verktyg för att utreda en incident i detalj, men NIS2 kräver också dokumenterade rutiner, tidsgränser för anmälan och en fungerande organisation runt hanteringen. Se paketanalysen som en del av utredningsförmågan, inte hela regelefterlevnaden.
Hur länge bör jag spara pcap-filer efter en incident?
Det beror på organisationens policy och eventuella regulatoriska krav, men en vanlig praxis är att behålla fångster kopplade till en bekräftad incident permanent eller i flera år, medan rutinmässig övervakningstrafik ofta roteras bort efter veckor eller månader av lagringsskäl.
