IT‑leverandørens adgang: RMM‑logs og leverandørens egne konti

Forside › Undersøgelse ved fratræden · Gennemgået oktober 2026 · Af John Nielsen

Når en IT-leverandør har haft adgang til kundens systemer, findes svaret på “hvem var logget på, og hvad blev gjort?” sjældent ét sted. Det ligger fordelt mellem RMM-platformens centrale auditlog, agentens lokale logs på de administrerede maskiner, kundens egne login- og auditlogs og de konti, leverandøren har oprettet eller fået delegeret. Den centrale log ligger typisk hos leverandøren, mens kundens egne logs ligger hos kunden, og det er krydsningen mellem dem, der gør dokumentationen robust.

Haster det? Agentens lokale logs har ofte en fast størrelse og overskrives, og konsollens auditlog gemmes kun i en periode, der afhænger af abonnementet. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen beskriver de tekniske kilder og deres faldgruber. Den praktiske side for virksomheden, herunder hvordan loggen bedes udleveret, står på Fjernsupportværktøjer: hvem var inde på computeren?. Gælder mistanken en intern administrator, står metoden i Undersøgelse af en administrator, der kan slette loggen.

Hvad et RMM-værktøj registrerer

RMM (remote monitoring and management) er mere end fjernskrivebord. En typisk platform kan køre scripts, installere software, åbne en fjernkommandoprompt, overføre filer, ændre politikker og hente inventar fra hundredvis af maskiner på én gang. Det betyder, at mange handlinger aldrig ses som en interaktiv session.

Den centrale konsol logger normalt:

teknikerens login i konsollen, med konto, tidspunkt, IP-adresse og eventuelt totrinsmetode,
sessioner til enkelte endpoints: start, slut, type (skærm, kommandoprompt, filoverførsel),
automatiseringer: hvilke scripts eller jobs der blev kørt mod hvilke maskiner, af hvem og med hvilket resultat,
ændringer i politikker, grupper, brugere og rettigheder i konsollen.

Hvilke felter der findes, hvor længe de gemmes, og om script-output gemmes, varierer meget mellem produkter og abonnementer, og leverandørerne ændrer det løbende. Spørg derfor først, hvilken platform og version der er brugt, og hent leverandørens dokumentation for auditloggen, før eksporten læses.

Agentens spor på endpointet

RMM-agenten kører som en tjeneste med høje rettigheder. På Windows efterlader den typisk:

en installeret tjeneste, hvis oprettelse kan ses i systemloggen (fx Event ID 7045) og i registreringsdatabasen,
egne logfiler i programmappen eller under C:\ProgramData, ofte med lokale tidsstempler for sessioner og jobs,
midlertidige scripts, der skrives til disk, køres og slettes, så de kun ses i filsystemets journal eller i EDR-telemetri,
processer, der starter som underproces af agenten, fx PowerShell eller cmd.

Det sidste punkt er vigtigt: En kommando, der køres via RMM, står i Windows’ logs som udført af systemkontoen eller tjenestekontoen, ikke af teknikeren. Koblingen til en bestemt tekniker findes kun i konsollens auditlog. Uden den kan du vise, at agenten kørte en kommando, men ikke hvem der satte den i gang. PowerShell-logning kan bevare selve scriptindholdet, hvis den var slået til. → PowerShell-historik og scriptlogning

Leverandørens egne konti

Ud over RMM har leverandøren ofte en eller flere af disse adgange:

Domæneadministrator eller lokal admin · Logon-hændelser, gruppemedlemskaber i AD
Navngivne eller fælles teknikerkonti · Loginlogs; fælles konti kan ikke føres til en person
Delegeret administration i Microsoft 365 · Partnerrelation og rolletildelinger i Entra ID
VPN eller fjernskrivebord · VPN-sessioner, RDP-hændelser
Tjenestekonti til backup og overvågning · Ikke-interaktive logins, ofte døgnet rundt

Delegeret administration fra en partner fremgår af kundens tenant som en partnerrelation med tildelte roller, og handlinger kan i auditloggen stå med partnerens identitet frem for en konto i kundens egen katalog. I kundens Entra-loginlog kan partnerens logins genkendes på feltet for adgang på tværs af tenants, der står som serviceProvider, og på at brugerens hjemmetenant er en anden end kundens. Dokumentér relationen, rollerne og hvornår de blev givet og fjernet. → Privilegerede roller: tildelinger og ændringshistorik

Fælles teknikerkonti er den største svaghed. Hvis fem teknikere deler én konto, kan loggen vise, at kontoen gjorde noget, men ikke hvem af de fem. Det skal stå som en begrænsning, ikke udfyldes med antagelser.

Sikring i den rigtige rækkefølge

Kortlæg adgangene. Lav en liste over RMM-platforme, fjernværktøjer, konti, partnerrelationer og tjenestekonti med de rettigheder, de har.
Bed leverandøren om eksport af konsollens auditlog og sessionslog for en klar periode, i det rå format platformen leverer (CSV eller JSON), med oplysning om, hvem der eksporterede, hvordan og hvornår. Bed om hashværdi af filen ved udlevering.
Sikr kundens egne logs uafhængigt: Entra-loginlogs, auditlog, domænecontrollerens sikkerhedslog, firewall- og VPN-logs.
Sikr agentens lokale logs og relevante Windows-logs på de berørte maskiner, helst med en forensisk metode, før agenten opdateres eller afinstalleres.
Ændr adgange bagefter og notér tidspunktet, så det fremgår, hvad der skete før og efter.

Er det leverandøren selv, sagen handler om, bør leverandøren ikke stå for sikringen af kundens logs. Leverandøren må gerne levere sin egen konsollog, men den bør krydstjekkes mod kilder, leverandøren ikke har kontrol over. → Undersøgelse af en administrator, der kan slette loggen

Krydsvalidering

Konsollens log er leverandørens egen. Den bliver stærkere, når den stemmer med uafhængige kilder:

En session i konsollen bør modsvares af en udgående forbindelse fra agenten i firewall-loggen og af aktivitet i EDR-telemetrien på samme tidspunkt.
Et script, der står som kørt, bør kunne ses som en proces under agenten og eventuelt i PowerShell-loggen.
Et login i konsollen bør komme fra en IP-adresse, der passer med leverandørens netværk eller en kendt tekniker.

Uoverensstemmelser er ikke i sig selv tegn på manipulation. Konsollens tid kan være i UTC, agentens i lokal tid, og nogle platforme sender hændelser forsinket. Normalisér tidszoner, før du sammenligner. → Logkorrelation

Når leverandørens adgang er misbrugt udefra

Et RMM-værktøj er en attraktiv vej ind, fordi én kompromitteret teknikerkonto giver adgang til mange kunder. Spørgsmålet i tvisten er så ofte, om leverandørens konto blev brugt af en uvedkommende. Se efter konsollogins fra adresser og klienter, der ikke passer med leverandørens kendte mønster, nye API-tokens eller integrationer, ændringer af teknikerkontoens totrinsmetode og jobs, der rammer mange kunder på kort tid. Leverandøren bør selv sikre konsollens auditlog og sin identitetsudbyders loginlog for teknikerkontoen. Kunden bør parallelt sikre sine egne kilder, fordi leverandørens forklaring og kundens data skal kunne holdes op mod hinanden.

Typiske fejlkilder

Automatik ligner menneskelig handling. Planlagte jobs, patch-politikker og overvågningstjek kører uden tekniker og kan forveksles med en session.
Åbne sessioner er ikke arbejde. En session kan stå åben i timer uden aktivitet. Varighed er ikke det samme som brugt tid.
Tekniker-id er ikke en person. Kontoen kan være delt, og et API-token kan bruges af en integration.
Lokale logs roterer. Agentlogs har ofte en fast størrelse og overskrives.
Afinstallation fjerner spor. At fjerne agenten for at “lukke hullet” kan slette den lokale log.

Hvad loggene kan og ikke kan bevise

Med en central auditlog, der stemmer med kundens egne logs, kan det ofte vises, hvilken teknikerkonto der startede hvilke sessioner og jobs mod hvilke maskiner og hvornår. Uden skærmoptagelse kan loggene sjældent vise, hvad teknikeren så eller klikkede på under en interaktiv session. Tidsforbrug i en faktureringstvist kan belyses, men en sessionslog alene viser ikke, om tiden var nødvendig. Det er en faglig vurdering, som ligger uden for loggen.

Dokumentation

Rapporten bør angive platform og version, eksportens format, periode og tidszone, hvem der leverede den, hashværdier, hvilke uafhængige kilder der er brugt til krydsvalidering, og hvilke konti der er fælles. Skriv eksplicit, hvilke handlinger der ikke kan føres til en navngiven person, og hvorfor.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse ved fratræden

Læs også: Bagdøre efter en administrator: opdagelse og dokumentation · Shadow AI: spor efter upload af firmadata

→ Undersøgelse ved fratræden · 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