OAuth‑apps og samtykke‑phishing: ukendte app‑tilladelser

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

Ved samtykke-phishing narres brugeren ikke til at afgive sin adgangskode, men til at give en app lov til at læse mail, filer eller kontakter. Appen får sine egne tokens og kan fortsætte, efter at adgangskoden er skiftet og sessionerne er tilbagekaldt. Undersøgelsen skal derfor finde alle app-tilladelser på de berørte konti, datere hvornår de blev givet og af hvem, og dokumentere, hvad appen faktisk har gjort med adgangen.

Haster det? Entra ID gemmer auditloggen over samtykker kun 7 eller 30 dage efter licens, og fjernes appen, forsvinder den fra listen over apps. Se akut forensisk sikring; hastesager koster ekstra.

Den korte introduktion til app-tilladelser som spor står i Sessioner og tokens: når adgangen fortsætter. Her går vi i dybden med, hvordan tilladelserne er bygget op, hvor de logges, og hvordan de læses.

Sådan virker et samtykke

Når en bruger klikker på et link og godkender en app, sker der typisk tre ting i Microsoft Entra ID:

Der oprettes en tjenesteprincipal (enterprise application) for appen i virksomhedens tenant, hvis den ikke findes i forvejen.
Der oprettes en tilladelsesbevilling (delegated permission grant), som knytter appen, brugeren og de godkendte rettigheder sammen.
Appen får tokens, herunder ofte et opdateringstoken, hvis rettigheden til vedvarende adgang (offline_access) er med.

Rettighederne kaldes scopes. Nogle er harmløse, som at læse brugerens profil. Andre giver fuld adgang, fx til at læse og skrive mail, sende mail som brugeren eller læse alle filer, brugeren kan se. En app med et neutralt navn som “Document Viewer” og rettigheder til at læse og sende mail samt vedvarende adgang er et klassisk fund.

Der skelnes mellem delegerede rettigheder, hvor appen handler på vegne af en bestemt bruger, og applikationsrettigheder, hvor appen handler uden bruger og ofte på tværs af hele tenanten. Applikationsrettigheder kræver normalt administratorens samtykke. Finder du en app med applikationsrettigheder, som ingen kan forklare, er spørgsmålet ikke længere én brugers fejlklik, men hvordan en administratorkonto blev brugt. → Bagdøre efter en administrator

Hvor det logges i Microsoft 365

Entra-auditlog · Samtykke til app, oprettelse af tjenesteprincipal, tilføjede rettigheder og rolletildelinger
Entra-loginlog for brugeren · Login til appen i forbindelse med samtykket
Loginlog for tjenesteprincipaler · Appens egne logins, når den bruger applikationsrettigheder
Purview-auditlog · Postkasse- og filhandlinger, hvor appens id fremgår som klient
Enterprise applications · Aktuel liste over apps, rettigheder og hvem der har givet samtykke

Auditloggens hændelse for samtykke indeholder typisk appens id, de bevilgede rettigheder, den bruger, der gav samtykket, og tidspunktet. Hændelsen kan stå under en tjenestekonto snarere end brugeren selv, og felterne kan være indlejret i et udvidet egenskabsfelt, så eksporten skal læses i rå form. Microsofts egen vejledning peger på aktiviteten Consent to application som den centrale hændelse, og tilknyttede hændelser om tilladelsesbevillinger og tjenesteprincipper bør hentes med. Microsoft Graph-aktivitetslogs kan give et mere detaljeret billede af, hvilke API-kald appen har foretaget. På tidspunktet for gennemgangen (oktober 2026) kræver de en premiumlicens til Entra ID, og de gemmes kun, hvis de på forhånd var sendt til et lager eller en analyseplatform.

Hvor det logges i Google Workspace

I Google Workspace findes en separat auditlog for OAuth-tokens, som viser, hvornår en bruger har godkendt en app, hvilke rettigheder appen fik, og hvornår tokens er brugt eller tilbagekaldt. Administratorkonsollen har desuden en oversigt over tilsluttede apps og deres rettigheder på tværs af domænet. Gmail- og Drive-auditloggene kan vise handlinger, hvor appen er klient. → Overtaget Google Workspace-konto

Sådan findes de ukendte apps

Eksportér listen over alle apps med samtykke i tenanten eller domænet, med rettigheder, udgiver og antal brugere.
Sortér efter risiko: apps med mail-, fil- eller sende-rettigheder, vedvarende adgang, ingen verificeret udgiver og få brugere.
Sammenhold med auditloggen: Hvornår blev hver mistænkelig app godkendt, af hvem og fra hvilken IP-adresse?
Sammenhold med mailen: Kom der en mail med et link til et samtykkeskærmbillede kort før? Søg i message trace efter afsenderen og linkets domæne.
Følg appens aktivitet: Søg i auditloggen efter handlinger med appens id som klient, fx læste eller sendte mails og hentede filer.

Dokumentér, før du fjerner

Når appen fjernes eller dens tilladelse tilbagekaldes, forsvinder den fra listen over apps, og kun auditloggen viser, at den har været der. Dokumentér derfor først:

appens navn, app-id og tjenesteprincipalens objekt-id,
udgiver og om udgiveren er verificeret,
omdirigeringsadresser (reply URLs), som kan pege på den infrastruktur, data er sendt til,
de bevilgede rettigheder, delegerede og applikations-,
hvem der gav samtykke, hvornår og fra hvilken IP-adresse,
eksport af auditlog og loginlog for appen.

Beregn hashværdier af eksporterne, og tag derefter en ny eksport efter fjernelsen, så det kan vises, at appen ikke længere har adgang.

Tenantens indstillinger på hændelsestidspunktet

I mange sager bliver spørgsmålet ikke kun, hvad appen gjorde, men om det overhovedet burde have været muligt. Det afhænger af tenantens indstillinger for brugersamtykke: Måtte brugere selv godkende apps fra alle udgivere, kun fra verificerede udgivere, kun med lavrisikorettigheder, eller slet ikke? Var der en arbejdsgang, hvor brugeren skulle bede en administrator om godkendelse? Gem de aktuelle indstillinger, og find i auditloggen, hvornår de sidst blev ændret og af hvem. Er de ændret efter hændelsen, skal den tidligere tilstand dokumenteres ud fra loggen, ikke ud fra hukommelsen. Oplysningen er ofte central, når en kunde og en IT-leverandør er uenige om, hvem der havde ansvaret for opsætningen.

Tilsvarende i Google Workspace: Gem indstillingerne for API-adgang og tredjepartsapps, herunder om ukonfigurerede apps var tilladt, og hvilke apps der var markeret som betroede eller blokerede.

Når appen har hentet data

Appens aktivitet i auditloggen viser, hvad der blev hentet fra virksomhedens side. Den viser ikke, hvor data endte. Omdirigeringsadresser og eventuelle domæner i appens registrering kan pege på den infrastruktur, der modtog tokens, men det er en teknisk indikation, ikke en identifikation. Har appen haft adgang til mail, skal omfanget vurderes på samme måde som ved en overtaget konto, og listen over berørte mails og filer bliver grundlaget for vurderingen af et eventuelt persondatabrud.

Typiske fejlkilder

Legitime apps med brede rettigheder. Backupværktøjer, CRM-integrationer og mailsignaturprogrammer har ofte netop de rettigheder, en ondsindet app ville bede om. Bred rettighed er ikke i sig selv mistanke.
Navnet siger intet. En app kan hedde det samme som et kendt produkt. App-id og udgiver er det, der identificerer den.
Tidspunktet for oprettelse er ikke tidspunktet for brug. En tjenesteprincipal kan have eksisteret længe, før den blev brugt.
Fjernet app, tokens i omløb. Allerede udstedte adgangstokens kan bruges, til de udløber. I Entra ID er standardlevetiden tilfældigt mellem 60 og 90 minutter, men den kan være længere afhængigt af klient og opsætning, så aktivitet kort efter tilbagekaldelsen er ikke i sig selv et tegn på en ny adgang.

Hvad det kan og ikke kan bevise

Auditloggen kan vise, at en bestemt konto gav en bestemt app bestemte rettigheder på et bestemt tidspunkt. Sammen med appens aktivitet i loggen kan den vise, hvad appen hentede eller sendte. Den kan ikke vise, hvem der står bag appen, ud over de tekniske oplysninger om udgiver og omdirigeringsadresser. Den kan heller ikke alene vise, om brugeren forstod, hvad der blev godkendt. Det er en vurdering, der ligger uden for loggen. Den juridiske side af en indsigelse om hacket konto er beskrevet på digital-bevissikring.dk.

I rapporten

Angiv for hver app identifikatorer, rettigheder, samtykketidspunkt og -konto, observerede handlinger og tidspunktet for fjernelse. Forklar kort forskellen på delegerede og applikationsrettigheder, fordi den afgør, hvor meget appen kunne nå.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: BEC-undersøgelse i Microsoft 365 trin for trin · AiTM-phishing: kendetegn på stjålne sessioner i loginloggen

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