A legtöbb szervezet évek óta ugyanazokat az óvintézkedéseket tanítja az alkalmazottaknak: ellenőrizd a webcímet, keress gyanús domain-nevet, nézd meg, hogy HTTPS-e az oldal. Egy 2026 nyarán azonosított adathalász kampány azonban pont ezen tanácsok mindegyikét teszi feleslegessé – ugyanis a támadók a valódi Microsoft bejelentkezési oldalát használják fel, és jelszót egyáltalán nem is lopnak.
Valódi Microsoft-oldal, hamis szándék – így működik a consent phishing
A Check Point e-mail-biztonsági kutatócsoportja tárta fel azt a kampányt, amely 2026 júniusának végétől július elejéig volt aktív. Az elemzés szerint több mint 200 adathalász e-mailt azonosítottak, amelyek mintegy 120 szervezet felhasználóit célozták meg világszerte.
A módszer lényege, hogy a támadók nem hamisítanak Microsoft-oldalt – hanem a Microsoft saját OAuth-alapú engedélyezési rendszerét fordítják a felhasználók ellen. Az eljárást „consent phishing” (hozzájárulás-adathalászat) névvel illetik a szakemberek.
A folyamat lépései a következők:
- Az áldozat egy hamis Microsoft Planner feladatértesítőre hasonlító e-mailt kap. A feladó neve „There’s New Activity On Team”, a tárgysor szerint az HR három üzenetet küldött Teams-csevegésen keresztül, a levél törzse pedig bérezési és juttatási frissítésre hivatkozik, négy lejárt feladattal együtt.
- Az e-mailben szereplő minden link – beleértve mindkét cselekvésre hívó gombot – ugyanazon az átirányításon keresztül vezet, és a látható küldő cím a saját szervezet domain-jéhez tartozik, azaz úgy néz ki, mintha az áldozat saját magának küldött volna levelet.
- A linkre kattintva a felhasználó egy valódi OAuth-engedélyezési URL-re kerül a login.microsoftonline.com domainen – nem egy hasonló nevű, hamisított oldalra.
- Bejelentkezés után Microsoft egy engedélykérő ablakot jelenít meg, amelyben egy támadók által irányított alkalmazás kér hozzáférést a felhasználó adataihoz.
- Ha a felhasználó jóváhagyja (vagy szervezete nevében elfogadja) a kérést, a Microsoft a böngészőt átirányítja a kérelemben megadott visszairányítási URL-re – jelen kampányban ez egy AWS API Gateway-végpont volt, amelyet a támadók irányítottak.
- Az engedélyezési kód erre a végpontra érkezik, a támadók ezt hozzáférési tokenre cserélik – és máris beléptek a fiókba.
Milyen adatokhoz férnek hozzá, és miért nem véd a kétlépéses azonosítás?
A jogosulatlanul megadott engedélyek révén a támadók hozzáférést szereznek az áldozat e-mailjéhez, fájljaihoz, Teams-üzeneteihez, SharePoint- és OneDrive-tartalmához, valamint naptárához – mindezt anélkül, hogy egyetlen jelszót is elloptak volna.
A többfaktoros hitelesítés (MFA) sem nyújt védelmet ebben az esetben. Az MFA a bejelentkezési folyamatot védi, nem pedig a bejelentkezés utáni adathozzáférést. A támadónak soha nincs szüksége sem a jelszóra, sem a második azonosítási tényezőre: a felhasználó érvényes munkamenete által kiadott tokent szerzi meg. Ez az alapvető különbség teszi ezt a módszert rendkívül veszélyessé a hagyományos adathalász elleni védelemmel szemben.
A Check Point megjegyzi, hogy a technika abban is különbözik például a Kali365 nevű, phishing-as-a-service platformtól, hogy ahelyett, hogy munkamenet-sütiket vagy OAuth-tokeneket lopna, tartós, jogszerűnek tűnő hozzáférési engedélyt szerez a felhasználó beleegyezésével.
Miért nem fogja ki ezt a szokásos biztonsági tréning?
A hagyományos figyelmeztető jeleket – gyanús domain, hiányzó lakat, elgépelt URL – itt egyszerűen nem lehet alkalmazni. A domain és a tanúsítvány a Microsofté, a bejelentkezési oldal ugyanaz, amelyet a felhasználó minden reggel lát. Ez hamis biztonságérzetet kelt annál, aki nem ismeri ezt a konkrét támadási vektort.
Mégis volt néhány árulkodó jel, amelyet egy biztonsági szakértő észrevett volna:
- Az e-mailben szereplő összes link ugyanazon az átirányításon vezet keresztül.
- A feladó látható e-mail-címe a saját szervezet domainjéhez tartozik – azaz a levél úgy néz ki, mintha az áldozat saját magától érkezett volna.
- Az engedélykérő ablak egy ismeretlen, külső alkalmazás nevében kér széles körű hozzáférést.
Védekezés: nem a felhasználón, hanem a rendszeren múlik
A Check Point két fő védekezési irányt javasol. Az első – és kevésbé megbízható – lehetőség az, hogy a felhasználók minden engedélykérő ablakot gondosan átnéznek, mielőtt jóváhagyják azt, hiszen a támadáshoz szükség van a felhasználó aktív közreműködésére. A második, hatékonyabb megoldás rendszergazdai szinten kezeli a problémát:
- A Microsoft Entra segítségével korlátozható, hogy alkalmazások milyen engedélyeket kérhetnek felhasználói fiókoktól.
- Az alkalmazás-hozzájárulási szabályzatok beállításával megakadályozható, hogy felhasználók saját döntésükből adjanak hozzáférést ismeretlen, külső alkalmazásoknak.
A Check Point hangsúlyozza, hogy bár ez a konkrét kampány már nem aktív, az alkalmazott technika korántsem számít elavultnak. Sőt, a kutatók szerint 2026-ra a módszer bérelhető szolgáltatássá (commoditized, rentable service) vált, ami azt jelenti, hogy bármely alacsony technikai tudással rendelkező bűnöző is igénybe veheti. A szervezetek számára az adminisztratív szintű hozzáférés-korlátozás legalább minimális szinten mindenképpen ajánlott lépés.
Gyakori kérdések
Mi az a consent phishing, és miben különbözik a hagyományos adathalászattól?
A consent phishing során a támadó nem jelszót lop, hanem a felhasználót ráviszi, hogy egy valódi OAuth-engedélyezési felületen maga adjon hozzáférést egy támadók által irányított alkalmazásnak. Nem kell hamisított oldal, és a kétlépéses azonosítás sem véd ellene, mivel a hozzáférési token a felhasználó érvényes munkamenetéből származik.
Milyen adatokhoz juthatnak hozzá a támadók, ha az áldozat jóváhagyja az engedélyt?
A Check Point szerint a kampányban érintett engedélyek kiterjedtek az e-mailekre, fájlokra, Teams-üzenetekre, SharePoint- és OneDrive-tartalmakra, valamint a naptárra is – mindezt jelszó megszerzése nélkül.
Hogyan lehetett volna azonosítani ezt a konkrét adathalász e-mailt?
Két jellemző árulkodó jelet azonosított a Check Point: az e-mailben minden link ugyanazon az átirányításon futott keresztül, illetve a feladó látható e-mail-címe a saját szervezet domainjéhez tartozott, vagyis úgy tűnt, mintha az áldozat önmagának küldte volna a levelet.
Mit tehetnek a szervezetek a védekezés érdekében?
A leghatékonyabb védekezési lépés rendszergazdai szinten, a Microsoft Entra segítségével korlátozni, hogy alkalmazások milyen engedélyeket kérhetnek felhasználói fiókoktól. Ez nem a felhasználó éberségére bízza a védelmet, hanem rendszerszinten zárja el a támadási lehetőséget.
Forrás: TechRadar
