Hostlogs i VMware ESXi, vCenter og Hyper‑V

Forside › macOS- og Linux-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når spørgsmålet er, hvem der slettede en virtuel maskine, slukkede en server, fjernede et snapshot eller kopierede en virtuel disk ud af datalagret, ligger svaret ikke i den virtuelle maskine, men i virtualiseringslaget. ESXi-værten, vCenter og Hyper-V-værten logger administrative handlinger med konto, tidspunkt og objekt. Problemet er, at loggene ofte er kortlivede: vCenter gemmer som standard opgaver og hændelser i 30 dage, og ESXi-logs kan ligge på et midlertidigt område, der forsvinder ved genstart.

Sikring af hypervisorer efter et ransomwareangreb er beskrevet i Krypterede servere og hypervisorer, og sikring af selve de virtuelle maskiner i Virtuelle maskiner og servere. Denne artikel handler om at bruge hostloggene til at besvare spørgsmål om administratorhandlinger, fx i en tvist med en IT-leverandør eller en intern undersøgelse af en administrator.

Typiske spørgsmål

Hvem slettede eller afregistrerede en virtuel maskine, og hvornår?
Hvem slukkede eller genstartede en server uden for servicevinduet?
Blev et snapshot oprettet, gendannet eller slettet, og af hvem?
Blev en virtuel disk downloadet via datalagerbrowseren eller kopieret til et andet datalager?
Hvem ændrede rettigheder, roller eller adgang til konsollen?
Blev SSH eller ESXi Shell slået til, og hvilke kommandoer blev kørt?

VMware ESXi

ESXi skriver sine logs i værtens logmappe. Broadcoms aktuelle dokumentation angiver placeringen som /var/run/log, mens ældre dokumentation bruger /var/log. De vigtigste til administratorhandlinger er:

hostd.log: værtens administrationstjeneste med opgaver og hændelser for virtuelle maskiner og værten, forbindelser fra vSphere-klienten og vCenter-agenten og API-forbindelser.
auth.log: godkendelse til ESXi Shell, vellykket og mislykket.
shell.log: aktivering og deaktivering af ESXi Shell og hver indtastet kommando. Broadcom beskriver, hvordan kommandoer kobles til et login via det samme World ID i auth.log og shell.log.
vobd.log: observationshændelser fra VMkernel.
vpxa.log: agenten, der kommunikerer med vCenter.

Når en vært administreres af vCenter, ses mange handlinger i hostd.log som udført af vCenters servicekonto. Den egentlige bruger findes da i vCenter.

vCenter

vCenter registrerer opgaver og hændelser på tværs af alle værter: logins og logouts, oprettelse og sletning af virtuelle maskiner, tænd og sluk, snapshots, migreringer, ændringer i rettigheder og roller og ændringer i konfiguration. Hver post har bruger, objekt, tidspunkt og resultat. Opgaver og hændelser ligger i vCenters database og kan eksporteres fra vSphere-klienten eller via API og PowerCLI.

Opbevaringen styres af indstillingerne for opgave- og hændelsesopbevaring under vCenters databaseindstillinger. Standarden er 30 dage, og Broadcom oplyser, at installationer, der er opgraderet fra versioner før 6.0, kan være sat ned fra 180 til 30 dage ved opgraderingen. Kontrollér den faktiske indstilling, før det konkluderes, at en handling ikke findes.

Ud over databasen har vCenter sine egne logfiler for login, API og tjenester, og vCenter kan sende hændelser til syslog. vCenter er ofte koblet til Active Directory, så domænecontrollerens log kan vise, hvornår en konto blev godkendt; se Active Directory og domænecontroller-logs.

Microsoft Hyper-V

På Hyper-V er værten en Windows-server, og handlinger registreres i Windows’ hændelseslogs. De vigtigste kanaler ligger under Microsoft-Windows-Hyper-V-VMMS (administrationstjenesten, fx oprettelse, sletning, snapshots, kaldet checkpoints, og ændringer i konfiguration) og Microsoft-Windows-Hyper-V-Worker (den enkelte virtuelle maskines arbejdsproces, fx start, stop og fejl). Hvem der udførte handlingen, skal ofte kobles via sikkerhedslogens logons og PowerShell-logningen på værten, fordi handlinger i Hyper-V Manager og PowerShell udføres via administrationstjenesten.

I en failover-klynge findes desuden klyngens egne logs, og i miljøer med System Center Virtual Machine Manager har administrationsserveren sin egen jobhistorik med bruger og tidspunkt.

Eksport af virtuelle diske

Et særligt spørgsmål i fortrolighedssager er, om nogen har hentet en hel virtuel disk. Download via datalagerbrowseren går gennem værtens administrationstjeneste og kan efterlade spor i hostd.log og i vCenter som en filhandling. Kopiering via en backupløsning eller replikering registreres i backupsystemet; se Backup-logs. På Hyper-V er en virtuel disk en almindelig fil på en volumen eller et share, og kopiering ses kun, hvis objektadgang var revideret på filsystemet.

Sikring

Kontrollér straks vCenters opbevaringsindstilling, og eksportér opgaver og hændelser for hele den tilgængelige periode.
Kontrollér, om ESXi-værterne har vedvarende logplacering eller sender til syslog. Hent værtens logs med en supportpakke eller ved kopiering, før værten genstartes.
Hent vCenters logfiler og en oversigt over brugere, roller og rettigheder.
På Hyper-V eksporteres VMMS- og Worker-kanalerne, sikkerhedsloggen og PowerShell-logs som EVTX. Ved klynger hentes klyngens logs fra alle noder.
Hent syslog- eller SIEM-data, hvis loggene er sendt videre.
Hash alt, og notér, hvilke konti der blev brugt til sikringen. Se Logfiler og logrotation.

Undersøges en administrator, bør sikringen ikke udføres med den samme administrators konto, og der bør hentes kopier fra en kilde, administratoren ikke kunne ændre; se Undersøgelse af en administrator.

Fejlkilder

Servicekonti: På værten fremstår handlinger fra vCenter som vCenters konto.
Delte administratorkonti: Mange miljøer bruger en fælles root- eller administratorkonto. Loggen viser kontoen, ikke personen.
Automatisering: Planlagte opgaver, backupsoftware og orkestreringsværktøjer udfører handlinger, der ligner manuelle.
Tidssynkronisering: Værter uden korrekt NTP giver tider, der ikke passer med vCenter og domænecontroller.
Rotation: ESXi-logs roterer efter størrelse, og ældre filer komprimeres eller slettes.

Dokumentation

Rapporten bør indeholde en oversigt over miljøet på sikringstidspunktet: værter, vCenter eller klynge, versioner, tidssynkronisering og logplacering. For hver relevant handling gengives posten fra den primære kilde med tidsstempel, konto, objekt og resultat, og eventuelle bekræftende poster fra andre kilder. Angiv opbevaringsindstillingerne og den periode, eksporten faktisk dækker. Hvis loggene fra en vært er tabt ved genstart, eller vCenters opbevaring var kortere end sagens periode, skal det stå som en begrænsning, så fravær af en post ikke læses som fravær af handling.

Hvad loggene kan og ikke kan bevise

Hostloggene kan vise, hvilken konto der udførte en administrativ handling på en virtuel maskine eller vært, hvornår og med hvilket resultat. De kan vise, at ESXi Shell blev brugt, og hvilke kommandoer der blev kørt. De kan ikke vise, hvad der skete inde i den virtuelle maskine, og de kan ikke alene knytte en delt konto til en person. Koblingen kræver andre spor, fx logins fra bestemte arbejdsstationer.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: macOS- og Linux-forensik

Læs også: Chromebook og ChromeOS i undersøgelser · Mac i virksomheden: MDM-logs og konfigurationsprofiler

→ Forensisk undersøgelse af en computer · For IT-afdelingen · 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