Valódi Microsoft-belépés, mégis csalás: hamis Teams-időpontfoglalással támadtak

Egy váratlan, de hihető üzleti megkeresés érkezik: egy lehetséges partner online egyeztetést szeretne. A levél egy Microsoft Teams-időpontfoglalónak látszó oldalra vezet, ahol ki lehet választani a beszélgetés hosszát és időpontját. A végén mindössze egy „foglalási hivatkozást” kell megadni egy Microsoft-belépési felületen. A probléma az, hogy a foglalási hivatkozás valójában nem foglaláshoz tartozik.

A Huntress 2026. november 12-én közzétett kutatása egy ilyen támadást dokumentált. Az esetet október közepén észlelték egy építőipari vállalatnál. A támadó nem a Microsoft oldalát hamisította meg az utolsó lépésben: a felhasználót a Microsoft valódi eszközbelépési oldalára irányította, ahol a megadott kód a támadó által elindított bejelentkezést hagyta jóvá.

Mitől volt hihető az álcázott Teams-meghívó?

A támadó egy másik, valóban létező építőipari vállalat vezetőjének adta ki magát. A levélhez megtévesztően hasonló domainnevet használt, az időpontfoglaló oldal pedig a megszemélyesített vezető nevét, szerepét és fényképét mutatta. A hivatkozás több átirányításon keresztül jutott a támadó által irányított felületre, így a végső cél nem volt azonnal nyilvánvaló.

A látogató kiválaszthatta a hívás időtartamát és az egyeztetés időpontját. Ez a megszokott folyamat csökkenthette a gyanakvást. A látszólagos naptárfoglalás azonban csak az adathalász támadás előkészítése volt.

Hogyan lett a foglalási kódból fiókhozzáférés?

A támadók az úgynevezett device code phishing módszert használták. A Microsoft eszközkódos belépési folyamata önmagában legitim: például korlátozott beviteli lehetőséggel rendelkező eszközök bejelentkeztetésére szolgál. A támadásban viszont nem a felhasználó kezdeményezte a saját eszköze beléptetését; a támadó indított egy folyamatot, majd elérte, hogy az áldozat hagyja azt jóvá.

Az időpontfoglaló oldal a háttérben eszközkódos Microsoft-bejelentkezést indított. A visszakapott kódot „Booking Reference”, azaz foglalási hivatkozás néven mutatta meg. A felhasználó a foglalás megerősítésére kattintva lemásolta a kódot, majd a megnyíló, valódi Microsoft-belépési oldalon megadta. Ezzel a támadó által kezdeményezett munkamenetet hitelesítette.

A Huntress szerint a támadó hozzáférési tokent szerzett, és a naplókban ezt követően sikeres, Device code (Cmsi:Cmsi) jellegű Microsoft Authentication Broker-belépés jelent meg. A kutatók észlelték és megfékezték az incidenst, mielőtt az súlyosabb következményekkel járt volna. A felhasználó végül egy valódinak látszó időpontfoglalási felületre jutott, ami tovább elfedhette a történteket.

Ez a módszer nem klasszikus jelszólopás: a támadó a bejelentkezési folyamat és a felhasználó megtévesztése révén jutott jogosultsághoz. A többfaktoros hitelesítés sem teszi biztonságossá egy idegen fél által kezdeményezett belépés jóváhagyását; az ismertetett konkrét áldozati fióknál ugyanakkor a Huntress szerint nem volt beállított MFA.

Miért fontos ez a vállalati pénzügyekben?

A Huntress által dokumentált konkrét incidens nem bankot, fintechcéget vagy Open Banking-szolgáltatót érintett. A pénzügyi kockázat ezért nem igazolt következmény, hanem az ilyen típusú fiókhozzáférésből adódó lehetséges veszély.

Egy vállalat Microsoft 365-környezetében lehetnek számlák, beszállítói egyeztetések, pénzügyi riportok, jóváhagyási levelek és ügyféladatok. Ha egy támadó hozzáférést szerez a megfelelő postafiókhoz vagy felhasználói munkamenethez, visszaélhet az elérhető információkkal. A tényleges hatást a megszerzett hozzáférési jogosultság és a további biztonsági kontrollok határozzák meg.

Különösen fontos ez a beszállítói kommunikációban. Egy korábban ismert üzleti kapcsolat nevében érkező, hitelesnek látszó egyeztetés ugyanúgy lehet megtévesztés, mint egy szokatlan bankszámlaszám-módosításról szóló levél. A védelem közös eleme a független, korábbi elérhetőségen történő visszaellenőrzés.

Milyen jelekből ismerhető fel a csalás?

• Váratlan, üzletileg sürgető meghívó: egy ismeretlen partner vagy vezető gyors egyeztetésre hív.
• Majdnem helyes feladói domain: a vállalat neve ismerős, de a címben apró eltérés van.
• Szokatlan megerősítési lépés: a foglalás végén a Microsoft eszközbelépési oldalán kell kódot megadni.
• Újabb hitelesítési kérés: egy találkozó lefoglalása miatt váratlan belépést vagy jóváhagyást kérnek.

A hivatkozás biztonságosnak látszó köztes szolgáltatásokon is áthaladhat, a megnyíló Microsoft-belépés pedig valódi lehet. Egyetlen részlet helyett a teljes folyamat indokoltságát kell ellenőrizni.

Mit tegyél, ha már megadtad a kódot?

Ne várj arra, hogy ismeretlen e-mail vagy pénzügyi tranzakció jelenjen meg. Azonnal értesítsd a vállalati informatikai vagy biztonsági csapatot, és jelezd, hogy mikor, melyik oldalról, milyen Microsoft-fiókkal léptél be. Ne csak a jelszó megváltoztatására hagyatkozz: a már kiadott hozzáférési tokenek és munkamenetek külön kezelést igényelhetnek.

A rendszergazda vizsgálja meg az érintett bejelentkezéseket és a munkamenetek visszavonásának szükségességét, az ismeretlen eszközöket, a hozzáadott hitelesítési módszereket, a gyanús alkalmazásengedélyeket, a postafiók-továbbítási szabályokat és a kimenő leveleket. Ha vállalati vagy ügyféladat érintettsége felmerül, az incidenskezelést és az esetleges adatvédelmi kötelezettségeket is külön értékelni kell.

Mit ellenőrizhetnek a Microsoft 365-üzemeltetők?

1. Entra-bejelentkezési naplók: váratlan device code hitelesítések, különösen ismeretlen eszközökkel, szokatlan földrajzi helyekkel vagy automatizált kliensekkel együtt. A Cmsi:Cmsi önmagában nem bizonyít támadást; más indikátorokkal együtt érdemes értékelni.
2. Conditional Access: ahol üzletileg nincs szükség eszközkódos belépésre, azt a Microsoft útmutatója alapján célszerű blokkolni. Bevezetés előtt használható a Report-only mód, majd a tesztelést követően élesíthető a szabály.
3. Indokolt kivételek: egyes Teams Room vagy közös eszközök legitim módon használhatják ezt a folyamatot; a Microsoft külön útmutatót ad a szűk körű kivételek kezelésére.
4. Fiókvédelem: adathalászatnak ellenálló hitelesítés, a szükséges hozzáférések korlátozása, valamint gyanús alkalmazáshozzáférések és munkamenetek vizsgálata.

A szabályozásokat a szervezet tényleges eszközhasználata alapján kell bevezetni: egy indokolatlanul széles tiltás legitim tárgyalótermi eszközök bejelentkeztetését is akadályozhatja.

Összegzés: nem a jelszómező az egyetlen veszélyes pont

A Teams-időpontfoglalásnak álcázott incidens azt mutatja meg, hogy a támadók nem feltétlenül hamis jelszóbekérő oldallal dolgoznak. Elég lehet egy meggyőző üzleti történet, egy szokásosnak tűnő foglalási felület és a Microsoft valódi belépési folyamata.

A legfontosabb szabály: soha ne hagyj jóvá olyan bejelentkezést vagy eszközkódos kérést, amelyet nem te kezdeményeztél. Váratlan üzleti egyeztetés esetén az ismert kapcsolattartónál ellenőrizd a megkeresést. A vállalati pénzügyi adatok védelmében ez ugyanúgy fontos kontroll, mint a jogosultságkezelés vagy a többfaktoros hitelesítés.