Hændelse hos flere kunder på én gang

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Når samme hændelse rammer flere kunder, er det næsten altid MSP’ens fælles værktøjer, der binder dem sammen: RMM-platformen, partneradgangen til kundernes tenants, en delt teknikerkonto, adgangskodeboksen eller backupkonsollen. Det fælles knudepunkt skal derfor sikres først, fordi det er dér, det kan ses, hvilke kunder angriberen faktisk nåede. Derefter prioriteres kunderne efter tegn på aktivitet og efter, hvor hurtigt deres egne logs forsvinder. Og hele vejen skal hver kundes data holdes adskilt fra de andres.

Den enkelte kundes første time er beskrevet i tjeklisten til MSP’er. Denne artikel handler om det, der er anderledes, når der er mange kunder på én gang.

Én hændelse eller mange

Det første tekniske spørgsmål er, om hændelserne har en fælles årsag. Sammenfald i tid er ikke nok. Se efter en fælles indgang:

jobs eller sessioner fra RMM-konsollen, der rammer flere kunder fra samme teknikerkonto eller samme API-nøgle,
logins via partnerrelationen i kundernes Entra ID fra samme adresse eller klient,
opslag i adgangskodeboksen på tværs af kundemapper,
ændringer i backupkonsollen, fx slettede jobs eller forkortet opbevaring hos flere kunder,
samme fil, samme hashværdi eller samme planlagte opgave på endpoints hos forskellige kunder.

Findes den fælles indgang, er det én hændelse med mange berørte, og sikringen skal organiseres derefter. Findes den ikke, er det flere hændelser, der skal behandles hver for sig, også selv om de skete samme nat.

Sikr det fælles knudepunkt først

MSP’ens centrale systemer viser omfanget bedre end nogen enkelt kundes logs. Sikr derfor tidligt:

RMM-konsollens revisionslog og sessionslog for hele perioden, i rå form, med hashværdi. Hvad loggen indeholder, er beskrevet i IT-leverandørens adgang: RMM-logs.
Identitetsudbyderens loginlog for teknikerkonti og tjenestekonti.
Partnerrelationer: hvilke kunder der havde delegeret administration, med hvilke roller, og hvornår de blev ændret.
Adgangskodeboksens revisionslog, især opslag og eksport.
PSA- og ticketsystemets historik for de berørte kunder i perioden.
Backupkonsollens revisionslog, fordi slettede eller ændrede backups ofte er en del af angrebet.

Det er MSP’ens egne logs, og det er derfor også her, at MSP’ens rolle bliver synlig. Det vender vi tilbage til.

Prioritering af kunderne

Kunderne kan sjældent sikres samtidig. Prioritér efter tekniske kriterier, ikke efter kundens størrelse:

Tegn på aktivitet: kunder, hvor knudepunktets logs viser sessioner, jobs eller logins fra angriberen, kommer først.
Opbevaring: kunder med kort opbevaring af loginlogs eller revisionslog, fx på grund af licensniveau, skal sikres, før data roterer ud.
Igangværende skade: kryptering, dataudtræk eller misbrug af konti, der stadig foregår.
Følsomme data: kunder med særlige kategorier af persondata eller fortrolige oplysninger.
Kundens egen kapacitet: kunder med eget IT-personale kan måske sikre en del selv efter en fælles vejledning.

Lav en enkel matrix med én række pr. kunde og notér, hvorfor rækkefølgen blev, som den blev. Matrixen ændrer sig undervejs, efterhånden som knudepunktets logs bliver analyseret. Gem hver version, så det senere kan forklares, hvorfor en kunde blev sikret før en anden.

Adskillelse af kundedata

Hver kunde er selvstændig ejer af sine data, og en kunde må ikke få indsigt i en anden kundes data via undersøgelsen. Det stiller konkrete krav:

Separat opbevaring: én container eller ét krypteret volumen pr. kunde, med egen hashliste og egen chain of custody-log.
Opdeling af fælles logs: RMM- og partnerlogs indeholder alle kunder. Bevar den fulde eksport forseglet med hashværdi, og udled en delmængde pr. kunde med en dokumenteret filtrering. Så kan delmængden altid føres tilbage til helheden.
Pseudonymer i fælles analyser: når tidslinjen på tværs af kunder skal bygges, bruges kundekoder i stedet for navne.
Separate rapporter: hver kunde får en rapport om sin egen del. Den fælles indgang beskrives uden at nævne de andre kunder.
Adgangsstyring: analytikere, der arbejder for én kunde, har ikke automatisk adgang til de andres materiale.

Én tidslinje, mange udsnit

Analysen bygges bedst som én samlet tidslinje på knudepunktsniveau, hvor hver hændelse er mærket med kundekode. Den viser rækkefølgen: hvilken kunde der blev ramt først, og hvordan angriberen bevægede sig. Fra den samlede tidslinje laves udsnit pr. kunde. Normalisér tidszoner, før kilderne lægges sammen, fordi RMM-konsollen, kundernes tenants og endpoints ofte bruger forskellige tidsangivelser. Metoden er beskrevet i logkorrelation.

Når MSP’en selv er indgangen

Hvis den fælles indgang er MSP’ens egne værktøjer eller konti, er MSP’en ikke kun hjælper. Kunderne kan rette krav mod MSP’en, og spørgsmål om MFA på teknikerkonti, adgangsrettigheder og overvågning vil blive stillet. Så bør analysen af de centrale systemer laves af en uvildig, og MSP’en bør holde egne driftsopgaver adskilt fra undersøgelsen. Fremgangsmåden er beskrevet i MSP’ens egen rolle: adskillelse af drift og undersøgelse.

Afklar samtidig, hvem der er opdragsgiver. En uvildig sagkyndig kan ikke arbejde for både MSP’en og en kunde, der retter krav mod MSP’en i samme sag. Nielco IT’s politik er beskrevet under uvildighed og bindinger. Leverandørens perspektiv, når kunden giver den skylden, står på bevissikring-digitalt.dk.

Kapacitet

Mange kunder betyder mange lokationer og mange konti. Ved større omfang kan Nielco IT tilknytte konsulenter, der arbejder som IT-sagkyndige i Nielco IT’s regi og med samme tavshedspligt. Uanset hvem der sikrer, skal metoden, hashlisterne og dokumentationen være ens på tværs af kunderne, så resultaterne kan sammenlignes.

Kommunikation til kunderne

Hver kunde skal informeres om sin egen situation, ikke om de andres. Brug en kanal, der ikke går gennem de kompromitterede systemer, og skriv faktuelt: hvad er observeret hos netop denne kunde, hvad er sikret, og hvad mangler. Undlad at nævne andre kunder ved navn, også selv om det er åbenlyst, at flere er ramt. Undgå tidlige udsagn om årsag og ansvar, fordi de kan blive fremlagt senere, hvis en kunde rejser krav. Notér, hvornår hver kunde blev informeret, og hvad der blev sagt. Det er relevant både for kundernes egne frister ved persondatabrud og for en senere vurdering af MSP’ens håndtering.

Hvad undersøgelsen kan og ikke kan

Med sikrede knudepunktslogs og kundernes egne logs kan det normalt vises, hvilke kunder angriberen nåede via den fælles indgang, i hvilken rækkefølge og med hvilke handlinger. Det kan også vises, hvilke kunder der ikke ses berørt i de tilgængelige kilder. Det er ikke det samme som at bevise, at de ikke er berørt: hvis en kundes logs allerede var roteret, skal det stå som en begrænsning.

Typiske fejl

Kunderne behandles enkeltvis, og ingen sikrer knudepunktets logs, før de roterer.
Fælles eksporter sendes i deres helhed til alle kunder.
Teknikerkonti nulstilles, før loginloggen er sikret.
MSP’en analyserer sin egen konsollog og konkluderer om egen rolle.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Hvornår SOC’en skal kalde en uvildig ind · Skadebehandlerens tekniske tjekliste til en IR-rapport

→ Undersøgelse efter et hackerangreb · 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