PowerShell‑historik og scriptlogning som datakilde

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

PowerShell bruges dagligt af administratorer og er derfor også et oplagt værktøj, når nogen ændrer konti, eksporterer postkasser, sletter data eller installerer fjernadgang. Sporene efter PowerShell findes fire steder: en tekstfil med brugerens interaktive kommandohistorik, script block logging i hændelsesloggen, modullogning og transskripter. Kun de to første findes typisk uden særlig opsætning, og historikfilen har ingen tidsstempler. Hvad der kan dokumenteres, afhænger derfor næsten helt af, hvad der var slået til, før hændelsen skete.

Overblikket over Windows’ logkanaler findes i Windows-hændelseslogs. Her gennemgås PowerShell-kilderne.

Konsolhistorikken

Den moderne PowerShell-konsol bruger modulet PSReadLine, der gemmer brugerens interaktivt tastede kommandoer i en tekstfil i brugerens roaming-profil, under AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine. Filen hedder efter værtsprogrammet, fx ConsoleHost_history.txt for den almindelige konsol. Den har én kommando pr. linje og et konfigurerbart loft over antal poster, så de ældste fjernes. PSReadLine udelader som standard kommandolinjer, der ligner følsomme oplysninger, fx med ord som password, token, apikey eller secret, og reglerne er justeret mellem versioner. Fravær af en bestemt kommando i filen er derfor ikke et bevis for, at den ikke blev tastet.

Det skal man vide om historikfilen:

Ingen tidsstempler pr. linje. Kun filens egne tidsstempler i filsystemet viser, hvornår den sidst blev ændret.
Kun interaktive kommandoer. Scripts, der køres, og kommandoer sendt via fjernstyring, registreres ikke her.
Pr. bruger og pr. vært. Hver konto og hver konsoltype kan have sin egen fil.
Kan redigeres eller slettes af brugeren selv.

Rækkefølgen af linjerne er bevaret, så det kan ofte ses, hvilke kommandoer der kom før og efter hinanden. Tidsfæstelse må ske ved at sammenholde med andre kilder, fx ændringsjournalen for filen eller hændelseslogs for de handlinger, kommandoerne udførte.

Script block logging

Script block logging registrerer indholdet af de kodeblokke, PowerShell udfører, i Operational-kanalen for PowerShell som hændelse 4104. Det gælder også kode, der var skjult eller kodet, da den blev sendt, fordi blokken logges, efter at PowerShell har afkodet den. Det gør script block logging til en af de stærkeste kilder til at vise, hvad der faktisk blev kørt.

Funktionen er ikke slået fuldt til som standard og aktiveres via gruppepolitik eller registreringsdatabasen. Windows PowerShell 5.1 kan desuden logge visse blokke, som motoren vurderer som mistænkelige, som advarsler, selvom fuld logning ikke er aktiveret. Om det sker, afhænger af version og konfiguration, så et fund eller fravær af sådanne advarsler skal ses i lyset af de aflæste indstillinger. Store blokke deles op i flere hændelser, der skal sættes sammen via et fælles id.

Modullogning og den klassiske PowerShell-log

Modullogning registrerer pipeline-udførelse for udvalgte moduler, herunder parametre, som hændelse 4103 i Operational-kanalen og som hændelse 800 i den klassiske Windows PowerShell-log. Den skal slås til via politik.

Den klassiske log registrerer desuden, når PowerShell-motoren startes og stoppes, med oplysninger om værtsprogrammet og motorversionen. Det kan vise, at PowerShell blev startet på et bestemt tidspunkt, fra hvilket program og med hvilken kommandolinje. Start af en ældre motorversion, der ikke understøtter den nyere logning, er i sig selv et relevant fund, der bør noteres.

Transskripter

Transskription gemmer hele sessioner, både kommandoer og output, som tekstfiler i en konfigureret mappe. Hver fil har en overskrift med bruger, computer, tidspunkt og værtsprogram. Transskripter er yderst værdifulde, men findes kun, hvis de er slået til via politik, og de bør ligge i en mappe, som brugerne ikke selv kan ændre.

PowerShell 7 og andre værter

PowerShell 7 installeres ved siden af den indbyggede Windows PowerShell og har sin egen logkanal, PowerShellCore/Operational, og egne politikindstillinger. Kanalen findes først, når hændelsesudbyderen er registreret på maskinen. Er kun den ene version konfigureret til logning, kan aktivitet i den anden være uregistreret. Andre værter, fx automatiseringsværktøjer og administrationskonsoller, kører også PowerShell-kode og kan efterlade spor i de samme kanaler, men med et andet værtsprogram.

Samlet overblik

Konsolhistorik · Standard: Typisk aktiv · Tidsstempel: Nej, kun filens · Viser: Interaktive kommandoer i rækkefølge
Script block logging (4104) · Standard: Delvis · Tidsstempel: Ja · Viser: Den udførte kode
Modullogning (4103/800) · Standard: Nej · Tidsstempel: Ja · Viser: Pipeline og parametre
Motorstart (klassisk log) · Standard: Ja · Tidsstempel: Ja · Viser: Start, værtsprogram, version
Transskripter · Standard: Nej · Tidsstempel: Ja · Viser: Hele sessionen med output
Procesoprettelse (4688) · Standard: Nej · Tidsstempel: Ja · Viser: Kommandolinjen ved start

Supplerende kilder

Ud over PowerShells egne kilder kan procesoprettelse med kommandolinje i sikkerhedsloggen, Prefetch for PowerShell-programmerne og EDR-telemetri vise, hvornår og hvordan PowerShell blev startet. EDR-løsninger registrerer ofte kommandolinjer og scriptindhold uafhængigt af Windows’ egne indstillinger og opbevarer dem centralt; se EDR-telemetri som bevis. Programkørsel generelt er beskrevet i Prefetch, Amcache og Shimcache.

Sikring

Sikr PowerShells Operational-kanal, den klassiske Windows PowerShell-log og eventuelt PowerShell 7’s kanal som EVTX; se Eksport af Windows-hændelseslogs. Sikr historikfiler for alle relevante brugerprofiler og transskriptmappen, hvis den findes. Aflæs og dokumentér de gældende politikindstillinger for logning og transskription, så det kan vises, hvad der kunne være registreret.

Script block-logs kan indeholde følsomme oplysninger som adgangskoder i klartekst, hvis de har indgået i scripts. Det skal håndteres i overensstemmelse med sagens afgrænsning og ikke gengives i rapporten.

Fjernstyring og cloudadministration

Meget administration sker i dag ikke på den lokale maskine, men via fjernstyring eller mod cloudtjenester. Kommandoer sendt via PowerShell-fjernstyring udføres på målmaskinen og logges dér, hvis logningen er slået til, mens afsenderen kun har sin egen konsolhistorik. Administration af Microsoft 365 og Entra ID via PowerShell-moduler registreres derimod i tjenestens egne auditlogs, hvor handlingen står som udført af kontoen, ofte med en angivelse af, at den kom fra et script eller en API-klient. Spørgsmålet om, hvem der eksporterede en postkasse eller ændrede en rolle, skal derfor ofte besvares i cloudloggen, med PowerShell-historikken på administratorens computer som supplement.

Rekonstruktion af et forløb

Et forløb kan ofte stykkes sammen sådan: motorstart i den klassiske log viser, hvornår og fra hvilket program PowerShell blev startet; script block-hændelserne viser koden i rækkefølge; historikfilen bekræfter de interaktive kommandoer; og systemets øvrige logs viser virkningen. Hvert led skal kunne henvises til en konkret post.

Fejlkilder

Fravær tolkes som uskyld. Uden logning er der intet at finde, og historikken dækker kun interaktiv brug.
Automatik forveksles med personer. Administrationssoftware, overvågningsagenter og planlagte opgaver kører store mængder PowerShell.
Historik uden tid. Linjerne i historikfilen kan ikke dateres alene.
Delte administratorkonti. En kommando under en delt konto kan ikke tilskrives en bestemt person uden andre spor.
Opdelte blokke. En stor scriptblok, der kun er delvist sikret, kan give et misvisende billede.

Når den undersøgte selv er administrator

Er den person, sagen handler om, administrator, kan lokale logs og historikfiler være ændret eller ryddet. Centrale logs i et SIEM eller hos en EDR-leverandør er da afgørende; se Undersøgelse af en administrator, der kan slette loggen. Hvad virksomheden bør have slået til på forhånd, er beskrevet set fra ledelsens side i Minimumslogning.

Hvad sporene kan og ikke kan bevise

PowerShell-sporene kan vise, hvilken kode der blev udført, under hvilken konto, på hvilken maskine og hvornår. De viser ikke i sig selv, om koden lykkedes, eller hvad resultatet var, medmindre et transskript eller systemets øvrige spor viser det. Kobl derfor altid kommandoerne til deres virkning: en ny konto, en ændret indstilling, en eksportfil.

Dokumentation

Angiv for hvert fund: kilde og kanal, maskine, konto, tidspunkt, hændelses-id og EventRecordID eller filsti og linjenummer, værtsprogram og motorversion, gældende logindstillinger og den afledte virkning af kommandoen.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: RDP-spor: fjernskrivebord i logs, register og bitmap-cache · Autostart, planlagte opgaver og tjenester: spor efter fastholdt adgang

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