RDP‑spor: fjernskrivebord i logs, register og bitmap‑cache

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

Fjernskrivebord (RDP) efterlader spor i begge ender af forbindelsen. På den computer eller server, der blev logget ind på, registrerer flere hændelseslogs tidspunkt, konto og kildeadresse for hver session, også når sessionen blot blev afbrudt og genoptaget. På den computer, forbindelsen blev oprettet fra, gemmer registreringsdatabasen de servere, der er forbundet til, og en bitmap-cache kan indeholde brudstykker af det, der blev vist på skærmen. Tilsammen kan sporene ofte vise, hvem der forbandt sig hvorfra og hvornår, men kildeadressen peger ofte på et mellemled, ikke på den egentlige enhed.

Fjernsupportværktøjer fra tredjepart har deres egne logs og er beskrevet set fra virksomhedens side i Fjernsupportværktøjer: hvem var inde på computeren?. Her handler det om Windows’ indbyggede fjernskrivebord.

Spor på serveren (målet)

Security-kanalen. En vellykket RDP-logon registreres som 4624 med logontype 10. Genoptages en afbrudt session, kan det registreres som type 7 eller 10, afhængigt af version, sammen med 4778 (session genoptaget) og 4779 (session afbrudt). Med netværksgodkendelse (NLA) sker selve godkendelsen før sessionen, så mislykkede forsøg ofte vises som 4625 med logontype 3, ikke 10. Fortolkningen af logontyper er gennemgået i Event 4624 og 4625.

TerminalServices-kanalerne. De giver et mere detaljeret sessionsforløb:

LocalSessionManager/Operational · Logon, skal startet, logoff, session afbrudt, session genoptaget
RemoteConnectionManager/Operational · Netværksgodkendelse lykkedes, med konto og kildeadresse
RdpCoreTS/Operational · Forbindelse modtaget, med kildeadresse og port

Microsoft dokumenterer ikke id-numrene i disse kanaler samlet, og offentlige oversigter beskriver flere af dem forskelligt. Læs derfor hændelsens meddelelsestekst og felter på det sikrede system i stedet for at stole på et id-nummer fra en liste. Bemærk også, at en godkendelseshændelse i RemoteConnectionManager ikke alene viser, at en session faktisk blev etableret; det skal bekræftes i LocalSessionManager og Security.

Sessions-id’et går igen på tværs af hændelserne i LocalSessionManager og gør det muligt at følge én session fra logon over afbrydelser og genoptagelser til logoff. Overblikket over kanalerne er i Windows-hændelseslogs.

Mellemled. Bruges en Remote Desktop Gateway, registrerer den selv forbindelserne med den eksterne adresse, mens målserveren kun ser gatewayens adresse. Gatewayens logs skal derfor sikres særskilt. Det samme gælder VPN: Målserveren ser den interne VPN-adresse, og koblingen til den eksterne adresse findes i VPN-loggen; se VPN-logs.

Spor på klienten (afsenderen)

Registreringsdatabasen. I brugerens NTUSER.DAT gemmer fjernskrivebordsklienten en liste over de seneste servere og en nøgle pr. server, ofte med det brugernavn, der blev brugt. Nøglernes LastWrite giver en indikation af seneste forbindelse til hver server.

Filer og programkørsel. En standardforbindelsesfil i brugerens dokumentmappe gemmer indstillingerne for seneste forbindelse. Prefetch for klientprogrammet viser kørsler, og programmets jump list viser seneste forbindelser. Gemte forbindelsesfiler andre steder kan vise planlagte eller gentagne forbindelser.

Klientens hændelseslog. RDPClient/Operational-kanalen registrerer forsøg på at forbinde til en bestemt server og afbrydelser, med tidspunkter.

Bitmap-cachen

For at spare båndbredde gemmer klienten dele af den viste skærm som små billedfliser i en cache i brugerens lokale AppData. Cachen kan efter udtræk sættes sammen til fragmenter af det, brugeren så på den fjerne maskine: vinduer, mapper, dele af dokumenter.

Cachen er nyttig, men skal behandles varsomt:

Den indeholder kun fliser, ikke hele skærmbilleder, og rækkefølgen er ikke nødvendigvis tidsmæssig.
Den overskrives løbende og afspejler typisk kun de seneste sessioner.
Den kan være slået fra i klientens indstillinger.
Den kan indeholde andre personers oplysninger, så adgang og gengivelse skal begrænses; se Dataminimering i forensic.

Fund fra cachen bør beskrives som rekonstruerede fragmenter og helst bekræftes af andre spor.

Uautoriseret eller uventet adgang

I sager om en tidligere medarbejder eller en leverandør, der stadig har adgang, er spørgsmålet ofte, om der har været forbindelser efter en bestemt dato. Tjek:

4624 type 10 og LocalSessionManager-hændelser på alle servere, der er eksponeret for fjernskrivebord,
kildeadresser mod VPN-, gateway- og firewalllogs,
om kontoen er en delt administrator- eller leverandørkonto,
om fjernadgangen er gået via et værktøj fra tredjepart frem for RDP; se IT-leverandørens adgang: RMM-logs. For TeamViewer og AnyDesk, se TeamViewer- og AnyDesk-logs.

Fjernskrivebord åbent mod internettet

Er fjernskrivebord tilgængeligt direkte fra internettet, indeholder loggene ofte et stort antal mislykkede forsøg fra mange adresser. Det er baggrundsstøj, som de fleste eksponerede servere udsættes for, og det beviser ikke i sig selv et målrettet angreb. Det interessante er, om der blandt forsøgene er et vellykket logon, hvilken konto det skete med, og hvad der skete i sessionen bagefter. Mønstrene i loginlogs ved gentagne forsøg er beskrevet nærmere i artiklen om password spray og brute force.

I sager om ransomware eller anden kompromittering er et vellykket RDP-logon fra en ukendt adresse ofte et kandidatspor for indgangsvejen. Konklusionen kræver dog, at forløbet efter logon kan følges: programkørsel, nye konti, ændrede indstillinger og forbindelser videre til andre maskiner.

Forbindelser videre i netværket

En session kan bruges som springbræt til andre maskiner. Det ses som RDP-klientaktivitet på den første server og som nye type 10-logons på de næste, med den første servers interne adresse som kilde. Ved at kæde hændelserne sammen kan bevægelsen gennem netværket rekonstrueres trin for trin. Det kræver, at urene på maskinerne er synkroniserede, eller at afvigelserne er kendt og korrigeret.

Begrænset administratortilstand

Fjernskrivebord kan bruges i en begrænset tilstand, hvor legitimationsoplysningerne ikke overføres til målmaskinen. Det fremgår af et felt i 4624-posten. Tilstanden påvirker, hvilke spor der opstår, og hvilke netværksressourcer sessionen kunne tilgå, og bør derfor noteres, når den forekommer.

Fejlkilder

Kildeadressen er et mellemled. NAT, VPN, gateway og jump-server skjuler den egentlige enhed.
Afbrydelse er ikke logoff. En session, der er afbrudt, kører videre og kan genoptages fra en anden klient.
Overskrevne logs. Security-kanalen på en travl server dækker kort tid; Operational-kanalerne ofte længere.
Arbejdsstationsnavnet oplyses af klienten og kan være forkert eller tomt.
Delte konti gør attribution umulig ud fra logs alene.

Sikring

Sikr Security- og TerminalServices-kanalerne fra målserverne, logs fra gateway, VPN og firewall og, hvis klienten er kendt, en forensisk kopi eller målrettet sikring af brugerprofilen med NTUSER.DAT, forbindelsesfiler og bitmap-cache. Notér logstørrelser og ældste post, fordi RDP-relevante kanaler kan have meget forskellig dækning. Er en server fortsat i drift og udsat for forbindelser, bør logs sikres straks og eventuelt løbende, indtil adgangen er lukket. Lukningen af adgangen, fx ved at fjerne en konto eller ændre firewallregler, skal ske efter sikringen og dokumenteres med tidspunkt, så det senere kan skelnes mellem forbindelser før og efter indgrebet.

Hvad sporene kan og ikke kan bevise

Sporene kan vise, at en konto forbandt sig via fjernskrivebord til en bestemt maskine på bestemte tidspunkter fra en bestemt adresse, og på klientsiden, at en bestemt brugerprofil forbandt sig til en bestemt server. De viser ikke, hvad der blev gjort i sessionen, ud over de fragmenter, cachen kan rumme. Handlinger i sessionen skal findes i artefakterne på målmaskinen, placeret i en samlet tidslinje.

Dokumentation

Angiv for hver session: målmaskine, konto, sessions-id, logon, afbrydelser, genoptagelser og logoff med kilde og EventRecordID, kildeadresse og eventuelle mellemled. For klientsiden angives profil, nøglesti og LastWrite, og for cachen værktøj, version og antal rekonstruerede fragmenter.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: UserAssist, RecentDocs og MRU-lister: brugerens seneste handlinger · PowerShell-historik og scriptlogning som datakilde

→ 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