Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
En compromise assessment er en afgrænset undersøgelse af, om et IT-miljø er eller har været kompromitteret, selvom der ikke er en kendt hændelse. Den bruges typisk ved opkøb og fusioner, ved ny ledelse eller nyt IT-ansvar, ved skift af IT-leverandør og efter en hændelse hos en leverandør eller samarbejdspartner. Resultatet er ikke en garanti for, at miljøet er rent, men en dokumenteret vurdering af, hvad der blev undersøgt, og hvad der blev fundet.
Artiklen beskriver metoden og de kilder, der indgår, og hvordan undersøgelsen dokumenteres, så den kan bruges, hvis spørgsmålet senere bliver en tvist, fx om en garanti i en købsaftale eller om en leverandørs ansvar.
Forskellen på assessment, pentest og incident response
En penetrationstest undersøger, om det er muligt at komme ind. En compromise assessment undersøger, om nogen allerede er kommet ind. Incident response starter fra en kendt hændelse og arbejder på at inddæmme den. En compromise assessment starter uden et kendt udgangspunkt og arbejder bredt for at finde spor, der ellers ville være overset. Hvordan forensic og incident response spiller sammen, er beskrevet i forensic eller incident response.
Afgrænsning før start
Uden en skarp afgrænsning bliver resultatet hverken brugbart eller efterprøveligt. Før undersøgelsen aftales:
- Spørgsmålet. Er det “har nogen haft adgang til miljøet i den seneste periode”, eller er det mere specifikt, fx om konti med privilegier er misbrugt, eller om data kan være sendt ud?
- Perioden. Hvor langt tilbage rækker de kilder, der findes? Det sætter grænsen for, hvad undersøgelsen kan sige noget om.
- Omfanget. Hvilke domæner, tenants, servere, klienter, cloudkonti og netværkssegmenter indgår, og hvilke gør ikke?
- Hvem der får resultatet. Ved opkøb er der ofte flere parter, og fortrolighed og adgang til rådata skal aftales.
Kilderne
En compromise assessment kombinerer øjebliksbilleder af systemernes tilstand med historiske logs:
- Identitet · Entra ID’s login- og revisionslog, Active Directory, privilegerede roller, appsamtykker og tjenestekonti
- Endpoints · EDR-telemetri, autostart, tjenester, planlagte opgaver, installerede fjernadgangsværktøjer og lokale administratorer
- Mail og samarbejde · Indbakkeregler, videresendelse, delegeringer, OAuth-apps og delte filer
- Netværk · DNS, proxy, firewall og VPN, særligt forbindelser til ukendte eller nyregistrerede domæner
- Cloud · Activity logs, nøgler og tokens, nye ressourcer og ændrede adgangspolitikker
- Backup · Ændringer af backupjob og opbevaring, og om backuppen kan bruges som tidsmaskine
Fastholdt adgang er ofte det mest givende sted at lede, fordi en angriber, der vil tilbage, efterlader noget, der overlever en genstart eller et skift af adgangskode. Se autostart, planlagte opgaver og tjenester. I cloudmiljøer gælder det samme for registrerede enheder, appsamtykker og tjenestekonti med egne hemmeligheder.
Metoden
En compromise assessment er hypotesedrevet. Typiske angrebsteknikker, fx som beskrevet i MITRE ATT&CK, omsættes til konkrete spørgsmål til kilderne:
- Indsaml bredt og ensartet. Samme triage-indsamling på alle relevante endpoints og samme logudtræk fra identitet og cloud. Ensartethed er en forudsætning for at sammenligne. Se triage.
- Fastlæg det normale. Hvilke administratorværktøjer, fjernadgangsprogrammer og planlagte opgaver er godkendte? Uden en baseline er alt mistænkeligt, eller intet er.
- Søg efter afvigelser. Sjældne programmer, ukendte tjenester, logins fra usædvanlige steder, nye appsamtykker, regler, der videresender mail, og konti, der har fået privilegier uden for normale procedurer.
- Undersøg fundene i dybden. Hvert fund vurderes: forklaret, uafklaret eller tegn på kompromittering. Uafklarede fund følges op, ikke bare noteres.
- Afgør, hvornår noget bliver en hændelse. Hvis der findes tegn på aktiv kompromittering, skifter opgaven til incident response, og sikringen af beviser skal ske, før der ryddes op.
Det sidste punkt bør være aftalt på forhånd: hvem der informeres, hvem der beslutter inddæmning, og hvordan beviserne sikres, inden noget ændres.
Særligt ved opkøb og leverandørskift
Ved et opkøb er tiden ofte kort, og adgangen til målvirksomhedens systemer begrænset, før handlen er gennemført. En compromise assessment i den fase bliver derfor tit en kombination af en gennemgang af konfiguration og de logs, sælger kan udlevere, og en mere fuldstændig undersøgelse efter overtagelsen. Det er vigtigt, at rapporten skelner mellem de to, og at det fremgår, hvilke data der er leveret af sælger, og hvilke der er indsamlet direkte. Data leveret af en part, der har interesse i resultatet, har en anden vægt end data, den undersøgende selv har hentet og hashet.
Ved skift af IT-leverandør er spørgsmålet ofte, om den tidligere leverandørs konti, fjernadgangsværktøjer og tokens er fjernet, og om der er tegn på misbrug i perioden op til skiftet. Her er leverandørens egne konti og RMM-værktøjer centrale kilder, og den nye leverandør bør ikke rydde op, før de er dokumenteret. Se IT-leverandørens adgang.
Hvor længe tilbage?
Den periode, en assessment kan dække, bestemmes af den kilde med kortest opbevaring blandt dem, der er nødvendige for at besvare spørgsmålet. Loginlogs i Entra ID har ved gennemgangen en standardopbevaring på 7 eller 30 dage afhængigt af licens, medmindre de sendes videre. Lokale hændelseslogs ruller efter størrelse. EDR-telemetri gemmes typisk i en begrænset periode, der afhænger af produkt og aftale. Backupper og arkiverede logs kan forlænge perioden markant og bør afdækkes tidligt. Hvordan det første tidspunkt for en kompromittering fastlægges, er beskrevet i dwell time.
Resultatet: hvad det kan og ikke kan bære
Den rigtige formulering af et resultat uden fund er, at der ikke blev fundet tegn på kompromittering i de undersøgte kilder i den undersøgte periode. Det er en væsentlig oplysning, men den er begrænset af:
- Kildernes dækning. En logkilde, der kun går 30 dage tilbage, kan ikke sige noget om forhold for tre måneder siden.
- Det ikke-undersøgte. Systemer uden logning, ikke-administrerede enheder og tredjepartssystemer uden for omfanget.
- Detektionsgrænser. En dygtig angriber, der bruger legitime værktøjer og konti, kan være svær at adskille fra almindelig drift.
Fravær af fund er ikke bevis for fravær af kompromittering. Se fravær af spor. Rapporten bør derfor indeholde en eksplicit liste over, hvad der ikke blev undersøgt, og hvorfor.
Dokumentation, der holder
En compromise assessment, der senere kan blive brugt i en tvist, skal dokumenteres som en forensisk undersøgelse: indsamlingsmetode og værktøjer, hashværdier for indsamlede data, tidspunkter og konti brugt til indsamlingen, de konkrete søgninger og deres resultater, og fundenes klassifikation med begrundelse. Konklusioner, der bygger på en IR-leverandørs værktøj, bør kunne efterprøves fra rådata.
Hvis undersøgelsen skal kunne bruges af flere parter, fx køber og sælger, eller ved en senere uenighed med en IT-leverandør, er det en fordel, at den udføres af en, der ikke selv har drevet eller sikret miljøet. Hvorfor uvildighed betyder noget her, er beskrevet i uvildig teknisk undersøgelse. Nielco IT har erfaring med incident response og undersøgelser efter hackerangreb og kan efterprøve en assessment eller IR-rapport uvildigt.
Kilder og versioner
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
- MITRE ATT&CK
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Undersøgelse efter et hackerangreb
Læs også: NIST SP 800-61 og bevissikring under incident response · IOC’er i en civil undersøgelse
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
