Sessioner og tokens: når adgangen fortsætter efter skift af adgangskode

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

“Vi skiftede koden, men de var stadig inde.” Det er en af de mest almindelige forklaringer i sager om uautoriseret adgang til mail og cloudkonti. Forklaringen er teknisk: Moderne tjenester bruger tokens, og et token, der allerede er udstedt, er ikke nødvendigvis afhængigt af adgangskoden. For den, der skal dokumentere forløbet, betyder det, at loginlogs skal læses med forståelse for, hvordan sessioner fungerer. Hvordan aktive enheder og sessioner opgøres på tværs af tjenester, står i Hvem er logget ind på kontoen?.

Haster det? Sessioner, tokens og registrerede enheder ændres eller forsvinder, når adgangen lukkes, og Entra ID gemmer login- og auditlogs i 7 eller 30 dage afhængigt af licensen. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Artiklen forklarer mekanismerne, hvad loginlogs viser og ikke viser, og i hvilken rækkefølge sporene bør sikres. Felterne og fejlkoderne i Microsofts loginlog er gennemgået i Entra ID sign-in logs. Den praktiske side for en virksomhed, hvis mailkonto er overtaget, er beskrevet på bevissikring-digitalt.dk.

Hvordan en session virker

Når en bruger logger ind i en cloudtjeneste, får klienten typisk to slags tokens:

Et adgangstoken med kort levetid, ofte omkring en time, som bruges til at hente data.
Et opdateringstoken med lang levetid, som bruges til at få nye adgangstokens uden at logge ind igen.

Et skift af adgangskode kan ugyldiggøre opdateringstokens, men det afhænger af tjenesten, af klienten og af, hvordan koden er skiftet. Et adgangstoken, der allerede er udstedt, kan være gyldigt, til det udløber. Nogle tjenester understøtter løbende genvurdering, så en session kan afbrydes hurtigere ved ændringer, men det gælder ikke alle klienter. I Microsoft Entra får et adgangstoken som standard en tilfældig levetid mellem 60 og 90 minutter, mens klienter med løbende adgangsevaluering (CAE) kan få længere levetid, fordi tjenesten i stedet afviser tokenet ved hændelser som skift af adgangskode, deaktivering af kontoen eller tilbagekaldelse af sessioner.

Browsere holder desuden en sessionscookie, som svarer til et login. Den lever, til den udløber, brugeren logger ud, eller tjenesten afviser den.

Det, der lever videre efter et skift af adgangskode

App-adgange via OAuth: En app, der har fået lov til at læse mailen eller filerne, har sin egen tilladelse, som ikke nødvendigvis afhænger af adgangskoden.
App-adgangskoder: Ældre mailklienter kan bruge separate adgangskoder, som ikke ændres sammen med hovedkoden.
Registrerede godkendelsesmetoder: En ukendt telefon eller nøgle, der er registreret til totrinsgodkendelse, kan stadig godkende nye logins.
Videresendelsesregler og delinger: De ligger i postkassen eller i cloudlageret og virker uanset adgangskoden.
Sessioner, der ikke er tilbagekaldt: Mange tjenester har en særskilt funktion til at logge alle sessioner ud, og den skal bruges aktivt.
Synkroniserede enheder: En telefon eller computer, hvor kontoen er tilføjet, kan blive ved med at synkronisere.

Disse punkter er de første, der skal dokumenteres, fordi de forklarer en fortsat adgang, og fordi de forsvinder eller ændres, når adgangen lukkes.

Hvad loginlogs viser

Tidspunkt · Hvornår der er logget ind, eller hvornår et token er fornyet
IP-adresse og omtrentlig placering · Hvor forbindelsen kom fra. Placering er usikker ved mobilnet, VPN og cloudtjenester
Klient og enhed · Browser, app eller protokol, og eventuelt enheds-id
Godkendelsesmetode · Adgangskode, totrinsgodkendelse eller eksisterende token
Resultat · Lykkedes, fejlede eller blev afvist af en politik
Sessions- eller korrelations-id · Gør det muligt at følge en session på tværs af hændelser

Et login uden ny godkendelse efter et skift af adgangskode er ikke nødvendigvis et brud. Det kan være et token, der blev fornyet fra en enhed, kontoindehaveren selv bruger. Logs skal derfor læses sammen med tidspunktet for skiftet og for eventuel tilbagekaldelse af sessioner.

Fejlkilder i fortolkningen

Placering: IP-baseret geolokation angiver netværkets registrering, ikke enhedens fysiske placering. En mobiloperatør kan placere en dansk bruger i en anden by eller et andet land.
Fælles IP-adresser: Mange brugere bag samme router, VPN eller mobiloperatør deler IP-adresse.
Ikke-interaktive logins: Tokenfornyelser fra apps kan ligne logins, selvom ingen har tastet noget.
Mislykkede logins: Mange fejlede forsøg fra fremmede adresser er ofte automatiserede forsøg og viser ikke, at nogen er kommet ind.
Tidszoner: Portaler kan vise lokal tid, mens eksporter er i UTC. Notér, hvilken der er brugt.

En sammenhængende tidslinje på tværs af loginlogs, auditlogs og enhedsspor er beskrevet i tidslinjeanalyse.

Microsoft 365 og Google Workspace

Microsoft Entra har loginlogs for interaktive og ikke-interaktive logins. De ikke-interaktive viser blandt andet tokenfornyelser og overses ofte. Auditloggen viser ændringer af regler, apps og godkendelsesmetoder, og postkasseaktivitet findes i Unified Audit Log i Microsoft 365.
Google Workspace har logs for logins, OAuth-tokens og administratorhandlinger, se Google Vault og auditlogs.

Logs har begrænset opbevaring, som afhænger af tjeneste og licens. På tidspunktet for gennemgangen (oktober 2026) gemmer Microsoft Entra login- og auditlogs i 7 dage uden premiumlicens og i 30 dage med. Google Workspace gemmer brugerloggen i seks måneder. Eksportér dem tidligt.

For private konti hos fx Apple, Google og Microsoft findes en sikkerhedsside med seneste aktivitet og tilknyttede enheder. Den viser typisk kortere historik og færre detaljer end en virksomhedskonto, og den bør dokumenteres med skærmbilleder og eventuel dataeksport, før noget ændres.

App-tilladelser som selvstændigt spor

En OAuth-tilladelse er ofte det mest oversete spor. Når en app får adgang til en konto, registrerer tjenesten typisk appens navn, udgiver, de rettigheder, der er givet, og tidspunktet for samtykket. Rettighederne kan spænde fra at læse profiloplysninger til fuld adgang til mail og filer. En app med et neutralt navn og brede rettigheder, som kontoindehaveren ikke kender, er et vigtigt fund, og tidspunktet for samtykket kan sættes ind i tidslinjen.

Dokumentér tilladelsen, før den fjernes: appens navn og id, udgiveren, rettighederne og tidspunktet. Auditloggen kan desuden vise, hvilken konto der gav samtykket, og om det skete fra en kendt enhed.

Sikring i den rigtige rækkefølge

Eksportér loginlogs, auditlogs, OAuth-tilladelser, registrerede godkendelsesmetoder, enhedslister og postkasseregler.
Hash eksporterne, og registrér, hvem der eksporterede, hvornår og med hvilken konto.
Tilbagekald sessioner, fjern ukendte apps og enheder, og skift adgangskoden.
Eksportér logs igen bagefter, så det kan dokumenteres, at adgangen faktisk er lukket.

Den sidste eksport overses ofte, men den er vigtig: Den viser, om der er forsøg eller adgang efter lukningen, og dermed om alle veje ind er fundet. Mere om logs, der roterer eller udløber, findes i logfiler og logrotation.

Dokumentation i rapporten

Rapporten bør angive, hvilke logkilder der er eksporteret, hvilken periode de dækker, hvilken tidszone tidspunkterne er angivet i, og hvilke felter der er lagt til grund. Hvis opbevaringstiden betyder, at den tidligste del af forløbet ikke er dækket, skal det stå som en begrænsning.

Når et fund bygger på et bestemt felt, fx at et login skete med et eksisterende token frem for med adgangskode, bør rapporten forklare, hvordan feltet er tolket, og henvise til den eksporterede post. Rå eksportfiler lægges i bilag med hashværdier, så en anden sagkyndig kan efterprøve tolkningen uden at skulle have adgang til kontoen. Skærmbilleder fra administrationsportalen kan supplere, men de erstatter ikke eksporten, fordi portalen kan vise felter forkortet eller i lokal tid.

Hvad loginlogs kan og ikke kan bevise

Loginlogs kan vise, at kontoen blev brugt fra en bestemt klient og netværksadresse på et bestemt tidspunkt, og om det skete med adgangskode, totrinsgodkendelse eller et eksisterende token. De kan ikke alene vise, hvilken person der brugte klienten. Det kræver kobling til andre spor, fx enheds-id’er, der kan føres til en bestemt enhed, eller sammenfald med andre hændelser. Den juridiske betydning af en indsigelse om hacket konto er behandlet på digital-bevissikring.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Kundens hjemmeside blev hacket: ansvarsfordeling i sporene · BEC-undersøgelse i Microsoft 365 trin for trin

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · 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