Egy Microsoft 365-fióknál a jelszócsere után is bent maradhat a támadó, ha a bejelentkezett munkamenetet lopta el.

Ezt írja le a Huntress 2026. október 22-i elemzése. A biztonsági cég saját közlése szerint egy támadó 79 szervezet Microsoft 365-fiókjába jutott be jelszó nélkül. Több fiókban saját MFA-módot és saját eszközt regisztrált. Ezek a Huntress szerint a jelszócsere után is a fiókon maradnak.

A kampány számai egyetlen forrásból, a Huntress blogjából származnak. Független forrás 2026. október 24-ig nem erősítette meg őket. A cég a saját ügyfelei körében látta az eseteket. Magyar érintettről az elemzés nem ír.

Mi történt július és szeptember között

A Huntress 2026. július 14. és szeptember 22. között követte a kampányt. Ez alatt 497 sikeres belépést rögzített 79 szervezetnél. Ugyanabból a címtartományból több mint 200 000 sikertelen belépési kísérlet is érkezett. A címek egy hamburgi tárhelycég, az 1337 Services GmbH tartományába tartoztak.

A támadó ellopott belépési tokeneket játszott vissza, vagyis újra felhasználta őket. A Huntress szerint a tokenek három úton kerültek hozzá: hamis belépőoldal mögötti közvetítővel, eszközkódos adathalászattal és egy valódi belépés közbeni megtévesztéssel.

A közvetítős módszer angol neve adversary-in-the-middle (AiTM). Az áldozat egy közvetítőn keresztül lép be. A közvetítő a valódi Microsoft-oldalt és az MFA-kérést is továbbítja. A sikeres belépés után a Microsoft tokent ad ki, ez igazolja a belépést. A közvetítő ezt megtartja. A token az MFA után keletkezik, ezért birtokosának nem kell újra MFA-n átmennie.

Az eszközkódos adathalászatnál az áldozat a Microsoft valódi belépőoldalán ír be egy kódot. A Huntress szerint ezzel érvényes hozzáférési és frissítő tokent ad át a támadónak.

A lopás és a felhasználás között kevés idő telt el. Egy 2026. július 21-i esetben 12 perc volt az MFA-kérés és az eltérített munkamenet megjelenése között. Szeptember 22-én 4 perc.

Ami a jelszócsere után is ott marad

A token idővel lejár, vagy visszavonják. A támadó a Huntress szerint tartós hozzáférést is kiépített.

Amit a támadó hagyott Huntress adata Mi történik jelszócserénél
Saját MFA-mód 19 szervezetnél törölte az áldozat MFA-módjait, és sajátot regisztrált A Huntress szerint megmarad, amíg valaki nem törli
Hamis eszköz a címtárban legalább 48 „DESKTOP-” kezdetű eszköz A címtárban marad, amíg valaki nem törli
Rejtett levelezési szabály egy-három karakteres vagy írásjelből álló nevek, például „s”, „d”, „sss” A Microsoft a visszaszerzés külön lépéseként kezeli

A 19 szervezetnél az MFA-csere a Huntress szerint három órán belül megtörtént az első belépéstől számítva. A hamis eszközök neve a „DESKTOP-” előtag után nyolc hexadecimális karakter volt. A Windows saját alapnevében hét karakter áll.

Egy esetben a támadó a feltört postafiókból bérszámfejtési levelet küldött egy külső könyvelőnek. Előtte átírt egy „s” nevű szabályt. Ez elrejtett minden levelet, amely a bérszámfejtést, a bérutalást, a bankot vagy a bónuszt említette. Öt perccel később egy „d” nevű szabály a könyvelő összes válaszát olvasottnak jelölte és eldugta. Az áldozat így nem látta a válaszokat.

⚠ Figyelem: ha a feltételes hozzáférés blokkol egy belépést, az a Huntress szerint érvényes hitelesítő adatra utal. A blokk ugyanis a sikeres hitelesítés után jön. A naplóban látott blokk figyelmeztető jel.

Megnéztem: mit ír a Microsoft a visszaszerzésről

2026. október 24-én elolvastam a Microsoft Learn vonatkozó oldalait. Bérlőt nem állítottam át, támadást nem próbáltam ki. A lépések a Microsoft és a Huntress saját ajánlásai.

1. A fiók letiltása. A Microsoft a vizsgálat idejére a fiók letiltását ajánlja. Ha ez nem megy, jelszócsere következik. Az új jelszót ne e-mailben kapja meg a felhasználó, mert a támadó olvashatja a postafiókot.

2. A munkamenetek visszavonása. Az útvonal: Entra ID > Users > All users, majd a felhasználó „Overview” oldala. Itt a „Revoke sessions” gomb végzi ezt. PowerShellben a Revoke-MgUserSignInSession parancs teszi ugyanezt. A Microsoft szerint ez érvényteleníti a frissítő tokeneket, és mindenhol újra belépést kér. A már kiadott hozzáférési token a lejáratáig működhet. Ennek alapértelmezett élettartama 60 és 90 perc között van. Feltételes hozzáférés nélküli bérlőben a Microsoft szerint a Teams és a Microsoft 365 kliensek tokenje alapértelmezésként két óráig él.

3. Az MFA-módok átnézése. Az Entra ID > Users menüben a felhasználót kiválasztva az „Authentication methods” menü mutatja a regisztrált módokat. Az ismeretlen MFA-módot törölni kell. A Huntress szerint a perceken belül törölt, majd újraregisztrált módok gyanúsak. A „Require re-register MFA” gomb törli a telefonszámokat, az Authenticator-alkalmazásokat és a szoftveres kódgenerátorokat.

4. Az eszközök átnézése. Az eszközlista az „Entra ID > Devices > All devices” menüjében van. Az eszköz letiltása a Microsoft szerint visszavonja az eszközön lévő frissítő tokeneket. A törlés nem vonható vissza. A Huntress is azt kéri, hogy törlés előtt ellenőrizzék a gyanús eszközt.

5. A levelezési szabályok és a továbbítás. A Microsoft a rejtett szabályokat is listázó Get-InboxRule parancsot ajánlja, „-IncludeHidden” kapcsolóval. Külön lépésként a postafiók-továbbítás ellenőrzését is kéri. A jelszócsere a Microsoft szerint az alkalmazásjelszavakat nem vonja vissza. A Huntress mintája: egy-három karakteres nevek, RSS- vagy „Conversation History” mappába mozgatás, bér- és bankszavakra szűrés.

6. Az alkalmazások és a naplók. A Microsoft a felhasználó által engedélyezett alkalmazások átnézését is kéri. A belépési naplóban az IP-cím, a helyszín, az időpont és a siker számít. Az elküldött leveleket is át kell nézni.

Megelőzés: feltételes hozzáférés és eszközhöz kötött token

A feltételes hozzáférés (Conditional Access) belépési szabályokat állít fel, például helyre vagy eszközre. A Microsoft szerint Entra ID P1 licenc kell hozzá, vagy Microsoft 365 Business Premium.

Egy szeptemberi hullámban egyetlen cím 1052 blokkolt belépést gyűjtött, mindössze négy szervezetből. A sikeres belépések más szervezeteknél történtek. A cég azt javasolja, hogy a szabály minden felhasználóra, alkalmazásra és klienstípusra feltétel nélkül kérjen MFA-t, vagy blokkoljon.

Az eszközkódos belépést a Microsoft magas kockázatúnak nevezi. Ahol lehet, blokkolását javasolja feltételes hozzáférési szabállyal. A Huntress ugyanezt ajánlja.

A tokenvédelem (Token Protection) a feltételes hozzáférés egyik beállítása. A Microsoft szerint csak az eszközhöz kötött tokent fogadja el, így a lopott token más gépről nem használható. Natív alkalmazásoknál az Exchange Online, a SharePoint Online és a Teams védhető vele. Windowson általánosan elérhető. Mac, iPhone és iPad esetén csak felügyelt (MDM-mel kezelt) eszközt támogat. Ezt a részt a Microsoft előzetes változatként írja le. Böngészőben csak az Azure-kezelőfelületet védi, a webes Outlookot nem. A Microsoft előbb csak naplózó módot és kis tesztcsoportot javasol.

Négy kérdés az IT-partnernek

  1. Le tudja-e tiltani a fiókot és visszavonni a munkameneteket egy órán belül? Kérdezze meg, ki fér hozzá ehhez hétvégén.
  2. Átnézte-e a regisztrált MFA-módokat és eszközöket? Kérje a „DESKTOP-” kezdetű, ismeretlen eszközök listáját.
  3. Van-e feltételes hozzáférési szabály, és tiltva van-e az eszközkódos belépés? Kérdezze meg azt is, milyen licenc van a cégnél.
  4. Ki nézi a rejtett levelezési szabályokat? Különösen a pénzügyi és a bérszámfejtési postafiókokat.

Ördög ügyvédje

A Huntress biztonsági szolgáltatást árul, és a saját ügyfeleinél mért. A 79 szervezet az általa kezelt esetek száma, nem a kampány teljes mérete. Az elemzés két helyén két eltérő szám szerepel ugyanarra a szeptemberi hullámra.

A Huntress szerint a jól beállított feltételes hozzáférés megelőzi a token-visszajátszást. A kampány egyik eszköze viszont böngészős munkameneteket játszott vissza. A tokenvédelem a Microsoft szerint a böngészős Outlookot nem védi, böngészőben csak az Azure-kezelőfelületre terjed ki. A licenc is feltétel: P1 vagy Business Premium nélkül feltételes hozzáférés nincs.

A saját ellenőrzésem korlátja: dokumentációt olvastam, élő bérlőben nem próbáltam ki a lépéseket. A menük neve és helye változhat.

A támadónak a belépéshez nem kellett jelszó. A takarítás ezért az MFA-módoknál, az eszközöknél és a szabályoknál kezdődik.

Gyakori kérdések

Mi a token-visszajátszás? A támadó egy ellopott belépési tokent használ fel újra a saját gépéről. Jelszó és újabb MFA nélkül jut be vele.

Elég a jelszócsere, ha van MFA? A Huntress szerint nem. A jelszócsere nem törli a támadó által regisztrált MFA-módot és eszközt. A munkameneteket is vissza kell vonni.

Meddig működhet az ellopott token a visszavonás után? A Microsoft szerint a hozzáférési token a lejáratáig működhet. Alapértelmezett élettartama 60 és 90 perc között van, átlagosan 75 perc. Feltételes hozzáférés nélküli bérlőben a Teams és a Microsoft 365 kliensek tokenje alapértelmezésként két óráig él.

Kell-e bejelenteni az esetet a NAIH-nak? Ha a postafiókban személyes adat volt, például bérszámfejtési levél, adatvédelmi incidens lehet. A GDPR 33. cikke szerint az adatkezelő kockázat esetén indokolatlan késedelem nélkül, lehetőleg 72 órán belül köteles bejelenteni. A határidő attól számít, hogy az incidens a tudomására jutott. A konkrét esethez jogi tanácsot érdemes kérni.

Mi a tokenvédelem? A feltételes hozzáférés egyik beállítása, amely csak az eszközhöz kötött tokent fogadja el. A Microsoft szerint natív alkalmazásoknál az Exchange Online, a SharePoint Online és a Teams védhető vele.

Források
  1. Huntress (Andrea Hatcher, Susannah Matt, Matt Poto, Andrew Schwartz): M365 Token Spray and Replay Campaign Compromises Business Email Accounts, 2026. október 22. https://www.huntress.com/blog/token-replay-spray
  2. Microsoft Learn: Responding to a compromised email account, frissítve 2026. július 17. https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account
  3. Microsoft Learn: Revoke user access in Microsoft Entra ID, frissítve 2026. június 19. https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
  5. Microsoft Learn: Manage user authentication methods for Microsoft Entra multifactor authentication, frissítve 2026. március 2. https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userdevicesettings
  6. Microsoft Learn: Manage device identities using the Microsoft Entra admin center. https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities
  7. Microsoft Learn: What are Microsoft Entra sign-in logs?, frissítve 2025. november 18. https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
  8. Microsoft Learn: Access tokens in the Microsoft identity platform, frissítve 2025. május 14. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens
  11. Microsoft Learn: Token Protection in Microsoft Entra Conditional Access, frissítve 2026. augusztus 20. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
  12. Európai Unió: (EU) 2016/679 rendelet (általános adatvédelmi rendelet), 33. cikk. https://eur-lex.europa.eu/legal-content/HU/TXT/?uri=CELEX:32016R0679

Nyitott kérdések

  • Hány szervezetet érintett a kampány a Huntress ügyfélkörén kívül. A Huntress ilyen számot nem közöl.
  • Volt-e magyar érintett. A forrás ilyet nem nevez meg.
  • Történt-e utalás a bérszámfejtési levél nyomán? Az elemzés kárösszeget nem közöl.

Ez a cikk általános tájékoztatás, nem minősül jogi vagy informatikai biztonsági tanácsadásnak.

AI-közreműködés: AI-asszisztált. A cikk megírásában mesterséges intelligencia közreműködött. A tartalomért a Loop szerkesztősége felel. (2026)