Autostart, planlagte opgaver og tjenester: spor efter fastholdt adgang

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

Et program, der skal køre igen efter genstart, skal registreres et sted, hvor Windows starter det automatisk: en autostartnøgle i registreringsdatabasen, en startmappe, en tjeneste, en planlagt opgave eller et WMI-abonnement. Det gælder både legitim software og fjernadgangsværktøjer, som en tidligere administrator, en leverandør eller en uvedkommende har efterladt. De samme steder er derfor centrale, når det skal dokumenteres, om nogen har fastholdt en adgang. Hver mekanisme har sine egne tidsstempler og logposter, som kan datere, hvornår posten blev oprettet, og under hvilken konto.

Artiklen beskriver kun, hvordan sådanne poster opdages og dokumenteres i Windows. Gennemgangen af alle adgangsveje efter en administrator, også i cloud og netværk, står i Bagdøre efter en administrator. Sporene efter fjernadgang i private forhold, herunder stalking, er behandlet i Stalkerware og fjernadgang.

Mekanismerne

Autostartnøgler · Hvor: Run- og RunOnce-nøgler i SOFTWARE og NTUSER.DAT · Tidsspor: Nøglens LastWrite
Startmapper · Hvor: Brugerens og den fælles startmappe · Tidsspor: Filens tidsstempler
Tjenester · Hvor: Tjenestenøglerne i SYSTEM-hiven · Tidsspor: LastWrite, installationshændelser
Planlagte opgaver · Hvor: Opgavefiler i Windows’ Tasks-mappe og en cache i registreringsdatabasen · Tidsspor: Oprettelsesdato i opgaven, hændelseslogs
WMI-abonnementer · Hvor: WMI-lageret · Tidsspor: Begrænset; WMI-aktivitetslog
Logon-relaterede værdier · Hvor: Winlogon-nøgler og lignende · Tidsspor: LastWrite

Hertil kommer mekanismer på højere niveau: browserudvidelser, tilføjelsesprogrammer i Office og nye lokale konti med administratorrettigheder. Nye konti er ofte den enkleste form for fastholdt adgang og skal altid kontrolleres.

Tjenester

En tjeneste er registreret med navn, visningsnavn, sti til programfilen, starttype og den konto, den kører under. Installation af en ny tjeneste logges som 7045 i System-kanalen og, hvis revisionen er slået til, som 4697 i Security. Posten angiver programfilens sti og kontoen, der installerede den.

Vær særligt opmærksom på tjenester, hvis programfil ligger i brugermapper eller midlertidige mapper, hvis navn efterligner Windows’ egne tjenester, eller hvis beskrivelsen mangler.

Planlagte opgaver

Hver planlagt opgave er gemt som en XML-fil med handling, udløser, konto og ofte en oprettelsesdato og forfatter. Opgaven er samtidig registreret i registreringsdatabasen. I Security-kanalen registreres oprettelse (4698), sletning (4699), aktivering (4700), deaktivering (4701) og ændring (4702), men kun hvis revisionsunderkategorien for andre objektadgangshændelser er slået til. TaskScheduler/Operational-kanalen kan vise registrering, start og afslutning af opgaver, men er ikke slået til på alle systemer, så det skal kontrolleres, før et fravær tolkes.

Uoverensstemmelser mellem XML-filen og registreringsdatabasen, fx en opgave, der findes det ene sted og ikke det andet, kan pege på, at opgaven er fjernet eller skjult, og bør undersøges nærmere.

WMI-abonnementer

WMI kan sættes op til at køre en handling, når en bestemt hændelse indtræffer, fx ved opstart eller med faste intervaller. Abonnementerne ligger i WMI’s eget lager og vises ikke i de almindelige administrationsværktøjer. Forensiske værktøjer kan parse lageret fra en kopi, og WMI-aktivitetsloggen kan registrere, når et abonnement oprettes. Fund her er sjældne i almindelig drift og bør derfor altid forklares.

Metode: fra liste til vurdering

En computer har typisk mange hundrede autostartposter, langt de fleste legitime. En forsvarlig gennemgang ser sådan ud:

Udtræk alle mekanismer fra en forensisk kopi, ikke fra det kørende system, så resultatet ikke påvirkes af software, der skjuler sig selv.
Hash og kontrollér signatur for hver programfil. Usignerede filer og filer med ukendt udgiver prioriteres.
Sammenlign med en baseline, fx en standardinstallation fra virksomhedens egen opsætning eller tilsvarende maskiner. Afvigelser er interessante.
Datér hver afvigelse med LastWrite, filtidsstempler, opgavens oprettelsesdato og hændelseslogs.
Kobl til programkørsel og identifikation af filen via Amcache og Prefetch; se Prefetch, Amcache og Shimcache.
Kobl til konto og logon, så det fremgår, under hvilken konto posten blev oprettet, og om kontoen var logget på på det tidspunkt.

Nøglerne og deres tidsstempler er beskrevet i Registreringsdatabasen i en undersøgelse, og hændelseslogs i Windows-hændelseslogs.

Typisk situation: efter en fratræden

Når en administrator eller en ekstern IT-leverandør er stoppet, er spørgsmålet ofte, om der er efterladt en vej ind. Ud over autostartmekanismerne kontrolleres:

fjernadgangsværktøjer, installeret som tjeneste eller planlagt opgave,
nye eller genaktiverede lokale konti og medlemskab af administratorgrupper,
VPN-profiler, SSH-nøgler og gemte legitimationsoplysninger til servere,
planlagte opgaver, der kører scripts fra netværksplaceringer eller eksterne adresser.

Den organisatoriske håndtering af mistanke mod en administrator er beskrevet på virksomhedssitet i Mistanke mod IT-administratoren. Den tekniske gennemgang af bagdøre på tværs af systemer og cloud er beskrevet i Bagdøre efter en administrator, og leverandørens adgangsværktøjer i IT-leverandørens adgang: RMM-logs.

Gruppepolitik og centrale værktøjer

I et domæne kan autostartposter, tjenester og planlagte opgaver distribueres centralt via gruppepolitik, softwaredistribution eller et RMM-værktøj. Findes samme afvigende post på mange maskiner, er det et tegn på central distribution, og kilden skal findes på domænecontrolleren eller i administrationsværktøjet. Gruppepolitikobjekter har egne versionsnumre og ændringstidspunkter, og domænecontrollernes logs kan vise, hvilken konto der ændrede dem. En enkelt maskines spor fortæller da kun halvdelen af historien.

Programmets egne spor

Når en mistænkelig post er fundet, er næste skridt programmet selv. Mange fjernadgangsværktøjer har konfigurationsfiler og logfiler med id’er, forbindelsestidspunkter og eventuelt den eksterne parts identitet. Nogle har også en konto hos producenten, hvor forbindelseshistorikken ligger. Den historik kan normalt kun fremskaffes af den, der ejer kontoen, eller efter aftale med producenten, og det bør afklares tidligt.

Sikring før oprydning

Det er fristende at fjerne en mistænkelig tjeneste eller opgave med det samme. Gør det først, når maskinen er sikret, eller sikr som minimum opgavefiler, registreringsdatabasen, programfilen, programmets logs og de relevante hændelseslogs. Afbryd hellere netværksforbindelsen end at slette. Selve fjernelsen skal dokumenteres med tidspunkt og konto, så den ikke senere forveksles med handlinger fra den, der oprettede posten.

Fejlkilder

Legitim software ligner mistænkelig software. Mange fjernsupportværktøjer er lovlige og godkendte. Afgørende er, om installationen var aftalt, og hvem der stod bag.
Tidsstempler kan være fra installationen af en opdatering, ikke fra den oprindelige oprettelse.
Opgavens forfatterfelt kan være sat af den, der oprettede opgaven, og er ikke en pålidelig identifikation.
Fjernede poster efterlader spor i logs, skyggekopier og journaler, men fravær i den aktuelle tilstand betyder ikke, at intet har været der.
Analyse på kørende system kan blive narret af software, der skjuler sig.

Hvad sporene kan og ikke kan bevise

Autostartposter kan vise, at en bestemt mekanisme var sat op til at starte et bestemt program, ofte hvornår og under hvilken konto, og om programmet har kørt. De viser ikke, hvem der faktisk har brugt adgangen. Det kræver programmets egne logs, netværksspor og logs hos eventuelle tjenesteudbydere bag værktøjet. De viser heller ikke i sig selv hensigten bag posten. En planlagt opgave, der kopierer filer til en ekstern adresse hver nat, kan være en glemt backupløsning eller noget andet. Rapporten bør beskrive, hvad posten gør teknisk, og overlade vurderingen af formålet til den samlede sag.

Dokumentation

Angiv for hvert fund: mekanisme, placering, programfil med sti, hashværdi og signatur, konto, alle tidsstempler med kilde, tilknyttede hændelseslogposter og afvigelsen fra baseline. Beskriv også, hvilke mekanismer der er gennemgået uden fund, så omfanget af undersøgelsen fremgår.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: PowerShell-historik og scriptlogning som datakilde · Active Directory og domænecontroller-logs: konti, grupper og nulstillinger

→ 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