MFA funguje. Útočník ale ukradl už přihlášenou relaci CIO MAG

Incident často začíná větou: MFA přece proběhlo, jak se tam mohl dostat někdo jiný? Odpověď je v rozdílu mezi přihlášením a relací. Vícefaktorové ověření rozhoduje, kdo smí relaci vytvořit. Následující požadavky už aplikace obvykle přijímá podle krátkodobého tajemství, které vydala prohlížeči nebo klientské aplikaci.

Aktuální pravidla NIST výslovně rozlišují autentizátor a browserovou cookie. Cookie není autentizátor, ale tajemství pro udržování relace. Její krádež přesto může mít podobný dopad jako selhání samotného přihlášení. MITRE ATT&CK vede krádež webové cookie jako samostatnou techniku T1539 a počítá s útoky z disku, paměti prohlížeče, škodlivého procesu i podvržené přihlašovací brány.

Nejde tedy o slovíčkaření. Pokud bezpečnostní architektura chrání pouze vydání relace, ale ne její další život, útočník může přeskočit přesně tu kontrolu, do které organizace investovala nejvíc.

Manažerské shrnutí

01MFA chrání vznik relace Jakmile aplikace vydá přenositelnou cookie nebo token, jejich pouhé držení může stačit k dalším požadavkům bez hesla a druhého faktoru.

02Změna hesla není zneplatnění relací Poskytovatel identity a každá připojená aplikace mohou udržovat vlastní relaci. Jedno centrální odhlášení proto nemusí ukončit všechny.

03Nejcennější relace je nepřenositelná U kritických služeb má být relace svázaná se zařízením nebo klíčem, průběžně vyhodnocovaná a rychle zneplatnitelná.

Přihlášení a relace jsou dvě různé bezpečnostní hranice

Uživatel vnímá přihlášení jako jednu událost. Technicky jde o řetězec několika rozhodnutí. Každé používá jiné tajemství a potřebuje jiný způsob zneplatnění.

Fáze	Co systém ověřuje	Co může útočník získat
1. Přihlášení	Heslo, jednorázový kód, potvrzení v aplikaci, certifikát nebo passkey.	Heslo, schválení požadavku nebo výsledek podvrženého přihlášení.
2. Vydání relace	Aplikace přijme výsledek přihlášení a vytvoří cookie či sadu tokenů.	Cookie, přístupový token, obnovovací token nebo celý profil prohlížeče.
3. Běžný požadavek	Server kontroluje platnost relace, rozsah oprávnění a případné kontextové podmínky.	Možnost opakovat požadavek jako již ověřený uživatel.
4. Obnova	Klient může bez interakce získat nový přístupový token nebo prodloužit relaci.	Dlouhodobější přístup, pokud získal obnovovací mechanismus.

NOSNÁ TEZE

MFA chrání okamžik, kdy relace vzniká. Bezpečnost po přihlášení určuje, zda lze tuto relaci ukrást, přenést na jiné zařízení a včas zneplatnit.

Stejný výsledek, různé cesty ke krádeži

Výrok „MFA bylo obejito“ často zakryje technický rozdíl, který je pro obranu zásadní. U některých útoků útočník stojí mezi uživatelem a skutečnou službou už při přihlášení. U jiných přihlašování vůbec neovlivní a vezme relaci až z již ověřeného zařízení.

Cesta	Jak funguje	Co ji omezuje
Podvržená přihlašovací brána	Uživatel komunikuje přes útočníkovu reverzní bránu se skutečnou službou. Heslo i jednorázový kód nebo potvrzení mohou být platné a služba následně vrátí cookie, kterou brána zachytí.	Ověření odolné proti phishingu, zejména FIDO a WebAuthn, podmínka spravovaného zařízení a detekce následného přehrání relace.
Infostealer nebo škodlivé rozšíření	Škodlivý proces čte databázi cookies, úložiště klienta, paměť prohlížeče nebo celý profil. Uživatel se přihlásil na správné adrese a druhý faktor splnil bez chyby.	Spravovaný prohlížeč, omezení rozšíření, ochrana koncového bodu, chráněné úložiště klíčů a vazba relace na zařízení.
Chyba aplikace	Token unikne přes zranitelnost klienta, nevhodné úložiště, log, analytiku, skript třetí strany nebo kompromitovaný server.	Bezpečný návrh relace, minimální rozsah tokenu, žádné tokeny v logu, ochrana proti škodlivému skriptu a rychlé zneplatnění.
Zneužitý souhlas aplikaci	Uživatel udělí škodlivé aplikaci oprávnění a ta si získá vlastní přístup. To není krádež relace, ale v incidentu může vypadat podobně a přežít běžné odhlášení.	Řízení souhlasů, omezení oprávnění, kontrola vydaných grantů a jejich samostatné odvolání.

Modelový případ z praxe: platný kód, platná cookie, cizí prohlížeč

Následující případ je složený z opakujících se vzorců veřejně popsaných kampaní a incidentní praxe. Finanční pracovník otevře odkaz na stránku, která věrně zobrazuje přihlášení ke cloudové poště. Stránka v reálném čase předává komunikaci skutečné službě. Uživatel zadá heslo, opíše jednorázový kód a ve skutečné službě vznikne platná relace.

Podvržená brána zachytí odpověď služby včetně cookie. Útočník ji vloží do vlastního prohlížeče a otevře poštu. Nové interaktivní přihlášení už nemusí vzniknout, protože aplikace vidí platnou relaci s tvrzením, že více faktorů bylo splněno. Ve zveřejněném sledování jedné takové kampaně navazovala podvodná práce s poštou v nejrychlejších případech během pěti minut.

Poznámka z praxe: tým, který sleduje jen neúspěšná přihlášení a výzvy MFA, může přehlédnout nejdůležitější část. Podezřelá aktivita začne až v aplikačním auditu: nové pravidlo pošty, otevření finanční konverzace, stažení příloh nebo odeslání odpovědi z již ověřené relace.

CO Z TOHO NEPLÝVÁ

MFA není zbytečné. Zásadně omezuje útoky s pouhým heslem. Je však potřeba rozlišovat metody, které lze přeposlat přes podvrženou bránu, od metod vázaných na skutečnou internetovou adresu služby. Pro kritické účty má být cílem ověření odolné proti phishingu, nikoli jen libovolný druh druhého faktoru.

Passkey řeší první polovinu problému, ne celý problém

FIDO a WebAuthn vážou ověření ke skutečnému původu služby. Autentizátor nevydá podvržené stránce podpis určený pro jinou doménu a soukromý klíč neopustí autentizátor. Tím se typický scénář s reverzní phishingovou bránou výrazně láme.

Po úspěšném přihlášení ale aplikace stále může vydat běžnou přenositelnou cookie. Pokud infostealer získá tuto cookie z legitimního prohlížeče, passkey nebyl prolomen a jeho klíč nebyl ukraden. Útočník pouze převzal stav, který vznikl až po správném ověření.

Proto se rozvíjejí mechanismy, které doplňují silné přihlášení o nepřenositelnou relaci. Pro webové relace jde například o zařízení vázané přihlašovací údaje relace. Pro OAuth existuje standard DPoP, ve kterém klient při použití tokenu prokazuje držení odpovídajícího soukromého klíče. Samotná znalost řetězce tokenu pak nestačí.

ARCHITEKTONICKÉ PRAVIDLO

Čím vyšší dopad má zneužití účtu, tím méně smí zabezpečení spoléhat na přenositelný token na doručitele. Silné přihlášení má doplňovat vazba relace na zařízení nebo klíč a nové ověření před citlivou operací.

Cookie, přístupový token a obnovovací token nejsou totéž

Při reakci na incident je nutné zjistit, co přesně útočník získal. Obecný pokyn „odvolejte token“ nestačí, protože jednotlivé typy mají jiného vydavatele, jinou životnost a jiný způsob zneplatnění.

Položka	K čemu slouží	Co je nutné při incidentu
Cookie aplikace	Udržuje přihlášení mezi prohlížečem a konkrétní webovou aplikací. Často funguje jako tajemství na doručitele.	Zneplatnit relaci na serveru aplikace. Odhlášení pouze u poskytovatele identity nemusí stačit.
Přístupový token	Opravňuje klienta volat určité rozhraní pro konkrétní zdroj a rozsah.	Počítat s jeho platností do expirace, pokud služba nepodporuje průběžné vyhodnocení, introspekci nebo jiné rychlé odvolání.
Obnovovací token	Umožňuje získávat nové přístupové tokeny bez další interakce uživatele.	Odvolat u vydavatele, zkontrolovat rotaci a případné opakované použití staršího tokenu.
Zařízení pro jednotné přihlášení	Pomáhá zařízení získávat tokeny pro více služeb. Může být chráněné hardwarem a stavem zařízení.	Posoudit kompromitaci zařízení, případně jej zakázat a znovu důvěryhodně zaregistrovat.
Identitní token	Předává klientovi tvrzení o identitě. Není určen jako oprávnění k volání cizího rozhraní.	Ověřit, že jej aplikace chybně nepřijímá jako přístupový token a kontroluje vydavatele, publikum a časovou platnost.

Dobře nastavená cookie je základ, nikoli vazba na zařízení

Atributy Secure, HttpOnly a SameSite mají přesný a omezený účel. Secure brání odeslání cookie přes nezabezpečený přenos. HttpOnly znemožní běžnému skriptu přečíst hodnotu cookie, ale prohlížeč ji stále připojí k požadavku a škodlivý proces s přístupem k úložišti nebo paměti ji může získat jinou cestou. SameSite omezuje posílání cookie v požadavcích z jiného webu a pomáhá proti podvržení požadavku, nikoli proti přehrání již ukradené hodnoty.

Také časové limity mají své hranice. Nečinnost útočníka omezí doba nečinnosti, ale aktivní útočník si může relaci udržovat. Absolutní konec relace zmenší maximální okno útoku, přesto musí být vynucen na serveru. Příliš krátká relace bez rozlišení rizika zase vede k únavě uživatelů a obcházení pravidel.

Poznámka z praxe: bezpečnostní kontrola často skončí u hodnot cookie atributů. To ověří hygienu prohlížeče, ale neodpoví na důležitější otázku: přijme server stejnou cookie z druhého zařízení a umí ji správce okamžitě zneplatnit?

Proč změna hesla nemusí incident ukončit

Ve federovaném prostředí existují nejméně dvě relace: relace u poskytovatele identity a relace, kterou po přihlášení vydala cílová aplikace. Ve skutečnosti jich bývají desítky. Každá cloudová služba může mít vlastní cookie, vlastní obnovovací mechanismus a vlastní okamžik, kdy znovu ověří stav uživatele u poskytovatele identity.

Pokud aplikace svou cookie stále považuje za platnou, změna hesla u poskytovatele identity ji automaticky neodstraní. Centrální odvolání může zastavit vydávání nových tokenů a zneplatnit obnovovací tokeny, ale cookie vydanou aplikací musí často ukončit sama aplikace. Průběžné vyhodnocení přístupu zkracuje prodlevu pouze u klientů a služeb, které tento mechanismus skutečně podporují.

Modelový případ z praxe: passkey obstál, reakce selhala

Uživatel se přihlásí passkey na správné adrese. Později ochrana koncového bodu odhalí infostealer, který kopíroval data prohlížeče. Podpora změní heslo a považuje incident za uzavřený. Útočník však už používá cookie jedné obchodní aplikace, která má vlastní dlouhou relaci a centrální odvolání nekontroluje.

V protokolu poskytovatele identity nemusí být nové interaktivní přihlášení. Podezřelé operace se objeví pouze v aplikačním auditu. Správný závěr není „passkey nefunguje“, ale „organizace neuměla vyjmenovat a ukončit všechny relace vydané kompromitovanému uživateli“.

REAKČNÍ PRAVIDLO

Reset hesla je pouze jeden zásah. Incident s ukradenou relací končí až tehdy, když jsou zneplatněny relace u poskytovatele identity i v kritických aplikacích, odstraněna persistence a vyčištěno původní zařízení.

Osm vrstev, které dávají MFA smysl i po přihlášení

Vrstva	Co má organizace požadovat	Omezení a kompromis
1. Silné přihlášení	FIDO, WebAuthn, certifikát nebo jinou metodu odolnou proti phishingu pro privilegované a významné účty.	Nechrání obyčejnou přenositelnou cookie po kompromitaci zařízení.
2. Důvěryhodné zařízení	Spravovaný stav, ochranu koncového bodu, omezená rozšíření a řízený prohlížeč.	Osobní a nespravovaná zařízení zvyšují plochu útoku i snižují viditelnost.
3. Hygiena relace	Bezpečné atributy cookie, minimální rozsah, bezpečné serverové úložiště a žádné tokeny v logu či adrese.	Brání úniku vybranými cestami, nikoli každému přehrání relace.
4. Čas a nové ověření	Dobu nečinnosti, absolutní konec relace a čerstvé ověření před změnou příjemce platby, novým faktorem nebo administrátorskou akcí.	Příliš časté výzvy snižují použitelnost. Citlivé kroky je proto nutné rozlišit.
5. Vazba na odesílatele	Vazbu tokenu nebo relace na klíč a zařízení, kde ji klient i služba podporují.	Pokud útočník získá token i klíčový materiál z kompromitovaného klienta, ochrana slábne.
6. Průběžné hodnocení	Reakci na zakázání účtu, změnu rizika, stav zařízení a neobvyklé použití bez čekání na dlouhou expiraci.	Vydavatel, klient i cílová služba musí předávat a respektovat stejné signály.
7. Inventář a odvolání	Jedno místo, ze kterého lze dohledat aktivní relace, a zdokumentovaný postup pro jejich ukončení v každé kritické aplikaci.	Centrální poskytovatel identity nemůže zaručit odvolání cookie, kterou samostatně vydala aplikace.
8. Detekce následků	Korelaci identity, zařízení, relace a aplikační akce, včetně změn pošty, grantů a administrátorských oprávnění.	Samotná změna adresy nebo prohlížeče je signál, nikoli důkaz. Útočník může napodobit běžný kontext.

Co má vidět detekce, když nevznikne nové přihlášení

Klíčem je korelovat životní cyklus konkrétní relace, nikoli jen uživatelský účet. Aplikace by měla zaznamenat vytvoření, obnovení, změnu oprávnění a zničení relace. Do logu nepatří samotný token. Pro bezpečnou korelaci lze použít jeho vhodně chráněný otisk.

Zdroj	Užitečný signál	Co může chybět
Poskytovatel identity	Úspěšné přihlášení následované použitím z jiného zařízení, sítě nebo neobvyklého klienta.	Přehrání aplikační cookie nemusí vyvolat nové přihlášení ani nový token.
Koncový bod	Přístup cizího procesu k databázi cookies, paměti prohlížeče nebo úložišti přihlašovacích údajů.	Legitimní nástroje a zálohy mohou vypadat podobně. Je nutná procesní a časová korelace.
Aplikace	Současné použití jedné relace z rozdílných kontextů, změna citlivého nastavení bez čerstvého ověření a neobvyklé stahování.	Pokud aplikace neloguje identifikátor relace, zůstane jen neurčité chování uživatele.
Pošta a spolupráce	Nová pravidla, skryté přesuny zpráv, přesměrování, změna podpisu a odpovědi ve finančních vláknech.	Útočník může pracovat pomalu a ve stejném čase jako uživatel.
Řídicí rovina	Nová ověřovací metoda, registrace zařízení, souhlas aplikaci, API klíč nebo změna role po rizikové relaci.	Zneplatnění původní cookie neodstraní nově vytvořený trvalejší přístup.

Poznámka z praxe: nemožné cestování a odlišná adresa jsou dobrý začátek, ale slabý důkaz. Útočníci používají blízkou infrastrukturu a napodobují typ prohlížeče. Silnější je sled událostí: přístup k cookies na zařízení, použití relace v novém kontextu a následná citlivá změna v aplikaci.

Reakční postup pro ukradenou relaci

Postup musí být připravený před incidentem. Za běhu už není čas zjišťovat, která aplikace má vlastní odhlášení, která umí zneplatnit všechny relace uživatele a která vyžaduje ruční zásah dodavatele.

Krok	Akce	Výsledek, který je nutné ověřit
1. Vymezit incident	Určit účet, zařízení, typ relace, aplikace, časové okno a oprávnění.	Tým ví, zda řeší cookie aplikace, přístupový token, obnovovací token nebo kompromitaci zařízení.
2. Izolovat zařízení	Odpojit kompromitovaný bod a před vymazáním uchovat potřebné volatilní a diskové stopy.	Další tokeny neodcházejí a vyšetřování neztratilo paměť procesů či profil prohlížeče.
3. Zastavit vydávání	Podle dopadu zakázat účet nebo zařízení, odvolat obnovovací tokeny a centrální relace, změnit kompromitované přihlašovací údaje.	Uživatel ani útočník nezískají nové tokeny bez kontrolovaného obnovení důvěry.
4. Ukončit aplikace	Zneplatnit vlastní relace v poště, úložišti, ERP, správě zdrojového kódu, finančních a administrátorských systémech.	Staré cookies jsou serverem odmítnuty, nikoli jen odstraněny z legitimního prohlížeče.
5. Odstranit persistenci	Prověřit pravidla pošty, přesměrování, nové faktory, zařízení, souhlasy aplikacím, klíče, tokeny a změny rolí.	Útočník nemá jinou cestu, která přežije odvolání původní relace.
6. Vyčistit a obnovit	Odstranit malware nebo znovu připravit zařízení, obnovit důvěryhodnou registraci a vydat nové relace.	Nové tajemství nevzniká na stále kompromitovaném zařízení.
7. Ověřit uzavření	Zopakovat pokus se zneplatněnou relací, zkontrolovat aplikační audit a sledovat účet po obnovení.	Tým má technický důkaz, že stará relace i následná persistence přestaly fungovat.

Metriky, které mají smysl pro vedení

Počet účtů s MFA je důležitý, ale neříká nic o tom, co se děje po přihlášení. Pro kritické služby je vhodné doplnit nejméně následující ukazatele.

Pokrytí odvoláním: podíl kritických aplikací, ve kterých lze vyjmenovat a zneplatnit všechny relace uživatele.
Čas do úplného zneplatnění: doba od potvrzení incidentu po prokazatelné odmítnutí starých relací poskytovatelem identity i aplikacemi.
Podíl nepřenositelných relací: kolik privilegovaných a významných přístupů je vázáno na zařízení nebo klíč.
Čerstvé ověření citlivých akcí: kolik změn faktoru, platebního cíle, oprávnění a klíčů vyžaduje nové ověření s jasným účelem.
Doba detekce přehrání: jak rychle organizace spojí ukradenou relaci s neobvyklou aplikační aktivitou.

METRIKA PRO VEDENÍ

Neptejte se pouze, zda mají lidé MFA. Ptejte se, za kolik minut bezpečnostní tým prokazatelně ukončí všechny relace kompromitovaného účtu v pěti nejkritičtějších službách.

Nejpřesnější odpověď dá řízený test

Jednou za čtvrtletí lze na schváleném testovacím účtu vytvořit relace v poskytovateli identity a několika kritických aplikacích. Tým dostane hlášení o ukradené cookie a musí bez znalosti připraveného scénáře zjistit, kde jsou relace aktivní, které centrální odvolání ukončí a které je nutné zneplatnit v aplikaci.

Test má skončit opakovaným použitím staré cookie nebo tokenu. Teprve odmítnutí serverem dokazuje, že relace skončila. Prázdný prohlížeč, změněné heslo nebo zelený stav v jedné konzoli tento důkaz nenahrazují.

MFA může fungovat přesně podle návrhu a incident přesto pokračovat. Skutečná otázka zní, zda organizace umí chránit, sledovat a ukončit stav, který vznikne po úspěšném přihlášení.

PRAKTICKÝ TEST

Vezměte testovací účet, vytvořte relaci v pěti kritických službách a spusťte incidentní postup. Pokud tým neumí všechny relace vyjmenovat, zneplatnit a ověřit jejich odmítnutí, MFA chrání jen vstupní dveře.