Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Når backuppen ikke kan bruges efter en hændelse, er det afgørende for både forsikringssagen og en tvist med IT-leverandøren at vide hvorfor. Der er tre grundlæggende forklaringer: backuppen blev aktivt slettet eller ændret, den udløb efter den gældende opbevaringspolitik, eller den blev aldrig taget korrekt. Backupsystemets egne logs kan i de fleste tilfælde skelne mellem de tre, hvis de sikres, før systemet bruges til genopretning eller geninstalleres.
Haster det? Så snart genopretningen går i gang, skriver backupsystemet nye poster og kan ændre kataloget, og en geninstallation af backupserveren fjerner loggene helt. Se akut forensisk sikring; hastesager koster ekstra.
Hvad virksomheden selv skal dokumentere om aftaler, advarsler og tab, er beskrevet i Backuppen virkede ikke. Her handler det om de tekniske kilder. Skal en tidligere tilstand hentes frem fra backuppen, følges Gendannelse fra backup til forensisk brug.
Fire lag af logs
Et backupsystem har typisk logs i flere lag, og hvert lag svarer på sit eget spørgsmål.
- Jobhistorik · Kørte backuppen, og lykkedes den?
- Audit- eller hændelseslog · Hvem ændrede politikker, slettede punkter eller loggede ind?
- Kataloget · Hvilke gendannelsespunkter fandtes, og hvornår udløb de?
- Lagerets egne logs · Hvad skete der med data på disken, båndet eller i cloud?
Jobhistorikken viser for hvert job start, slut, status, datamængde og eventuelle advarsler. Auditloggen viser administrative handlinger: logins i konsollen, ændring af opbevaringstid, deaktivering af job, sletning af gendannelsespunkter og ændringer af krypteringsnøgler. Kataloget er backupsystemets egen oversigt over, hvilke data der findes hvor. Lageret, fx en NAS, et objektlager eller en cloudtjeneste, har sine egne logs over sletninger og adgang.
Navne og placering varierer meget mellem produkter. Det vigtige er at finde de fire lag i det konkrete produkt og eksportere dem alle.
Sletning, udløb eller aldrig taget?
Aktiv sletning
Spor: poster i auditloggen om sletning af gendannelsespunkter eller job, ofte kort før krypteringen, udført af en bestemt konto fra en bestemt adresse. Ændring af opbevaringstid til et meget kort interval efterfulgt af en oprydningskørsel er en variant, der kan ligne almindeligt udløb, men som afsløres af ændringen i politikken. På lagerniveau ses mange sletninger på kort tid. Ved cloudbaseret lager kan sletningerne findes i udbyderens adgangslogs, se Objektlager: adgangslogs og versionering.
Udløb efter politikken
Spor: oprydningskørsler, der sletter punkter i overensstemmelse med den opbevaringstid, der var gældende. Her skal politikken dokumenteres, som den var på tidspunktet. Er den ændret undervejs, skal ændringen og dens tidspunkt fremgå af auditloggen. Udløb efter politikken er ikke et angreb, men det kan være et spørgsmål om, hvorvidt politikken var tilstrækkelig.
Aldrig taget eller ufuldstændig
Spor: job med fejl eller advarsler over en længere periode, job, der kørte, men med en datamængde, der er påfaldende lille, servere, der aldrig var med i et job, og manglende testgendannelser. Jobhistorikken viser det direkte, hvis den er bevaret længe nok. Advarselsmails og overvågningsalarmer viser, hvem der fik besked.
Testgendannelser og verifikation
Mange backupsystemer kan verificere backuppen efter hvert job, fx ved at kontrollere checksummer eller ved at starte en gendannet maskine i et isoleret miljø og tjekke, at den svarer. Hvis det var slået til, giver loggen over verifikationerne et stærkt billede af, om backuppen faktisk var brugbar på et givent tidspunkt. Hvis det ikke var slået til, er det i sig selv en oplysning, der kan få betydning.
Manuelle testgendannelser dokumenteres sjældent i backupsystemet selv, men ofte i tickets, driftsrapporter eller mails. Find dem, og notér, hvad der blev testet: en enkelt fil, en hel server eller et helt miljø. En vellykket gendannelse af en enkelt fil siger ikke meget om, hvorvidt en hel server kunne gendannes.
Uforanderligt lager
Mange backupløsninger kan skrive til uforanderligt lager, hvor data ikke kan slettes før en bestemt dato, fx via objektlås i cloud eller en hærdet lagerserver. Hvis det var konfigureret, skal det dokumenteres, hvordan: Var låsen i en tilstand, hvor en administrator kunne ophæve den, eller i en tilstand, hvor ingen kunne? I Amazon S3 hedder de to tilstande governance og compliance: Den første kan omgås af konti med en særlig rettighed, den anden kan ikke ophæves af nogen, heller ikke kontoens rodbruger. I Azure Blob Storage svarer det til en ulåst og en låst opbevaringspolitik. Hvis backuppen alligevel forsvandt, er spørgsmålet, om låsen faktisk var aktiv for de relevante data, om opbevaringstiden var kortere end antaget, eller om lagerets administrative konto var kompromitteret. Lagerets egen konfiguration og log er den eneste pålidelige kilde.
Hvem havde adgang?
Backupkonsollen administreres ofte af en IT-leverandør. Konsollens login-log og auditlog viser, hvilke konti der var aktive, og leverandørens egne fjernadgangsværktøjer kan vise, hvem der sad bag. Se IT-leverandørens adgang: RMM-logs. Er backupsystemet koblet til Active Directory, kan en kompromitteret domæneadministrator have haft adgang, og så er domænecontrollerens logs en del af kæden.
Sikring
- Eksportér jobhistorik, auditlog og katalog fra backupsystemet, før det bruges til genopretning. Genopretning skriver nye poster og kan ændre kataloget.
- Gem konfigurationen: job, politikker, opbevaringstider, mål og konti.
- Hent lagerets egne logs, herunder fra cloudtjenesten, hvis den bruges.
- Sikr advarselsmails og rapporter fra modtagernes postkasser og fra overvågningssystemet.
- Notér backupserverens systemtid mod en pålidelig tidskilde.
- Beregn hashværdier af alle eksporter, og registrér dem i bevisloggen.
Backupsystemets interne database kan indeholde mere historik end det, konsollen viser. I så fald kan en kopi af databasen være relevant, men det kræver kendskab til produktet og skal dokumenteres særskilt.
Faldgruber i fortolkningen
- Logs med kort historik. Mange produkter beholder kun jobhistorik i en begrænset periode. Det, der ikke findes, kan ikke tolkes som “ingen fejl”.
- Status “lykkedes” er ikke det samme som brugbar. Et job kan lykkes med at tage backup af en tom eller allerede krypteret mappe.
- Tidszoner. Konsollen kan vise lokal tid, mens eksporten bruger UTC.
- Automatiske oprydninger efter angrebet. Hvis backupsystemet kører videre efter angrebet, kan det udløbe gendannelsespunkter, mens sagen står på. Sæt oprydning i bero, og dokumentér, at det er gjort.
- Logs på det samme system, som angriberen kontrollerede. En angriber med administratoradgang til backupkonsollen kan også have ændret dens log. Sammenhold med uafhængige kilder, se Logintegritet.
Hvad logs kan og ikke kan vise
Logs kan som regel vise, hvornår gendannelsespunkter forsvandt, om det skete ved en administrativ handling eller en planlagt oprydning, og hvilken konto der udførte handlingen. De kan vise, om job fejlede over tid, og om nogen fik advarsler. De kan ikke i sig selv vise, hvem der havde ansvaret for at reagere på advarslerne, eller om opbevaringstiden var aftalt. Det står i aftalegrundlaget. Hvordan sikkerhedsniveauet før hændelsen dokumenteres samlet, er beskrevet i Forsikringstvist: sikkerhedsniveauet før hændelsen.
Dokumentation
Rapporten bør indeholde en tidslinje over gendannelsespunkterne i den relevante periode: hvornår de blev skabt, hvornår de forsvandt, og hvorfor. Ved hver forsvinding angives kilden, fx en bestemt post i auditloggen eller en oprydningskørsel efter en navngiven politik. Herudover en oversigt over politikker og deres ændringer med tidspunkt og konto, og en liste over advarsler med modtagere. Angiv tydeligt de perioder, hvor logs manglede. Er der gennemført gendannelse til forensisk brug, beskrives metoden for sig, se Gendannelse fra backup til forensisk brug.
Kilder og versioner
- AWS: S3 Object Lock, governance og compliance
- Microsoft Learn: uforanderligt lager i Azure Blob Storage
- NIST SP 800-209: sikkerhedsretningslinjer for lagerinfrastruktur
Senest gennemgået: oktober 2026.
Næste skridt
- Hvilke persondata blev berørt? Teknisk afgrænsning af et databrud
- NIS2: varsling og rapporter set fra logkilderne
- Overdragelse fra IR-team til sagkyndig
Del af: Undersøgelse efter et hackerangreb
Læs også: Krypterede servere og hypervisorer: hvad kan sikres? · Dwell time: hvornår kom angriberen ind?
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For MSP’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
