Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
En IOC (indicator of compromise) er et teknisk kendetegn, der tyder på, at et system er eller har været kompromitteret: en hashværdi, en IP-adresse, et domæne, et filnavn eller en registreringsnøgle. Et fund viser, at noget i jeres data matchede en indikator på en liste. Det beviser ikke i sig selv, at et angreb fandt sted, hvem der stod bag, eller hvad der blev berørt. I en civil sag er det forskellen mellem en alarm og et bevis.
Artiklen er til SOC’er, der skal bruge IOC-fund i en rapport, der kan blive brugt i en tvist, fx med en forsikring, en leverandør eller en kunde. Den bygger bro til IR-rapporten som bevis.
Hvad en IOC er
NIST beskriver indikatorer som tekniske artefakter eller observationer, der tyder på, at et angreb er nært forestående, er i gang, eller at en kompromittering kan have fundet sted. Ordet “tyder” er vigtigt. En indikator er en hypotese, der skal bekræftes.
De almindeligste typer:
- Hashværdi · Eksempel: SHA-256 af en skadelig fil · Holdbarhed: Præcis, men ændres ved den mindste ændring af filen
- IP-adresse · Eksempel: Adresse på en styringsserver · Holdbarhed: Kort; adresser genbruges og deles
- Domæne og url · Eksempel: Domæne brugt til phishing eller styring · Holdbarhed: Kort til middel
- Artefakter på værten · Eksempel: Filsti, tjenestenavn, registreringsnøgle, planlagt opgave · Holdbarhed: Middel
- Netværksmønstre · Eksempel: User agent, certifikat, kommunikationsmønster · Holdbarhed: Middel
Over de konkrete indikatorer ligger angribernes adfærd, ofte beskrevet med MITRE ATT&CK som taktikker og teknikker. Adfærd er sværere at ændre end en IP-adresse, men også sværere at bevise med et enkelt fund.
Hvor IOC’erne kommer fra
Kilden afgør meget af værdien:
- Egen undersøgelse: indikatorer fundet i det konkrete miljø, fx en fil på en kompromitteret server. De er stærke, fordi de er knyttet til sagen.
- IR-leverandør eller myndighed: lister fra en rådgivning eller en advarsel. De er nyttige, men konteksten er en anden sag eller en generel kampagne.
- Kommercielle og åbne feeds: store mængder indikatorer med varierende kvalitet, alder og dokumentation.
I en rapport skal kilden og dens tidspunkt fremgå for hver liste, der er brugt. En liste fra et feed uden dato eller begrundelse er svær at forsvare. Det samme gælder lister, der løbende opdateres: hvis listen er ændret mellem søgningen og rapporten, skal det være muligt at vise præcis den version, der blev brugt. Gem den derfor som en fast fil sammen med sagen.
Falske fund
IOC-fund giver jævnligt falske positiver, og det er dem, en modpart vil angribe:
- Delt infrastruktur. En IP-adresse hos en cloud- eller CDN-udbyder kan have tjent både en skadelig og hundredvis af legitime tjenester. Et opslag mod adressen siger ikke, hvilken tjeneste der blev brugt.
- Gamle indikatorer. Et domæne, der var skadeligt for to år siden, kan være overtaget af en anden.
- Legitime værktøjer. Fjernadministrationsværktøjer og systemværktøjer optræder på IOC-lister, fordi angribere bruger dem. Men IT-afdelingen gør det også.
- Generiske filnavne. Et filnavn som
update.exesiger intet uden hashværdi og placering. - Forkert tidsvindue. Et fund uden for den periode, hvor kampagnen var aktiv, er ofte uden betydning.
Ved forbindelser til IP-adresser gælder de samme forbehold som ved IP-adresser i al almindelighed. Se IP-adresser som bevis.
Når IOC’en bruges i en tvist
I civile sager er spørgsmålet sjældent, om et system var kompromitteret, men hvornår og under hvis ansvar. Tre spørgsmål går igen:
- Hvornår begyndte det? Ved en tvist med en driftsleverandør kan det afgøre sagen, om det første fund ligger før eller efter et skift af leverandør, en opdatering eller en ændring i konfigurationen.
- Var det forudsigeligt? Var indikatoren offentligt kendt, før den blev fundet i miljøet? Så kan spørgsmålet blive, om den burde have været opdaget tidligere. Datoen for listens offentliggørelse skal derfor dokumenteres sammen med fundet.
- Hvad omfattede det? Forsikringsselskaber og modparter vil vide, hvilke systemer der var berørt. Fund på én maskine siger ikke noget om de andre, medmindre de også er undersøgt.
Søges der i historiske logs med indikatorer, der først blev kendt senere, skal det fremgå, at søgningen er retrospektiv. Det er en styrke, ikke en svaghed, men det ændrer, hvad fundet kan sige om, hvad nogen vidste på tidspunktet.
Fravær af fund
Det modsatte er lige så vigtigt: at en IOC-søgning ikke giver fund, viser ikke, at systemet ikke var kompromitteret. Det viser kun, at de søgte indikatorer ikke fandtes i de data, der blev søgt i. Svaret afhænger af:
- hvilke datakilder der indgik, og for hvilken periode
- om logningen var slået til og ikke overskrevet
- om angriberen brugte nye eller tilpassede værktøjer
En rapport, der konkluderer “ingen kompromittering” alene ud fra en IOC-scanning, er en af de svageste konklusioner, der kan fremlægges. Det systematiske alternativ er beskrevet i compromise assessment.
Fra fund til bevis
Et IOC-fund bliver først til bevis, når det er bekræftet og sat i sammenhæng. For hvert vigtigt fund bør rapporten vise:
- Rådata: den konkrete logpost, fil eller hændelse, der matchede, med tidspunkt og kilde.
- Bekræftelse: fx at filen med den fundne hashværdi faktisk findes, er analyseret og opfører sig skadeligt, eller at forbindelsen til domænet faktisk overførte data.
- Kontekst: hvilken proces, konto og maskine fundet hører til, og hvad der skete før og efter.
- Alternative forklaringer: om fundet kan skyldes legitim brug, og hvorfor den forklaring er afvist.
Telemetri fra EDR er ofte den bedste kilde til trin 2 og 3; se EDR-telemetri som bevis. Koblingen mellem kilderne er beskrevet i logkorrelation.
Dokumentation af søgningen
En IOC-søgning skal kunne gentages. Det kræver:
- listen over indikatorer, med kilde, version og dato, gemt sammen med sagen og med hashværdi
- de datakilder og den periode, der blev søgt i
- værktøj, forespørgsel og tidspunkt for søgningen
- antal fund, og hvordan hvert fund blev vurderet
Hvis indikatorerne er udvekslet i et struktureret format som STIX, indeholder de ofte felter for gyldighedsperiode og tillid. De oplysninger bør med i rapporten, fordi de viser, hvor sikker kilden selv var.
Hvad IOC’er kan og ikke kan bevise
Et bekræftet IOC-fund kan vise, at et bestemt skadeligt element var til stede på et bestemt sted og tidspunkt, og det kan pege på, at hændelsen hører til en kendt kampagne. Det kan ikke alene vise, hvordan angriberen kom ind, hvilke data der blev tilgået, eller hvem der stod bag. Tilskrivning til en bestemt aktør bygger på et samlet billede og er sjældent afgørende i en civil tvist. Her er det typisk vigtigere at vise tidspunkt, indgang og omfang.
Kilder og versioner
Senest gennemgået: oktober 2026.
Næste skridt
- NIS2: varsling og rapporter set fra logkilderne
- Overdragelse fra IR-team til sagkyndig
- Bevissikringstrin i jeres IR-playbooks
Del af: Undersøgelse efter et hackerangreb
Læs også: Compromise assessment: er vi kompromitteret uden en kendt hændelse? · Forensic eller incident response? Forskellen og samspillet
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
