1data Solutions

Microsoft 365-fiókátvétel MFA mellett: mit mutat a Microsoft új figyelmeztetése?

Biztonság

Egy váratlan passkey-beállítási kérésből céges fiókátvétel és dokumentumletöltés is lehet. Megmutatjuk, hogyan kapcsolódnak össze a gyanús bejelentkezés, az új hitelesítési mód és a felhőben végzett adatgyűjtés jelei.

2026. szeptember 14.6 perc olvasás
Biztonsági szakember céges bejelentkezési és felhőtevékenységi jeleket vizsgál, miközben egy munkatárs a telefonját ellenőrzi

Egy sürgős passkey-kérésből indulhat a Microsoft 365-fiókátvétel

Egy kolléga telefonon kap üzenetet: az informatikai ügyfélszolgálat szerint ma frissíteni kell a belépési módját, különben akadozhat a munkája. A hivatkozás cégesnek látszik, a következő képernyőn pedig akár valódi Microsoft-bejelentkezés fogadhatja. Ilyenkor nehéz azonnal felismerni, hogy a jóváhagyás valójában kinek ad hozzáférést.

A Microsoft 2026. szeptember 9-én olyan aktív felhős támadássorozatról számolt be, amelyben a gyanús bejelentkezést új, támadó által felvett hitelesítési mód, Microsoft Graph-lekérdezések, majd SharePoint-, OneDrive- és esetenként levelezési adatgyűjtés követte. A megfigyelt tevékenység 2026 májusa óta zajlik. Több különböző kezdő lépést és vizsgált esetet írnak le, ezért ezek nem egyetlen minden áldozatnál azonos támadási forgatókönyv állomásai.

Hogyan jut be a támadó, ha az MFA be van kapcsolva?

A támadó gyakran informatikai segítségnek álcázza magát. Azt mondja, a passkeyt, a többtényezős hitelesítést vagy a központi belépést kell sürgősen beállítani. A „passkey” szó itt sokszor csak ürügy: a Microsoft vizsgálatai többféle hozzáférésszerzést találtak a hasonló csalik mögött.

Az egyik változat az eszközkódos adathalászat. A munkatárs egy valódi Microsoft-hitelesítési oldalon ír be egy kapott kódot, de a belépési folyamatot a támadó indította. A jóváhagyás után a támadó klienséhez tartozó hozzáférési token használható az engedélyezett erőforrásokhoz. Itt nem feltétlenül lopják el a jelszót; ha viszont az alkalmazott nincs már bejelentkezve, a valódi belépés során jelszót és MFA-jóváhagyást is kérhet a szolgáltatás.

Más esetben közbeékelődő, úgynevezett AiTM-adathalászat történik: a hamis oldal közvetít a felhasználó és a valódi bejelentkezés között, így belépési adatokat és munkamenet-tokeneket szerezhet. A Microsoft egy harmadik mintát is leírt, ahol a támadó korábban megszerzett belépési adatokat használt, és egy már korábban regisztrált hitelesítő alkalmazással teljesítette az MFA-t. Ezeket nem szabad egyetlen „jelszó nélküli MFA-bypass” állítássá összemosni.

Az új hitelesítési mód tartósabb hozzáférést adhat

A kezdeti bejutás után a Microsoft által vizsgált támadók új telefonszámot, hitelesítő alkalmazást vagy szoftveres egyszer használatos kódot vettek fel a kompromittált felhasználóhoz. Ezzel a későbbi hitelesítési kéréseket saját eszközükkel teljesíthetik. Ezért egy ismeretlen MFA-módszer felvétele sokkal súlyosabb jel, mint egy önmagában szokatlan IP-cím.

A hozzáadott módszer nem jelent örök és feltétel nélküli belépést. A Microsoft szerint önmagában nem éli túl a teljes hitelesítőadat- és munkamenet-visszaállítást; a még érvényes tokenekkel, munkamenetekkel vagy megszerzett jelszóval együtt viszont megerősítheti a támadó jelenlétét. Emiatt egy gyanús fióknál a jelszócsere egymagában nem lezárt incidens.

A Microsoft Graph után a dokumentumok és a levelek következhetnek

A Microsoft Graph az a hivatalos felület, amelyen alkalmazások felhasználókat, csoportokat és a jogosultságukhoz tartozó Microsoft 365-adatokat kérdezhetnek le. A támadó a kompromittált fiók hozzáférésével feltérképezheti a szervezetet, az adminisztratív szerepeket, az alkalmazásokat, a SharePoint-helyeket és a OneDrive-tárhelyet. A hozzáférés terjedelmét a fiók és az alkalmazás tényleges jogosultságai korlátozzák; ettől még egy túl széles hozzáférésű fiók komoly üzleti kárt okozhat.

A vizsgált esetekben a felderítést tömeges SharePoint- és OneDrive-fájlhozzáférés, letöltés, egyes esetekben Exchange Online-levelek gyűjtése követte. A Microsoft szerint az adatgyűjtés órákon át vagy akár több napon keresztül tarthatott. Egy ügyfélszerződés, ajánlat, belső költségvetés vagy levelezési melléklet elvesztése után a kérdés már nem csak az, hogy ki lépett be: azt is tisztázni kell, milyen üzleti adatokhoz férhetett hozzá.

Egyetlen normálisnak tűnő művelet helyett az eseménysort nézzük

Egy felhasználókat felsoroló Graph-lekérdezés vagy egy SharePoint-fájlletöltés önmagában lehet hétköznapi munka. Gyanússá a sorrend válik: szokatlan bejelentkezés után új hitelesítési mód, sokféle jogosultság- és tárhelylekérdezés, majd nagy mennyiségű fájl vagy levél elérése. A Microsoft külön IP-címeket figyelt meg a belépésnél, a felderítésnél és az adatgyűjtésnél, ezért egyetlen IP blokkolása vagy esemény önálló vizsgálata nem ad teljes képet.

A vizsgálatnak ugyanahhoz a felhasználóhoz, alkalmazáshoz és időszakhoz kell összekötnie az Entra-bejelentkezési és hitelesítésimód-változási naplókat, a Graph-tevékenységet, valamint a SharePoint, OneDrive és Exchange eseményeit. Az auditálás és a riasztások elérhetősége a szervezet beállításaitól és előfizetéseitől függhet. Ha ezek a jelek nincsenek bekapcsolva vagy senki nem nézi őket, utólag nehezebb megállapítani, mi történt.

Mit érdemes ma ellenőrizni a céges fiókoknál?

Elsőként legyen ismert út arra, hogy a munkatárs a váratlan „IT-s” telefonhívást, SMS-t, Teams-üzenetet vagy kódkérést azonnal jelezhesse. Az IT-felelős nézze át, ki és milyen feltételekkel vehet fel új hitelesítési módot, szükséges-e egyáltalán az eszközkódos belépés, és mely fiókok férhetnek hozzá érzékeny fájlokhoz vagy adminisztratív funkciókhoz.

  • Ellenőrizzük a szokatlan bejelentkezések után felvett telefonokat, hitelesítő alkalmazásokat és új eszközöket.
  • A valóban szükséges kivételek megtartásával korlátozzuk az eszközkódos hitelesítést és az új biztonsági adatok regisztrálását feltételes hozzáférési szabályokkal.
  • Ahol lehetséges, vezessünk be adathalászattal szemben ellenálló hitelesítést, például eszközhöz kötött passkeyt vagy FIDO2-kulcsot.
  • Kapcsoljuk össze a bejelentkezési, Graph-, fájlletöltési és levelezési jeleket; különösen a hirtelen megváltozó mennyiséget és sorrendet figyeljük.

Ha felmerül a fiókátvétel gyanúja, az érintett fiókot és a hozzáférhető adatok körét incidensként kell vizsgálni. Megerősített kompromittálásnál a Microsoft az aktív munkamenetek és frissítőtokenek visszavonását, a hitelesítő adatok visszaállítását, az idegen hitelesítési módok és támadói levélszabályok eltávolítását, majd a módszerek biztonságos újraregisztrálását javasolja. A műveleteket a tenant felelős adminisztrátora végezze, az események és az érintett adatok rögzítésével.

A fiókbiztonság az üzleti adatok útján dől el

Ha a cég Microsoft 365-fiókjai ajánlatokat, szerződéseket, ügyféladatokat vagy belső jóváhagyásokat érnek el, érdemes a jogosultságokat és a bejelentkezési rendet együtt áttekinteni. Pontosan ki kezeli a fiókokat, hol látszik egy új MFA-módszer, ki kap riasztást a gyanús letöltésről, és ki tudja visszavonni a hozzáférést, ha az alkalmazott már jóváhagyott egy idegen kérést?

Az 1data informatikai kockázatfelmérésben és külső IT-menedzsmentben ezeknek a felelősségi és hozzáférési kérdéseknek a tisztázásában tud segíteni. A tenant konkrét naplóit és biztonsági beállításait a jogosult rendszergazdával együtt érdemes ellenőrizni, különösen akkor, ha már kompromittálás gyanúja merült fel.

További olvasnivaló

Fejlesztők és üzleti döntéshozó API metódusokat és lekérdezési folyamatokat terveznek egy tárgyalóban
Fejlesztés2026. július 5.6 perc olvasás

GET, POST vagy QUERY? Mit jelent az új HTTP metódus az üzleti API-kban?

Az RFC 10008 új HTTP QUERY metódusa jó apropó arra, hogy tisztábban beszéljünk az API-tervezésről. Egy üzleti integrációnál nem mindegy, mi olvas adatot, mi módosít állapotot, mi próbálható újra biztonságosan, és mit lehet később hibakeresni.

Elolvasom
IT szakember WordPress plugin frissítést tesztel staging környezetben cégvezetővel
WordPress2026. június 23.6 perc olvasás

WordPress frissítés előtt: melyik plugin fogja megtörni az oldalt?

A WordPress 7.0 utáni fejlesztői változások, a Gutenberg tesztelési körök és a React 19 körüli kompatibilitási munka jól mutatják: egy céges WordPress oldalt frissítés előtt tesztelni kell. A valódi kérdés az, hogy az ajánlatkérés, fizetés, admin és szerkesztés működik-e utána is.

Elolvasom
1data Solutions
Megbízható Internet Megoldások
2026 © 1data Solutions