Keď správna doména nestačí

E-mail s faktúrou, žiadosťou o ponuku (RFP) alebo zdieľaným dokumentom môže viesť až na pravú stránku microsoft.com/devicelogin. Výskum Microsoftu z 6. apríla 2026 opísal device-code phishing: útočník si pripraví reláciu a obeť potom jej kód zadá na oficiálnom portáli. Potvrdením mu schváli prístup – heslo mu pritom nikdy nedá. Ide o dátum zverejnenia výskumu, nie o začiatok kampane. Zdroj: Microsoft Security Blog

Device-code flow je legitímny OAuth mechanizmus pre zariadenia s obmedzenými možnosťami zadávania údajov, napríklad televízor alebo tlačiareň. Používateľ otvorí prehliadač na inom zariadení, prihlási sa a klient priebežne čaká na výsledok. Dokumentácia Microsoftu uvádza, že predvolená platnosť kódu je 15 minút a pri úspechu klient dostane tokeny v rozsahu požadovaných oprávnení. Zdroj: Microsoft Learn

Porovnanie dvoch tokov: pri bežnom použití prihlásenie začne televízor a prístup dostane on; pri phishingu kód pošle útočník, obeť ho zadá na pravom microsoft.com a prístup dostane útočník.
Rovnaká stránka, iný príjemca prístupu – rozhoduje, kto prihlásenie začal. Schéma SXIZA.

Pre firemné školenie z toho vyplýva jedna konkrétna otázka: dokáže zamestnanec rozlíšiť prihlásenie, ktoré začal sám, od požiadavky, ktorú mu poslal niekto cudzí? Presne toto odporúčame nacvičovať. Overovanie má zostať, ľudia sa však popri ňom majú naučiť pozrieť sa na účel požiadavky skôr, než ju potvrdia.

Naša analýza: overujte účel autorizácie

Bezpečnostná rada „skontrolujte adresu“ tu nie je chybná, iba neúplná. Kontrolou domény overujeme identitu stránky, nie to, kto založil práve autorizovanú reláciu a aká aplikácia dostane prístup. Užitočná otázka pred vložením kódu z nevyžiadaného e-mailu je: Na ktorom mojom zariadení sa má teraz aktivovať prístup a pre akú konkrétnu aplikáciu? Ak na ňu zamestnanec nevie odpovedať, má proces prerušiť a overiť požiadavku mimo doručeného odkazu.

Namiesto toho, aby bolo prihlasovanie cez device-code flow automaticky povolené všetkým, je praktickejšie povoľovať ho podľa potreby. Zostavte zoznam aplikácií a zariadení, ktoré ho naozaj vyžadujú, vlastníka každého prípadu, požadované oprávnenia a dátum ďalšieho preskúmania. Pre ostatných používateľov je rozumné tok blokovať alebo obmedziť podmieneným prístupom; Microsoft odporúča povoliť ho len tam, kde je nutný. Pred vynútením pravidla overte jeho dosah v režime report-only a zdokumentujte úzke výnimky. Zdroj: Microsoft Learn

Dohodnite sa, ako zamestnanec nahlási podozrivú požiadavku a kto mu odpovie, keď nevie, či môže pokračovať. V modelovom cvičení nechajte podporu pracovať iba s údajmi, ktoré bežne dostáva od používateľa. Sledujte, či dokáže správne určiť zodpovedný tím a odovzdať mu zrozumiteľný záznam. Do výsledku zapíšte, kde chýbal kontakt, právomoc alebo vysvetlenie. Z takého pozorovania sa postup zlepší oveľa spoľahlivejšie než z počtu ľudí, ktorí školením prešli.

Pri podozrení pracujte s dôkazmi konkrétnej relácie: používateľ, čas, aplikácia, IP adresa, rozsah udelených oprávnení a následné akcie. Zablokujte alebo vypnite kompromitovaný účet podľa závažnosti, odvolajte relácie a obnovovacie tokeny podľa možností služby, skúmajte pravidlá pošty a činnosť aplikácií. Samotný reset hesla ešte neznamená vyriešený incident: životnosť a odvolanie tokenov závisia od ich typu aj od konkrétnej aplikácie. Microsoft Learn upozorňuje, že token a relácia v aplikácii nemusia zaniknúť rovnakým krokom; pri aplikácii môže byť potrebný zásah jej správcu. Cieľom je zastaviť zneužitie, určiť rozsah a až potom bezpečne obnoviť prístup. Zdroj: Microsoft Learn

Pred zavedením pravidiel si vyžiadajte reálny zoznam zariadení, ktoré tok používajú, a u každého otestujte bežný aj núdzový postup. Výsledkom má byť rozhodnutie, nie iba technické nastavenie: povoliť, nahradiť modernejším spôsobom alebo odstaviť. Len tak sa z výnimiek nestane trvalé a neviditeľné riziko.

Pri schválenej výnimke určte aj jej koniec a zástupcu vlastníka. Ak sa používané zariadenie vyradí, zahrňte odstránenie výnimky do rovnakého pracovného postupu.

Zdroje