Sådan stopper du OAuth-consent phishing i Microsoft 365 (blokér bruger-samtykke, brug admin-approval, og ryd op i apps)

OAuth-samtykke er lavet for at gøre hverdagen nem: en app beder om adgang, brugeren klikker “Acceptér”, og integrationen virker. Problemet er, at samme mekanik kan misbruges. OAuth consent phishing rammer især SMV’er, fordi der ofte er mange brugere, få admins og travl it-support.

Et klassisk scenarie er en mail om en “SharePoint PDF viewer”-app. Den ser legitim ud. Samtykkeskærmen nævner “læse filer” og “se profil”. Det lyder harmløst. I praksis kan appen få vedvarende adgang til mails og dokumenter, uden at angriberen behøver password.

Her er en konkret, tidløs opskrift til Microsoft Entra ID (tidl. Azure AD) og Microsoft 365: hærdning, oprydning og et kort incident response-forløb.

OAuth er i bund og grund “nøgler på en nøgleknippe”. Brugeren giver en app en nøgle (token) til udvalgte data, typisk via Microsoft Graph-tilladelser. Hvis appen er ond, eller bare unødigt “sulten” på rettigheder, kan den læse og flytte data i baggrunden.

Det er vigtigt at forstå, hvorfor klassisk perimetersikring ikke redder jer alene:

• Antivirus ser ikke altid misbrug af legitim OAuth-adgang.
• Firewall stopper ikke en godkendt cloud-app, der taler med Microsofts API’er.
• Backup hjælper med gendannelse, men stopper ikke datatyveri og videresendelse.

Business-konsekvensen handler ofte om tid og tillid. Lækkede tilbud, kontrakter, HR-dokumenter eller kundehenvendelser kan give tabte kunder og lange oprydningsforløb. For SMV’er kan det også betyde driftstab, fordi man midlertidigt må lukke integrationer og stramme adgange.

Hvis man vil have den officielle definition og Microsofts anbefalede værn, er Microsofts guide til at beskytte mod consent phishing et godt udgangspunkt.

Målet er enkelt: Brugere skal ikke kunne give brede rettigheder til tilfældige apps. Admins skal kunne godkende kontrolleret, og standarden skal være mindst privilegium.

I Microsoft Entra admin center:

1. Gå til Identity ; Applications ; Enterprise applications .
2. Find Consent and permissions (ofte under “Security” eller “User settings”, afhængigt af portalvisning).
3. Sæt User consent for applications til:
   • Do not allow user consent (typisk anbefalet for SMV’er med normal compliance-krav), eller
   • Allow user consent for apps from verified publishers, for selected permissions (hvis forretningen har mange legitime SaaS-integrationer).

Microsoft beskriver valgmulighederne og konsekvenserne her: konfigurér bruger-samtykke i Entra ID.

Praktisk tommelfingerregel:

• Tillad kun bruger-samtykke, hvis I har en moden godkendelsesproces og god overvågning.
• Hvis I er i tvivl, så blokér, og brug admin-godkendelse.

Admin consent workflow gør, at brugere kan anmode om en app, men ikke selv godkende.

1. Gå til Enterprise applications ; Consent and permissions .
2. Slå Admin consent requests til (workflow).
3. Vælg godkendere (mindst to personer, hvis muligt).
4. Definér hvad der kræver ekstra kontrol (fx “offline access”, mail-skrivning, fuld filadgang).

Microsofts gennemgang af proces og evaluering er her: admin consent workflow og vurdering af anmodninger.

Når det giver mening, så begræns til apps fra verified publishers . Det fjerner en stor del af “flotte navne”-tricket, hvor angriberen kalder appen “SharePoint PDF Viewer” eller “M365 Security Update”.

Kontrolpunkter ved godkendelse:

• Er udgiver verificeret, og matcher navnet jeres forventning?
• Er tilladelserne rimelige, eller beder den om mere end nødvendigt?
• Findes der et databehandlergrundlag, hvis det er en ekstern leverandør?

Hærdning stopper nye samtykker. Oprydning fjerner det, der allerede er sluppet igennem. I mange SMV-miljøer ligger der gamle test-apps, forladte integrationer og “gratis tools”, som ingen længere ejer.

Brug disse steder systematisk:

• Enterprise applications : Her ligger service principals (apps, der har adgang i tenant’en). Sortér på nyeste, ukendte navne, og apps med mange brugere.
• App registrations : Her ligger registreringer, ofte oprettet af udviklere eller power users. Se efter ukendte ejere og nylige ændringer.
• Permissions : Tjek hvilke Graph scopes der er givet (fx Mail.Read, Files.Read.All, offline_access).

Tegn på høj risiko:

• Appen er ukendt i forretningen og har bred adgang.
• Der mangler tydelig ejer (ingen ved, hvem der bruger den).
• Udgiver er ikke verificeret, eller navnet virker “for pænt”.

I Microsoft 365 og Entra ID bør man kunne besvare: “Hvem gav samtykke, hvornår, og til hvad?”

Praktiske steder at søge:

• Audit logs : Find events for “Consent to application” og “Add service principal”.
• Sign-in logs : Se om appen bruger tokens på tværs af lande eller på atypiske tidspunkter.
• App sign-ins (hvis tilgængeligt): Kan vise om en app pludselig har høj aktivitet.

En enkel SMV-rytme virker ofte bedst:

1. Identificér 10 mest risikable apps (brede scopes, ukendt ejer, ny oprettelse).
2. Kontakt forretningen kort, “Bruger nogen denne integration?”
3. Hvis ingen ejer, planlæg fjernelse i et vindue, og overvåg supporthenvendelser.
4. Fjern appen, og tilbagekald adgang.

Konkrete handlinger, når en app skal ud:

• Fjern appen fra Enterprise applications (service principal).
• Fjern evt. App registration , hvis den er oprettet i jeres tenant.
• Fjern consent grants (admin og brugere), hvis portalen viser dem separat.
• Udfør revoke sessions/tokens for berørte brugere (for at stoppe vedvarende adgang). Det er især vigtigt, hvis appen havde offline access.

For SMV’er i Århus (århus) og Lystrup (lystrup) er det tit en god it-løsning at få en fast driftsrutine med ekstern it-support. Hos NETDK ser man ofte, at oprydning i Enterprise Applications giver hurtige risikoreduktioner, uden at ændre brugernes hverdag ret meget.

Hvis en medarbejder har klikket “Acceptér”, gælder det om at stoppe adgang hurtigt og dokumentere.

Tjekliste til de første timer:

• Fjern den mistænkte app (Enterprise application/service principal).
• Tilbagekald sessions og tokens for den berørte bruger (og evt. flere, hvis appen blev givet bredt samtykke).
• Skift password og håndhæv MFA, hvis der er tegn på yderligere kompromis.
• Undersøg om mail, SharePoint eller OneDrive er tilgået i perioden (audit og sign-in logs).
• Kig efter regelforandringer i mail (videresendelse, inbox rules), og fjern dem.
• Informér internt kort og klart (hvad skete, hvad gør vi nu, hvad skal medarbejdere holde øje med).

Efterfølgende kontrol:

• Var der datalæk, som kræver kundeinformation eller juridisk vurdering?
• Skal samtykkepolitikken strammes yderligere?
• Skal der indføres en tydelig godkendelsesproces og brugervejledning?

OAuth-samtykker er en smart genvej, men de kan også blive en bagdør. Den bedste beskyttelse mod OAuth consent phishing i microsoft 365 er en kombination af blokering af user consent, admin-approval og løbende oprydning i apps og permissions. Backup, antivirus og firewall er stadig vigtige, men de kan ikke stå alene, når adgang gives via tokens. Næste skridt er at sætte politikken i Entra ID, gennemgå jeres apps, og gøre godkendelse til en fast del af change management.