Hamis ChatGPT-oldal nyeli el az MFA-kódot – a külső címsor árulja el

|Szerző: A QUASA szerkesztősége|5 perc olvasás| 2
Hamis ChatGPT-oldal nyeli el az MFA-kódot – a külső címsor árulja el

Az Island 2026. október 6-án közzétett vizsgálatában egy akkor még aktív adathalász kampányt mutatott be, amelyben hamis MI-hirdetési oldalak kérnek hozzáférést a látogatók fiókjaihoz. A kutatók több száz beküldést figyeltek meg a támadók rendszerében; ez nem jelent ugyanennyi igazolt fiókátvételt. A „Connect” gomb után látható Google- vagy Okta-belépés a weboldalon belül rajzolt ablak lehet, amely elkéri a jelszót és az MFA-kódot. A benne megjelenő cím önmagában semmit sem bizonyít: a betöltött oldal címét a valódi böngésző külső címsora mutatja.

A BleepingComputer október 6-i beszámolója a ChatGPT, a Gemini, a Claude és a Perplexity nevét használó csaló oldalakat, valamint a hirdetési fiókok kezelőinek célzását írja le. Egy magyarországi hirdetési fiók kezelőjének is ezt a különbséget kell felismernie: a belépőablakba rajzolt accounts.google.com felirat eltérhet attól a címtől, amelyet a böngésző ténylegesen megnyitott. Nyilvános magyarországi áldozatszám nem szerepel a kampányról szóló beszámolókban.

Hogyan jut el a hirdetési ajánlat a hamis belépésig?

A támadás hirdetési munkára szabott ajánlattal kezdődik. A ChatGPT nevét használó oldal heti Google Ads-összefoglalót ígér, a Geminihez kötött csali kezelői és kapcsolt ügyfélfiókokat említ, más változatok kampánytervezést vagy költéselemzést kínálnak. Ezek a csaló oldalak állításai, nem a megnevezett MI-szolgáltatások igazolt funkciói. A hirdetési fiókok nyelvezetét használják, hogy a fiók összekapcsolása a feladat természetes részének tűnjön.

A közös pont a „Connect” művelet. Kattintás után az oldal egy másik böngészőablakot utánoz, címsorral, lakatjellel és ismerős bejelentkezési felülettel. A valódi böngésző közben a csalit tartalmazó webcímen marad. Ez a böngészőn belüli böngésző módszere: az oldal saját tartalmában jelenít meg egy olyan keretet, amelyet a látogató önálló, megbízható bejelentkezési ablakként értelmezhet. A megjelenített Google- vagy Okta-cím ugyanúgy az oldal által készített elem lehet, mint a gomb, amellyel az ablak megnyílt.

A külső címsor dönti el, hol van a belépés

A tényleges webcímet a teljes böngészőablak címsora mutatja. A belső keretben olvasható accounts.google.com felirat csak akkor jelzi a Google valódi bejelentkezési helyét, ha a böngésző címsorában is ez a kiszolgálónév szerepel. Okta esetén a szervezet ismert bejelentkezési címét kell ugyanígy ellenőrizni. A képernyőn követhető ellenőrzés a jelszó vagy kód beírása előtt néhány döntésből áll:

  1. Nézze meg a böngésző legkülső címsorában a teljes webcímet, különösen a kiszolgálónevet. Ha ott továbbra is a hirdetési ajánlat oldala látszik, a belső Google- vagy Okta-felirat nem igazolja a belépőablak eredetét.
  2. Figyelje meg az ablak határát. Ha a bejelentkezés a korábbi oldal területén belül jelenik meg, és nem önálló böngészőablakként viselkedik, szakítsa meg az adatbevitelt.
  3. Zárja be a gyanús oldalt. A szolgáltató megszokott címét külön nyissa meg, és a fiókkezelési felületen ellenőrizze, valóban van-e jóváhagyásra váró kapcsolat.

Az ablak mozgatása további támpontot adhat: az oldalba rajzolt keret nem húzható ki a valódi böngészőablakból. Egyetlen képi jel azonban nem helyettesíti a külső cím ellenőrzését. A támadók felülete a használt eszközhöz és böngészőhöz igazodhat, ezért a belső címsor, a lakat és az ablak vezérlői is meggyőzőnek tűnhetnek. Ha a valódi címsorban egy ismeretlen hirdetési oldal marad, a folyamatot ott kell megszakítani.

Miért nem állítja meg önmagában az MFA?

A vizsgált rendszerben a támadó emberi kezelője követhette a beküldött adatokat, és menet közben választhatta ki a következő képernyőt. Kérhetett újabb jelszót, SMS-ben vagy hitelesítő alkalmazásban kapott egyszer használatos kódot, illetve Google- vagy Okta-jóváhagyásra emlékeztető lépést. A többszöri próbálkozás így a csaló folyamat része is lehet: a rendszer megőrizhette a korábban beírt jelszavakat, miközben újabb adatot kért.

Az MFA továbbra is fontos védelem, de a bemásolható kód átadható egy adathalász oldalnak. Ha a kezelő ugyanakkor a valódi szolgáltatásnál próbál belépni, az időben elkért kód segíthet neki átlépni a második azonosítási lépést. Az eredmény az adott fiók és az időzítés körülményeitől függ; a megfigyelt beküldésekből nem lehet megállapítani a sikeres átvételek számát. Az eredeti webcímhez kötött belépési megoldások azért erősebbek ezzel a módszerrel szemben, mert a hamis oldal nem tudja a saját címét a valódi szolgáltató címévé változtatni.

Mi történjen, ha már megadták az adatokat?

A gyanús ablak bezárása után az érintett bejelentkezést incidensként kell kezelni. A valódi szolgáltató felületén meg kell változtatni a megadott jelszót, értesíteni kell a fiók rendszergazdáját, és kérni kell az érintett munkamenetek megszakítását. Ha munkahelyi Okta-fiók szerepelt a folyamatban, annak üzemeltetőjét is be kell vonni. A vizsgálatnak ki kell terjednie arra is, hogy a hozzáférést más szolgáltatáshoz vagy további hirdetési fiókhoz használták-e.

A Google Ads fiók-helyreállítási útmutatója a feltételezett kompromittálás bejelentését, a változástörténet, a felhasználók, a kezelői kapcsolatok és a kampányok áttekintését írja le. A hirdetési fiókban külön figyelmet érdemelnek az új jogosultságok, az ismeretlen kezelői fiókok, a módosított kampányok és a szokatlan költés. Ha a belépési fiók több ügyfélhez kapcsolódik, mindegyik elérhető ügyfélfiókban ellenőrizni kell ezeket a változásokat.

A jelszócsere a beírt titkot védi, de önmagában nem távolít el egy időközben hozzáadott felhasználót vagy kezelői kapcsolatot. Az incidens lezárása ezért a hozzáférések és a hirdetési módosítások rendezésén múlik: egyetlen kezelői bejelentkezés mögött több ügyfél kampányai és költési keretei is állhatnak.

Olvassa el ezt is:

Megosztás:

Kapcsolódó cikkek

Iratkozzon fel hírlevelünkre

A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.

0