RMM‑værktøjet som sikringsværktøj

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Et RMM-værktøj kan bruges til målrettet indsamling og triage, når der ikke er tid eller mulighed for at møde op ved hver maskine. Det er ofte den hurtigste vej til flygtige data på mange endpoints. Prisen er, at agenten ændrer det system, den indsamler fra, at data passerer gennem leverandørens platform, og at dokumentationen ligger i MSP’ens egen konsol. Det er acceptabelt, når det er bevidst valgt og dokumenteret. Det er ikke acceptabelt, når MSP’en eller RMM-platformen selv er en del af sagen.

RMM-logs som bevis for, hvad en tekniker har gjort, er en anden problemstilling og er beskrevet i IT-leverandørens adgang: RMM-logs. Denne artikel handler om at bruge værktøjet aktivt til sikring.

Hvad RMM egner sig til

RMM-platforme kan køre scripts med høje rettigheder på mange maskiner samtidig og hente resultatet tilbage. Det gør dem velegnede til:

Flygtige data: kørende processer, netværksforbindelser, indloggede brugere, planlagte opgaver og tjenester, før en maskine isoleres eller genstartes.
Målrettede artefakter: eksport af hændelseslogs, udvalgte registreringsdatabase-filer, prefetch-filer eller browserdatabaser fra mange maskiner.
Omfangsbestemmelse: søgning efter en kendt fil, en hashværdi eller en tjeneste på tværs af alle endpoints.
Fjerne lokationer: filialer og hjemmearbejdspladser, hvor fremmøde tager dage.

Formålet er det samme som ved anden fjernindsamling: at få de mest flygtige spor sikret hurtigt, så resten kan sikres grundigere bagefter. Afvejningen mellem triage og fuld kopi er beskrevet i triage i digital forensics.

Hvad agenten ændrer

Hver handling via RMM sætter spor på endpointet, og de skal kunne skelnes fra hændelsens:

Processer: scripts kører som underproces af agenten, typisk under systemkontoen. De optræder i EDR-telemetri, i proceslogs og eventuelt i 4688-hændelser.
Filer: mange platforme skriver scriptet til en midlertidig mappe, kører det og sletter det. Det skaber poster i filsystemets journal og kan overskrive ikke-allokeret plads.
Output på disk: gemmes indsamlingen lokalt, før den sendes, optager den plads, hvor slettede data kunne have ligget.
Logs: PowerShell-logning registrerer scriptindholdet, og agentens egen log vokser og roterer måske ældre poster ud.
Tidsstempler: at læse en fil kan opdatere adgangstiden, afhængigt af systemets indstillinger.

Påvirkningen er normalt lille og kendt, men den skal stå i dokumentationen. Princippet er det samme som ved live response: mindst mulig påvirkning, og fuld log over den påvirkning, der sker.

Hvor data bevæger sig

Ved en klassisk sikring går data fra kilden direkte til et medie, den sagkyndige kontrollerer. Ved RMM-indsamling går data typisk gennem platformens skyinfrastruktur. Det rejser tre tekniske spørgsmål:

Afkortning: mange platforme begrænser størrelsen af script-output og filoverførsler. Output, der skæres af uden fejlmelding, ser komplet ud uden at være det.
Konvertering: tekstoutput kan blive omkodet, fx fra UTF-16 til UTF-8, eller få ændrede linjeskift. Det ændrer hashværdien uden at ændre indholdet.
Opbevaring hos leverandøren: output kan ligge i konsollen i en periode, tilgængeligt for alle teknikere med adgang til kunden.

Løsningen er at lade scriptet pakke de indsamlede filer i et arkiv på endpointet, beregne hashværdier af hver fil og af arkivet der, og sende arkivet til en dedikeret, adgangsbegrænset placering i stedet for til konsollens outputfelt. Hashværdierne kontrolleres igen ved modtagelsen. Kommandoerne er beskrevet i hash af en fil.

Fremgangsmåde

Forbered scripts på forhånd. Indsamlingsscripts skrives, testes og versioneres, før der er en hændelse. Gem scriptets hashværdi og version.
Vælg modtagerplacering. En lagerplads, som kun de relevante personer kan skrive til og læse fra, adskilt fra kundens miljø.
Kør mod navngivne endpoints. Undgå brede jobs mod hele kunden, medmindre omfangsbestemmelse er formålet.
Notér job-id, tidspunkt og konto for hver kørsel, og eksportér konsollens revisionslog for jobbet bagefter.
Kontrollér resultatet. Sammenlign antal filer og hashværdier mellem endpoint og modtager, og notér fejl og maskiner, der var offline.
Overdrag. Det indsamlede overdrages med hashliste og en kort metodebeskrivelse til den, der skal analysere.

Hvad et indsamlingsscript typisk dækker

Et forberedt script til Windows-endpoints kan med fordel holdes smalt og forudsigeligt. Et typisk indhold er:

en liste over kørende processer med kommandolinje, forælderproces og starttidspunkt,
aktive netværksforbindelser med proces-id,
indloggede brugere og sessioner,
eksport af de vigtigste hændelseslogs med wevtutil epl frem for at kopiere de åbne logfiler direkte,
indholdet af C:\Windows\Prefetch og registreringsdatabasens hive-filer via en metode, der kan læse låste filer,
planlagte opgaver, tjenester og autostartpunkter,
maskinens tid, tidszone og tidskilde, så tidsstemplerne kan placeres korrekt.

Scriptet bør selv skrive en log over, hvad det har gjort, med start- og sluttidspunkt og fejl undervejs. Den log er en del af indsamlingen og hashes sammen med resten. Ændres scriptet, får det et nyt versionsnummer, og den gamle version gemmes, så det senere kan vises præcis, hvad der blev kørt mod hvilken maskine.

Hvornår RMM ikke bør bruges

MSP’en kan være part. Hvis hændelsen kan skyldes MSP’ens egen drift, bør MSP’en ikke selv indsamle det, der skal bedømme MSP’en.
RMM-platformen er mistænkt. Er angriberen kommet ind via RMM, eller er teknikerkonti kompromitteret, kan platformens resultater ikke betragtes som pålidelige. Misbrug af legitime fjernværktøjer er et kendt angrebsmønster.
Der er brug for slettede data. Gendannelse kræver en fuld kopi af mediet. Indsamling via agenten kan tværtimod forringe muligheden.
Den undersøgte er administrator. Har den undersøgte adgang til RMM-konsollen, kan job og output være påvirket.
Telefoner og cloudkonti. RMM dækker sjældent dem, og andre metoder er nødvendige.

Fejlkilder

Gentagne kørsler: platformen kan automatisk prøve et fejlet job igen, så scriptet kører to gange med forskellige resultater.
Forsinket udførelse: en maskine, der var slukket, kører jobbet, når den kommer online, måske dage senere.
Tidszoner: konsollen viser ofte en anden tidszone end endpointet. Angiv begge.
Sikkerhedssoftware griber ind: EDR eller antivirus kan blokere eller sætte et indsamlingsscript i karantæne, fordi det ligner angriberadfærd. Resultatet er et delvist output, og samtidig opstår en alarm, der senere skal forklares. Aftal undtagelser med den, der administrerer EDR, og notér dem.
Rettigheder: systemkontoen kan ikke altid læse brugerens profil, krypterede filer eller netværksdrev, og output kan derfor være ufuldstændigt uden fejl.

Hvad RMM-indsamling kan og ikke kan bevise

Korrekt dokumenteret kan en RMM-indsamling vise tilstanden på et endpoint på et bestemt tidspunkt og bære en tidslinje over de artefakter, der er indsamlet. Den kan ikke erstatte en fuld forensisk kopi, når spørgsmålet handler om slettede data, og den kan ikke stå alene, hvis RMM-platformen eller MSP’en er under mistanke. Rapporten skal angive platform, scriptversion, job-id, konto, tidspunkt, modtagerplacering og hashværdier, og den skal beskrive agentens påvirkning af endpointet.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Når MSP’en henvender sig på kundens vegne

Del af: Sikring: metoderne samlet

Læs også: Når MSP’en henvender sig på kundens vegne · MSP’ens egen rolle: adskillelse af drift og undersøgelse

→ Forensisk sikring · 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