Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Når et forsikringsselskab eller en virksomhed vil rejse krav mod en IT-leverandør efter et angreb, er det tekniske spørgsmål ikke, om leverandøren gjorde noget forkert i almindelighed. Det er, om en bestemt opgave, leverandøren havde, blev udført, og om den havde betydning for indgangen, spredningen eller genopretningen. Svaret kræver tre ting: en ansvarsmatrix, der kobler aftalen til konkrete kontroller, data for hver kontrol fra perioden før angrebet, og en kobling mellem de konkrete mangler og angrebets forløb.
Den juridiske side af regreskravet er beskrevet på digital-bevissikring.dk, og leverandørens egen situation på bevissikring-digitalt.dk i Kunden giver jer skylden. Her er det metoden.
Fra aftale til kontroller
Aftaler beskriver ydelser, ikke kontroller. “Drift af servere” eller “sikkerhedsovervågning” skal oversættes til noget, der kan måles. Byg en matrix med én linje pr. kontrol:
- Sikkerhedsopdateringer på servere · Ansvarlig ifølge aftalen: Leverandør · Datakilde: Opdateringshistorik, RMM-rapporter
- MFA på fjernadgang · Ansvarlig ifølge aftalen: Uklart eller kunde · Datakilde: Konfiguration og loginlogs
- Backup adskilt fra produktion · Ansvarlig ifølge aftalen: Leverandør · Datakilde: Backupjob, lagerplacering, rettigheder
- Gendannelsestest · Ansvarlig ifølge aftalen: Leverandør · Datakilde: Testlogs, tickets
- Overvågning og alarmhåndtering · Ansvarlig ifølge aftalen: Leverandør · Datakilde: Alarmhistorik, tickets
Kolonnen for ansvar udfyldes af juristerne ud fra aftalen og dens til- og fravalg. Den tekniske undersøger udfylder de to andre og markerer, hvor ansvaret er uklart. Det er ofte i de uklare linjer, tvisten ender.
Leverandørens adgangsveje
En leverandør med administrativ adgang er både en mulig forsvarer og en mulig indgangsvej. Kortlæg alle adgangsveje leverandøren havde:
- RMM-værktøjet: agenter på kundens maskiner, leverandørens konsol og dens brugerkonti. Se MSP-adgang og RMM-logs.
- Partneradgang til Microsoft 365: delegerede administratorrettigheder via Partner Center. Med GDAP kan adgangen være tidsbegrænset og begrænset til bestemte roller, men ældre partnerrelationer kan have givet bredere rettigheder.
- Navngivne konti i kundens domæne, som leverandørens teknikere brugte, og fælles konti uden navn.
- VPN eller fjernskrivebord med leverandørens egne forbindelser.
For hver adgangsvej dokumenteres: hvem havde den, hvornår blev den brugt i perioden, og blev den brugt af angriberen. Viser data, at angriberen kom ind via leverandørens værktøj eller konto, ændrer det sagen væsentligt. Viser data det modsatte, er det lige så vigtigt at dokumentere. Hvis samme leverandør er ramt hos flere kunder, se hændelse hos flere kunder.
Data for perioden før angrebet
Den afgørende periode er tiden før angrebet, og det er den, der først forsvinder. Prioritér:
- Opdateringsstatus pr. system med datoer for installation og frigivelse af de relevante opdateringer. Kilder kan være Windows-opdateringshistorikken, RMM-rapporter og CBS-logs.
- Backupjob med status, mål og opbevaring, og rettigheder på backuplageret. Se backuplogs ved sletning.
- Alarmer fra EDR og overvågning med tidspunkt for oprettelse, kvittering og lukning. Se EDR-telemetri som bevis.
- Tickets og rapporter, især anbefalinger fra leverandøren og kundens svar. Se ticketsystemers ændringshistorik.
Mange af kilderne ligger i leverandørens systemer. Sikringen bør ske med leverandørens deltagelse eller i det mindste med en beskrivelse, leverandøren har fået mulighed for at kommentere. Ellers vil leverandøren med rette spørge, hvad der er udvalgt.
Politik eller effekt
En RMM-rapport, der viser “opdateringspolitik aktiv”, er ikke bevis for, at opdateringerne blev installeret. Ligesom ved forsikringstvister om sikkerhedsniveauet skal konfigurationen og effekten holdes adskilt. Konfigurationen viser, hvad leverandøren havde sat op. Effekten viser, hvad der faktisk skete på de enkelte maskiner: installationsdatoer, fejlede installationer, maskiner uden agent eller uden for politikken. Det er ofte i undtagelserne, angriberen fandt vejen ind, og det er dem, en modpart vil gå efter. Se sikkerhedsniveauet før hændelsen.
Det samme gælder backup. Et backupjob med status “gennemført” siger ikke, om backuplageret var adskilt fra produktionsmiljøet, om angriberen havde rettigheder til det, eller om en gendannelse ville have virket. Rettigheder på lageret, netværksadgang til det og resultatet af tidligere gendannelsestest skal dokumenteres for sig.
Tidspunkter og frister
Mange aftaler fastsætter frister, fx for installation af kritiske opdateringer efter frigivelse eller for reaktion på en alarm. Dokumentér for hver relevant kontrol tre tidspunkter: hvornår leverandøren kunne have handlet (opdateringen blev frigivet, alarmen blev oprettet), hvornår leverandøren handlede, og hvornår angriberen brugte forholdet. Først når de tre tidspunkter står ved siden af hinanden, kan det vurderes, om en forsinkelse havde betydning. Tidspunkterne skal normaliseres til samme tidszone og hentes fra kilder, der ikke er ændret efter hændelsen.
Fase for fase
Kobl derefter manglerne til forløbet. Del angrebet op:
- Indgang. Brugte angriberen en vej, hvor en kontrol i leverandørens kolonne manglede? Evidensniveauet for indgangsvejen skal angives, fx påvist, sandsynlig eller mulig. Se indgangsvejen: sådan underbygges konklusionen.
- Spredning. Kom der alarmer, der ikke blev håndteret, og hvor lang tid gik der mellem alarm og reaktion? Kunne adskillelse, som leverandøren skulle opretholde, have begrænset bevægelsen?
- Genopretning. Var der en brugbar backup, og hvor langt var den fra den aftalte? Hvor meget af genopretningstiden skyldes backupens tilstand? Se driftstab og genopretningstid.
En mangel i én fase siger ikke noget om de andre. En leverandør, der ikke testede gendannelse, er ikke dermed årsag til indgangen. Den tekniske rapport bør holde faserne adskilt, så juristerne kan vurdere dem hver for sig.
Kontrafaktiske spørgsmål
Regressager rummer næsten altid spørgsmålet: Hvad ville der være sket, hvis kontrollen havde været på plads? Det kan teknisk kun besvares delvist. Undersøgeren kan vise, at angriberen brugte en bestemt sårbarhed, og at opdateringen, der lukkede den, var frigivet på et bestemt tidspunkt. Undersøgeren kan sjældent vise, at angriberen ikke ville have fundet en anden vej. Skriv det præcist: hvad data viser, hvad der er en teknisk vurdering, og hvad der ikke kan siges.
Det samme gælder genopretningen. Var backuppen brugbar, kan det ofte beregnes ud fra datamængde og gendannelseshastighed, hvor lang tid en gendannelse ville have taget. Beregningen skal angive sine forudsætninger, fx hvilken backup der ville have været til rådighed, og hvilken hastighed miljøet faktisk opnåede ved andre gendannelser. En kontrafaktisk varighed uden forudsætninger kan ikke efterprøves.
Typiske fejl
- Matrixen bygges ud fra aftalens overskrifter i stedet for konkrete kontroller.
- Leverandørens egne adgangsveje undersøges ikke som mulig indgang.
- Data fra perioden før angrebet sikres først, når leverandøren er udskiftet.
- Mangler i genopretningen bruges som argument for ansvar for indgangen.
- Rapporten konkluderer ansvar i stedet for at beskrive udførelse og betydning.
Hvad dokumentationen kan og ikke kan bevise
Dokumentationen kan vise, hvilke kontroller der var på plads på et givet tidspunkt, hvilke adgangsveje angriberen brugte, og hvordan backup og overvågning fungerede. Den kan ikke afgøre aftalens fortolkning eller fordele tabet. Den skadesundersøgelse, kravet ofte bygger på, er beskrevet i skadesundersøgelse for forsikringsselskabet.
Kilder og versioner
- Microsoft Learn: introduktion til GDAP
- NIST SP 800-61 Rev. 3: incident response
- CIS Critical Security Controls v8.1
Senest gennemgået: oktober 2026.
Næste skridt
- Dataudtræk før kryptering: spor efter eksfiltration
- Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om
- Persondatabrud på 72 timer: de tekniske fakta, der skal være fastlagt
Del af: Undersøgelse efter et hackerangreb
Læs også: Skadesundersøgelse for forsikringsselskabet: årsag, tidslinje og omfang · Driftstab og genopretningstid: tekniske data til tabsopgørelsen
→ 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