Knight Office ukazuje, proč je krádež relace Microsoft 365 incidentem identity

Vícefaktorové ověření (MFA) ověřuje přihlášení, ale samo o sobě nechrání každou relaci, která po přihlášení vznikne. Phishingová sada Knight Office, kterou popsal Huntress, zachytila materiál relace Microsoft 365 a po prvotním průniku následovala neoprávněná registrace zařízení v Microsoft Entra ID. Správný provozní pohled proto není „uniklo heslo“, ale kompromitace identity. 640

Co se při útoku děje

Zdokumentovaný řetězec začal phishingovým e-mailem ve stylu DocuSignu. Odkaz vedl přes měřicí službu Monday.com a následně přes kompromitovaný web na platformě Joomla. Účelem těchto mezikroků bylo skrýt výslednou phishingovou stránku před reputačními kontrolami a běžnou kontrolou odkazu v e-mailu. 6

Útočník při technice adversary-in-the-middle (AiTM) funguje jako reverzní proxy mezi obětí a skutečnou přihlašovací službou Microsoftu:

1. Oběť zadá přihlašovací údaje a dokončí běžnou výzvu MFA.
2. Proxy tuto komunikaci v reálném čase přeposílá skutečné službě Microsoftu.
3. Po úspěšném ověření zachytí cookie relace nebo jiný tokenový materiál vrácený prohlížeči.
4. Útočník pak tento ověřený stav přehraje ze své infrastruktury a získá přístup k účtu.

Nejde tedy o kryptografické prolomení MFA. Útočník krade stav autorizace, který vznikl až po úspěšném MFA. Microsoft krádež tokenu definuje jako kompromitaci a opětovné použití tokenu vydaného uživateli, který mohl MFA již splnit. 40

Proč samotná změna hesla nestačí

Ukradená relace v prohlížeči nebo přístup odvozený z obnovovacího tokenu může útočníkovi umožnit pokračovat bez další výzvy k heslu či MFA, dokud příslušné tokeny nejsou zneplatněny. Microsoft při reakci na krádež tokenů výslovně doporučuje dotčené uživatele či zařízení zablokovat a zrušit jejich aktuální tokeny. 40

Případ Knight Office je závažnější tím, že po kompromitaci bylo zaznamenáno připojení neoprávněného zařízení do Microsoft Entra ID a nastavení útočníkem ovládaných přihlašovacích údajů Windows Hello for Business. 6 To může vytvořit samostatnou cestu k ověření identity. Po zneplatnění původní webové relace nebo resetu hesla proto musí tým ověřit, zda v tenantovi nezůstalo neznámé zařízení či nově přidaná ověřovací metoda.

Podobný princip perzistence je zdokumentován také u phishingu zneužívajícího device code flow. Microsoft uvedl, že obnovovací token získaný tímto způsobem může posloužit k vyžádání přístupu pro registraci zařízení a k registraci zařízení ovládaného útočníkem v Entra ID. 28

Device-code phishing není totéž co AiTM

Obě techniky míří na použitelný autorizační artefakt, ale fungují odlišně:

• AiTM phishing zprostředkovává živé přihlášení a krade výslednou relaci.
• Device-code phishing zneužívá legitimní autorizační tok OAuth pro zařízení: útočník založí žádost o kód, přiměje oběť k zadání kódu a ověření a po schválení získá tokeny pro klienta, kterého ovládá. 22

Detekce proto nemá pokrývat jen AiTM proxy. Doporučení Elasticu upozorňuje zejména na úspěšná interaktivní přihlášení do Entra ID přes protokol device code s klientem Microsoft Authentication Broker a požadavky na služby první strany, například Exchange Online, Microsoft Graph nebo SharePoint. 17

Knight Office v širším trendu PhaaS

Vyšetřování Huntress potvrdilo konkrétní sekvenci průniku Knight Office: dokumentovou návnadu, vícekroková přesměrování, zachycení tokenu relace a neoprávněnou registraci zařízení do Entra ID. Huntress navíc ve své telemetrii spojil opakované přehrávání tokenů s jednou IP adresou; tento poznatek ale není celosvětovým počtem obětí. 6

Knight Office zapadá do rostoucí nabídky sad phishing-as-a-service (PhaaS) zaměřených na relace Microsoft 365:

• Mirage2FA využívá AiTM infrastrukturu k zachycení přihlašovacích údajů i ověřených relací. ANY.RUN uvádí 9 332 potenciálních kompromitačních událostí v letech 2024 až 2026, z toho 4 561 případů krádeže cookies. Jde o potenciální události vycházející z telemetrie, nikoli o počet potvrzených obětí. 4
• Kali365, poprvé zaznamenaný v dubnu 2026 a šířený hlavně přes Telegram, byl předmětem varování FBI kvůli schopnosti získávat přístupové a obnovovací tokeny Microsoft 365 OAuth. 1

Společné poučení je jednoduché: tokeny a relace je nutné chránit, detekovat a řešit se stejnou vážností jako kompromitované heslo.

Co prioritně hledat v Entra ID a Microsoft 365

Nejlepší výsledky nepřinese izolovaný alert, ale korelace více signálů.

1. Podezřelé opětovné použití relace

Prověřujte případy, kdy se stejný účet nebo relace objeví v krátkém čase z výrazně odlišných IP adres, sítí, zeměpisných oblastí, prohlížečů nebo vlastností zařízení — zvlášť krátce po úspěšném MFA. Microsoft upozorňuje na detekce anomálního použití tokenů a neznámých vlastností přihlášení souvisejících s cookies relace. 38

2. Neobvyklé použití device code flow

Kontrolujte úspěšná ověření přes device code a posuzujte, zda odpovídají použitý klient, zdrojová IP, požadovaný prostředek a chování uživatele. V přihlašovacích protokolech Entra mohou takovou aktivitu označovat například pole authenticationProtocol: deviceCode a originalTransferMethod: deviceCodeFlow. 26

3. Změny, které vytvářejí perzistenci

Přednostně vyšetřujte auditní události Entra týkající se:

• nových registrací a připojení zařízení, změn vlastníků nebo neobvyklých identifikátorů zařízení;
• nově přidaných metod Windows Hello for Business, FIDO2/passkey, MFA či metod obnovy účtu;
• souhlasů aplikacím, změn podnikových aplikací, service principals a přiřazení privilegovaných rolí;
• změn podmíněného přístupu, pojmenovaných umístění, federace, přeposílání pošty a pravidel doručené pošty.

Neoprávněná registrace zařízení krátce po podezřelém ověření je vysoce prioritním signálem identity persistence. 2628

4. Propojení e-mailových a identitních stop

Samotný e-mail s motivem DocuSignu může být jen spam. Samostatně nově registrované zařízení může být legitimní. Kombinace podezřelé zprávy, důkazů o přesměrovacím řetězci, úspěšného MFA, neobvyklého využití relace a změny zařízení či ověřovací metody je však výrazně akčnější.

Reakce na incident: omezte identitu, ne jen heslo

Při podezření na AiTM nebo krádež tokenů přes device code použijte postup zaměřený na celou identitu:

1. Podle potřeby zablokujte či vypněte dotčenou identitu. Během zjišťování rozsahu vypněte zasažené uživatelské a zařízeníové účty. 40
2. Zneplatněte aktuální relace a obnovovací tokeny. Použijte proces odvolání přihlašovacích relací v Entra a vynuťte nové přihlášení. Microsoft pro reakci na device-code phishing doporučuje odvolat obnovovací tokeny voláním revokeSignInSessions. 27
3. Resetujte heslo, ale nepovažujte tím případ za uzavřený. Reset hesla je doplňkové opatření, nikoli důkaz, že útočník ztratil přístup. 4042
4. Odstraňte perzistenci. Najděte a odstraňte neoprávněná zařízení Entra, prověřte jejich vlastnictví, odeberte nedávno přidané metody Windows Hello for Business, FIDO2, MFA, obnovy účtu a přihlašovací údaje aplikací; zkontrolujte také udělené souhlasy. 628
5. Prohledejte celý tenant. Hledejte stejné návnadové URL, přesměrovací infrastrukturu, podezřelé zdrojové IP adresy, device-code události, anomálie po MFA a nové registrace zařízení u všech uživatelů, nejen u první nahlášené oběti.
6. Vyhodnoťte dopad na byznys. Prověřte auditní aktivitu v Exchange, SharePointu, OneDrivu, Teams, Microsoft Graphu a OAuth: přístup k datům, pravidla schránky, přeposílání, externí sdílení, zneužití souhlasů, změny oprávnění a přístupy přes aplikace napojené na SSO.
7. Před úklidem zajistěte důkazy. Uchovejte phishingové e-maily včetně hlaviček, mail trace, přesměrovací řetězce, přihlašovací a auditní logy Entra, záznamy o zařízeních, OAuth souhlasech a telemetrii prohlížečů či endpointů.

Jak snížit riziko před další návnadou

Phishingu odolné metody ověření jsou důležitou vrstvou, zejména pro privilegované a vysoce rizikové účty. Microsoft doporučuje metody jako bezpečnostní klíče FIDO2, Windows Hello for Business a ověření založené na certifikátech; u nespravovaných zařízení také opatření zkracující použitelnou životnost relací. 39

Organizace by zároveň měly vyhodnotit, zda device code flow skutečně potřebují, omezit neoprávněnou registraci zařízení, uplatnit podmíněný přístup podle souladu zařízení a rizika a zajistit, že provozní tým dokáže rychle zneplatnit relace a prověřit změny objektů identity.

Základní poučení z Knight Office nezní, že MFA selhalo. Problém je, že úspěšné MFA může být začátkem kompromitace, pokud útočník ukradne relaci, která po něm následuje. Reakce je úplná teprve tehdy, když tým prověřil a omezil relace, zařízení, ověřovací metody i delegované přístupy v celém tenantovi.