Krypterede servere og hypervisorer: hvad kan sikres?

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Når ransomware rammer hypervisoren direkte, krypteres de virtuelle maskiners diskfiler på værtens datalager, og alle maskinerne på værten går ned på én gang. Det, der kan sikres, er værtens egne logs og konfiguration, administrationsplatformens hændelser, datalagrets indhold i sin krypterede tilstand og eventuelle snapshots på lagersystemet. Den vigtigste regel er at undgå at genstarte eller geninstallere værten, før logs og konfiguration er hentet, fordi en del af sporene kan ligge i hukommelsen eller på midlertidige områder.

Haster det? Hypervisorens logs ligger ofte på midlertidige områder, der tømmes ved genstart, og en geninstallation af værten fjerner resten. Se akut forensisk sikring; hastesager koster ekstra.

Den generelle metode til sikring af virtuelle maskiner og servere er beskrevet i Virtuelle maskiner og servere. Her handler det om den særlige situation, hvor selve virtualiseringslaget er ramt.

Hvorfor hypervisoren er et mål

Ved at kryptere på hypervisorniveau rammer angriberen mange servere med én handling og uden at skulle omgå sikkerhedsprogrammer inde i de enkelte maskiner. Adgangen opnås typisk via administrationsgrænsefladen med en stjålet administratorkonto, via en integration med Active Directory, hvor en domænegruppe har fået administratorrettigheder, eller via en sårbarhed i hypervisorens tjenester. Det er netop de veje, sikringen skal kunne belyse. Derfor er administrationslagets logs mindst lige så vigtige som de krypterede filer, og de er som regel langt mere skrøbelige, fordi de fylder lidt og roteres hurtigt.

VMware ESXi og vCenter

Værtens logs

ESXi skriver logs for administrationstjenesten, godkendelse, shell-kommandoer og systemhændelser. Relevant er særligt, hvem der loggede ind hvornår og fra hvilken adresse, om SSH eller ESXi Shell blev slået til, hvilke kommandoer der blev kørt i shell, og hvornår virtuelle maskiner blev slukket. De enkelte logfiler er gennemgået i Hostlogs i VMware ESXi, vCenter og Hyper-V.

En væsentlig faldgrube er, at logs på ESXi kan ligge på et midlertidigt område, hvis der ikke er konfigureret vedvarende lager eller central syslog. Det gælder især værter, der starter fra USB- eller SD-medier: Her oprettes der ikke automatisk et vedvarende scratch-område, og logs havner på en RAM-disk. En genstart kan så slette dem. Kontrollér derfor straks, om værten sender logs til en syslog-server, og om der er et vedvarende scratch-område. Hent logs, før værten genstartes, ved at eksportere en supportpakke eller kopiere logmappen, og beregn hashværdier.

vCenter

vCenter registrerer opgaver og hændelser på tværs af værter: logins, ændringer af roller og rettigheder, sletning af snapshots, slukning af maskiner og ændringer i konfiguration. Eksportér hændelser og opgaver for hele perioden, og hent vCenters egne logs. vCenter er ofte koblet til Active Directory, så en del af sporet efter administratorlogins ligger i domænecontrollerens logs. Se Active Directory og domænecontroller-logs.

Hyper-V

På Hyper-V er værten en Windows-server, og sikringen følger i vid udstrækning den almindelige metode for Windows-servere: hændelseslogs, herunder Hyper-V’s egne kanaler for administration og virtuelle maskiner, sikkerhedsloggen, PowerShell-logning og en kopi af systemdisken. Er værten medlem af en klynge, skal klyngens logs og eventuelt System Center-logs med. Når værten selv er Windows, kan angriberens værktøjer også findes som almindelige Windows-artefakter, se Windows-hændelseslogs.

Datalagret og de krypterede diskfiler

De krypterede diskfiler bør bevares uændrede. Det kan være svært, fordi de typisk er meget store, og fordi virksomheden vil genbruge lageret. Mulighederne er:

Bevar datalagret og genopret til et nyt lager. Det er den bedste løsning, hvis kapaciteten findes.
Tag snapshot på lagersystemet (SAN eller NAS), hvis det understøtter det, og dokumentér snapshottets id og tidspunkt.
Kopiér udvalgte diskfiler fra de vigtigste maskiner til separat lager, med hashværdi.

Nogle ransomwarefamilier krypterer kun dele af store filer for at arbejde hurtigere. Det kan betyde, at dele af indholdet i de virtuelle diske kan læses, og at filsystemer inde i maskinerne delvis kan rekonstrueres. Det er en analyseopgave, der forudsætter, at de krypterede filer er bevaret uændret. Forsøg på reparation eller dekryptering skal altid ske på en kopi.

Snapshots og deltafiler

Virtuelle maskiner kan have snapshots med deltafiler, og lagersystemer kan have egne snapshots. Angribere sletter ofte begge for at forhindre genopretning. Dokumentér, hvilke snapshots der fandtes før angrebet, fx ud fra backupsystemets eller lagersystemets logs, og hvornår de blev slettet, og af hvilken konto. Sletning af snapshots er et af de klareste spor efter angriberens handlinger på hypervisorniveau.

Backupsystemet på samme platform

Backupsystemet kører ofte selv som en virtuel maskine på den ramte platform, eller det har adgang til hypervisoren med en servicekonto. Det gør det til en del af både angrebet og sikringen. Kontrollér, om backupserveren er krypteret, om backupkataloger og gendannelsespunkter er slettet, og om servicekontoen er brugt til andet end backup i perioden. Backupsystemets egne job- og auditlogs skal eksporteres, før systemet bruges til genopretning, så det kan dokumenteres, hvornår de sidste gyldige gendannelsespunkter blev lavet, og hvornår de eventuelt forsvandt. Se Backup-logs.

Hukommelse

Kører værten stadig, kan det være relevant at sikre hukommelsen i virtuelle maskiner, der ikke er krypteret endnu, eller i administrationsmaskiner. Selve hypervisorens hukommelse er sjældent praktisk at sikre med almindelige værktøjer. Til gengæld kan virtuelle maskiners hukommelsesfiler og suspenderede tilstande ligge på datalagret og indeholde værdifulde spor. Se Hukommelsessikring.

Rækkefølge i praksis

Afbryd værtens forbindelse til netværket, undtagen den adgang, der skal bruges til sikring, og notér tidspunktet.
Hent logs og konfiguration fra værten og fra vCenter eller klyngestyringen. Hash filerne.
Kontrollér og eksportér central syslog for værten.
Tag snapshot på lagersystemet eller bevar datalagret.
Kopiér prøver af krypterede filer og eventuelle løsesumsbeskeder på værten.
Dokumentér alt i indgrebsloggen, før værten genopsættes.

Typiske fejl

Værten genstartes for at “se, om den kommer op”, og midlertidige logs forsvinder.
Datalagret formateres for at genbruge kapaciteten, før en kopi er taget.
Kun de virtuelle maskiners indhold undersøges, mens værtens og vCenters logs overses.
Logs fra syslog-serveren hentes ikke, fordi det antages, at værten har dem.
Administratorkontoen til hypervisoren nulstilles, før dens loginhistorik er eksporteret.
Lagersystemets egne snapshots ryddes automatisk efter den sædvanlige politik, fordi ingen har sat den i bero.

Dokumentation

For hver vært og for administrationsplatformen bør dokumentationen indeholde version og build, konfiguration af logning og syslog, de hentede logfiler med hashværdi og tidspunkt for hentning, en liste over datalagre med angivelse af, om de er bevaret, kopieret eller overskrevet, og snapshot-id’er fra lagersystemet. Notér også værtens systemtid sammenholdt med en pålidelig tidskilde, fordi hypervisorer i isolerede administrationsnet ofte har ure, der er gået skævt. Uden den afvigelse kan værtens logs ikke lægges korrekt ind i den samlede tidslinje.

Hvad sikringen kan vise

Værtens og administrationsplatformens logs kan typisk vise, hvilken konto der loggede ind på hypervisoren, fra hvilken adresse, hvornår shell-adgang blev slået til, og hvornår maskiner blev slukket og snapshots slettet. Sammen med domænecontrollerens logs kan det ofte føre tilbage til den konto og den maskine, angrebet kom fra. Det er det led, der binder hypervisorangrebet sammen med resten af forløbet, se Ransomware: bevissikring parallelt med genopretning.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Dataudtræk før kryptering: spor efter eksfiltration · Backup-logs: hvornår blev backuppen slettet eller ændret?

→ 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

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik