Noko av det eg tok med meg heim frå Workplace Ninja Summit i Baden, var kor mykje eininga faktisk betyr for identiteten.

Vi snakkar mykje om MFA, passkeys, Conditional Access og token. Men eininga er ikkje berre noko brukaren sit framfor når den loggar inn.

Eininga kan sjølv bli ein del av tillitskjeda.

Det poenget vart tydeleg gjennom sesjonane om moderne identitetsangrep, device trust, passkeys og privilegerte arbeidsplassar. Kort tid etter konferansen kom det konkrete angrep som gjorde problemstillinga langt mindre teoretisk.

For kva skjer dersom ein angripar ikkje berre får ein sesjon, men rekk å registrere si eiga eining i Entra ID?

Då kan Revoke sessions + reset password vere starten på incident response. Ikkje slutten.

PREVIEW – manuelt skjermbilete/portalbevis manglar: identity-er-meir-enn-brukaren.png
Vis identiteten som ei samansett tillitskjede: brukar, autentiseringsmetode, token, eining og Conditional Access. Eininga skal vere visuelt framheva som ein tryggleiksgrense

Preview plasshaldar for identity-er-meir-enn-brukaren.png

Device code flow var allereie på blokkeringslista mi

På Workplace Ninja Summit såg vi korleis legitime autentiseringsmekanismar kan misbrukast. Eitt av dei konkrete punkta eg tok med meg heim var:

Blokker device code flow med Conditional Access dersom du ikkje har eit dokumentert behov for den.

Device code flow er ein legitim OAuth-flyt. Problemet er at angriparen kan starte autentiseringsflyten og manipulere brukaren til å fullføre den på Microsoft si legitime innloggingsside. MFA kan bli gjennomført, men brukaren autoriserer i realiteten ein flyt angriparen starta.

Angriparen treng altså ikkje nødvendigvis å bryte MFA. Den kan få brukaren til å gjennomføre autentiseringa for seg.

C
Conditional Access: Authentication flows
Microsoft forklarer device code flow, protocol tracking og kvifor flyten bør blokkerast der den ikkje er nødvendig.
B
Block authentication flows with Conditional Access
Microsoft si konkrete rettleiing for å kartleggje og blokkere device code flow med Conditional Access.

Blokkering av device code flow er derfor ein del av CA-baselinen eg ville starta med. Kartlegg bruken i Report-only først, finn dei legitime behova, og lag deretter eksplisitte og avgrensa unntak.

Det som skjer på skjermen er ikkje heile autentiseringa

Dette var noko av det eg synest var mest interessant i Baden. Passkeys, Windows Hello for Business, device bound credentials, attestation, Primary Refresh Token, Conditional Access og Token Protection fortel eigentleg den same historia:

Identiteten stoppar ikkje ved brukarkontoen.

PREVIEW – manuelt skjermbilete/portalbevis manglar: fra-brukar-til-tillit.png
Arkitekturillustrasjon som viser korleis brukar, passkey eller WHfB, device trust, PRT/token og Conditional Access saman etablerer tilgang til Microsoft 365

Preview plasshaldar for fra-brukar-til-tillit.png

Det same såg vi i diskusjonen rundt PAW og Windows 365. Ein privilegert arbeidsflate inne i ein Cloud PC eller VM fjernar ikkje automatisk risikoen dersom inngangen kjem frå ei kompromittert arbeidsmaskin.

Tilliten må vurderast heilt tilbake til eininga.

Så kom GhostCode

Kort tid etter Workplace Ninja Summit dokumenterte eSentire Threat Response Unit GhostCode. Det interessante var ikkje berre korleis angriparen kom inn, men kva som skjedde etterpå.

Etter at offeret hadde gjennomført autentiseringa, starta automatisert aktivitet svært raskt. Angriparen fekk registrert eigne device objects.

Angrepskjeda kan altså gå frå phishing via legitim device code authentication og token til device registration og vidare aktivitet.

PREVIEW – manuelt skjermbilete/portalbevis manglar: device-code-angrepskjede.png
Vis den komplette device code phishing-angrepskjeda og marker punktet der vanleg incident response ofte stoppar for tidleg

Preview plasshaldar for device-code-angrepskjede.png

Microsoft dokumenterer no den same angrepskjeda

  1. september publiserte Microsoft ei omfattande analyse av EvilTokens. Microsoft set device registration inn i angrepskjeda og dokumenterer deteksjonar for device code authentication, token theft, mistenkjeleg Entra device join eller registration, unormal Microsoft Graph-aktivitet og skadelege inbox rules.

Det bind saman mykje av det eg nettopp hadde høyrt om i Baden:

Eininga er ei tryggleiksgrense.

U
Unmasking EvilTokens: Getting to the root of device code phishing
Microsoft Threat Intelligence viser korleis device code phishing kan utvikle seg frå initial access til tokenmisbruk, device registration, Graph-aktivitet og vidare persistence.

Sosial manipuleringa har allereie flytta seg

Microsoft dokumenterte 9. september aktive angrep der personar utgav seg for å vere IT eller helpdesk. Passkey, MFA og SSO kunne bli brukte som lokkemiddel for å få brukaren til å gjennomføre AiTM eller device code authentication.

Dette er ikkje eit argument mot passkeys. Det er eit argument for å forstå heile autentiseringsprosessen rundt dei.

P
Passkey-themed social engineering leads to identity and cloud compromise
Microsoft Security Research dokumenterer korleis falsk IT-støtte brukar passkey, MFA og SSO som lokkemiddel for identitetsangrep.

Revoke sessions er framleis viktig

Dette betyr ikkje at Revoke sessions ikkje fungerer. Det er eit sentralt containment-tiltak.

Poenget er at incident response også må undersøkje kva som skjedde mellom kompromisset og tilbakekallinga.

Kva rakk angriparen å endre eller etablere?

Eg ville endra runbooken

PREVIEW – manuelt skjermbilete/portalbevis manglar: entra-incident-response-runbook.png
Ei visuell sjekkliste for respons etter identitetskompromiss i Entra ID

Preview plasshaldar for entra-incident-response-runbook.png

Den gamle mentale sjekklista med reset password, revoke sessions og kontroll av MFA bør bli større.

Eg ville minimum kontrollert:

  • Blokker eller avgrens kontoen ved aktivt kompromiss
  • Revoke sessions
  • Reset kompromitterte credentials
  • Kontroller nye authentication methods
  • Kontroller nye Entra registered og Entra joined devices
  • Kontroller Intune enrollment
  • Kontroller mistenkjeleg Microsoft Graph-aktivitet
  • Kontroller OAuth consent og applikasjonstilgang
  • Kontroller mailbox rules
  • Kontroller Exchange, SharePoint og OneDrive
  • Undersøk device-relaterte autentiseringsartefaktar dersom angrepsbildet tilseier det

Eit registrert device object gir ikkje automatisk angriparen varig tilgang. Effekten kjem an på korleis eininga vart registrert eller joina, kva autentiseringsartefaktar som vart utferda, og kva Conditional Access-policyar som gjeld. Men det er nettopp derfor vi må sjekke.

Og eg ville blokkert device code flow

Microsoft anbefaler å blokkere device code flow der det er mogleg. For Teams-einingar som faktisk treng flyten, finst det konkret rettleiing for kontrollerte unntak.

R
Restrict device code flow for Microsoft Teams devices
Microsoft viser korleis device code flow kan blokkerast generelt, samtidig som nødvendige Teams resource accounts får kontrollerte unntak.

Finn kontoane som faktisk treng flyten. Dokumenter behovet. Lag unntaket. Blokker resten.

Microsoft dokumenterer både Authentication protocol = Device code flow og Original transfer method = Device code flow i sign-in logs. Det siste er interessant fordi protocol tracking kan knyte seinare tokenaktivitet til den opphavlege device code-sesjonen.

Eininga er ein del av identiteten

Dette er kanskje den viktigaste lærdommen eg tok med meg frå Workplace Ninja Summit.

Vi må passe på at vi ikkje gjer identitet synonymt med berre brukarkonto.

I moderne Entra ID er det ei større tillitskjede:

Brukaren → autentiseringsmetoden → tokenet → eininga → tilstanden til eininga → Conditional Access → handlingane etter autentisering

Det betyr at incident response må følgje den same kjeda.

For heilt ærleg:

Du tilbakekalla sesjonen. Du resette passordet. Du kontrollerte MFA.

Bra.

Men sjekka du kva angriparen rakk å etablere før du kasta den ut?

Og sjekka du om ei av dei tinga var ei eiga eining i tenanten din?