Egy kínai hátterű szereplőhöz kötnek egy célzott adathalász kampányt, amely a Google Chrome és a Microsoft Windows nemrég javított biztonsági hibáit használja ki, hogy GRIMWEDGE néven ismert, rosszindulatú JavaScript hátsó kaput telepítsen.

A Volexity, amely UTA0560 néven követi a fenyegetési csoportot, közölte, hogy a tevékenység 2026. szeptember 1-jén több civil szervezetet (NGO-t) célzott meg.

„Az e-mailekben egy üzenet arra biztatta a felhasználókat, hogy kattintsanak egy hivatkozásra, amely egy amerikai egyetem weboldalára vezetett” – írták a kutatók, Ankur Saini, Conor Quigley, Sean Koessel, Steven Adair és Tom Lancaster beszámolójukban. „Ezek a linkek a weboldal egy visszavert cross-site scripting (XSS) sebezhetőségét használták ki, és a címzetteket a támadók által irányított infrastruktúrára irányították át, ahol egy többlépcsős exploit lánc futott.”

A Proofpoint által korábban részletezett exploit lánc három különálló hibát használ ki – kettőt a Chrome-ban és egyet a Windows Advanced Local Procedure Call (ALPC) komponensben. Először a CVE-2026-85046 sebezhetőséget használja ki, hogy tetszőleges olvasási/írási hozzáférést szerezzen a V8 sandboxon belül, majd a CVE-2026-87491 segítségével lép ki a böngésző sandboxból, végül pedig a CVE-2026-85880 kihasználásával kódot fecskendez a Chrome böngésző folyamatába, és tetszőleges kódvégrehajtást ér el.

Megfigyelték, hogy az UTA0560 ezt a támadási módszert használja a GRIMWEDGE telepítésére. A kártevő gépfelderítést, fájl- és folyamatkezelést, parancsvégrehajtást és további kártékony komponensek letöltését teszi lehetővé. A támadás egy célzott adathalász e-maillel indul, amely ráveszi az áldozatot, hogy rákattintson egy beágyazott linkre. A link egy legitim weboldalra mutat, amely sebezhető egy visszavert XSS hibával szemben.

A fenyegetési szereplő ezt a hibát használta ki, hogy elindítsa a BlueMoon néven is ismert nulladik napi exploit láncot, és így juttassa célba a kártevőt, miközben kiszűrte azokat a rendszereket, amelyek nem Chrome-ot használnak Windows alatt a hivatkozás megnyitásához. A végső exploit oldal három bináris payloadot ágyaz be Base64-kódolt karakterláncok formájában a JavaScript kódban –

• p1: shellcode, amely egy DLL-t tölt be reflektív módon, hogy gépfelderítést és ujjlenyomat-vételt végezzen
• p2: shellcode, amely egy DLL-t tölt be reflektív módon a Windows kernel jogosultságszint-emelés megkönnyítésére
• pp: shellcode, amely a böngésző folyamatába fecskendez kódot, és letölti a payloadot

Az UTA0560 esetében a következő lépcsőben egy „msgbox.exe” nevű futtatható állomány töltődik be. Ez egy loader, amely saját magából csomagol ki egy legitim Windows binárist és egy rosszindulatú DLL-t („wsc.dll”), hogy elindítson egy DLL sideloading láncot. A DLL ezután kapcsolatba lép ugyanazzal a szerverrel, és letölt egy szövegfájlt, amelynek neve megegyezik az eszköz profilozás során lekérdezett hostnevével.

A szövegfájl valójában egy MSI telepítő, amelynek feladata, hogy lefuttassa az MSI egyedi műveletei közé rejtett, obfuszkált JavaScript hátsó kaput. Amint elindul, a GRIMWEDGE egy folyamatos parancsciklusba lép, és rendszeresen lekérdez egy parancs- és vezérlőszervert (C2) („ocr.opusaccel[.]top”), hogy további utasításokat kapjon, amelyeket az eval() paranccsal, memóriában hajt végre. A következő parancsokat ismeri fel:

• Info – gépfelderítés végrehajtása
• Dir – könyvtárlista lekérése
• Mkdir – könyvtár létrehozása
• Del – fájl törlése
• Tasklist – futó folyamatok listázása
• Taskkill – folyamat leállítása PID alapján
• Type – fájl beolvasása legfeljebb 5 MB méretig
• Run – parancs végrehajtása rejtett ablakban
• Upload (chunk) – Base64-kódolt adatblokk letöltése a C2 szerverről, és hozzáfűzése egy memóriában tárolt bufferhez
• Upload (commit) – a felhalmozott buffer lementése lemezre, végleges fájlként

„A kódnak nincs beépített perzisztencia-, oldalirányú mozgás- vagy adatkiáramoltatási mechanizmusa a fájlolvasási és feltöltési parancsokon túl” – közölték a kutatók. „A hátsó kapu egy kezdeti lábnyomot biztosít a kompromittált gépen, ami elég ahhoz, hogy az UTA0560 felmérje a rendszert, letöltse az érdekes fájlokat, és további eszközöket telepítsen a Run és Upload parancsokkal.”

A Volexity szerint egy másik, szintén Kínához köthető fenyegetési szereplőt, a JungleBamboo-t (más néven APT31) is megfigyelték, amint nagyjából ugyanebben az időszakban ugyanazt az exploit láncot használta egy SUPERSTOMP nevű loader telepítésére. Ez a loader egy távoli szerverről telepíti a LONGTALE-t, egy hitelesítőadat-lopásra szolgáló Chrome kiterjesztést, amelyet GemStone néven is emlegetnek. A kiterjesztés Google Gemini Chrome kiegészítőnek álcázza magát (ID: ckiknalbeplpcpofpnabcnhjcegckfei), hogy elkerülje a detektálást, és az alábbi funkciókat támogatja:

• Billentyűnaplózás és űrlapadatok rögzítése
• Sütik és munkamenetek ellopása
• Képernyőmentés készítése az oldal tartalmának figyelésével, a C2 szerver által megadott kulcsszavak alapján
• Billentyűleütések, sütik, tárolt adatok, böngészési előzmények és munkamenet-metaadatok tömeges kiáramoltatása a C2 szerver felé, nagyjából 30 másodperces időközönként
• Távoli parancs- és vezérlés

A Volexity szerint a LONGTALE-ben még egy alapvető, távoli kódfuttatást lehetővé tevő parancs sincs, amellyel a fenyegetési szereplő további, utólagos műveleteket hajthatna végre a kompromittált eszközökön. Hozzátették, hogy lehetséges, a támadók feleslegesnek tartották ezt a funkciót, mert a LONGTALE kiterjedt adatlopási képességei önmagukban is elegendőek voltak a JungleBamboo hitelesítőadat-lopási és megfigyelési céljainak eléréséhez.

Az, hogy Kínához köthető több fenyegetési szereplő szinte egy időben használta ugyanazt a Chrome–Windows exploit láncot, felveti annak lehetőségét, hogy az exploit fejlesztője eladta nekik, vagy valamilyen módon elérhetővé tette számukra, miután feltehetően visszafejtette a Chromium forráskódjában végrehajtott módosításokat.

Különösen figyelemre méltó a javítási rés: bár a két Chrome sebezhetőség javítását beépítették a nyílt forráskódú Chromium kódbázisába, ezek még nem kerültek be a Google Chrome egyetlen stabil kiadásába sem. Másképp fogalmazva: az upstream javítócsomagok egy szokatlan helyzetet teremtettek, amelyben két N-napos hiba ugyan már javítva volt a Chromiumban, de nem a Chrome-ban. Emiatt a Chrome szempontjából ezek nulladik napi sebezhetőségeknek számítottak.

Mivel a Chrome a múlt hétig négyhetes release ciklust követett a főbb mérföldkő-kiadásoknál (mostantól két hetente jelennek meg), elképzelhető, hogy a támadók igyekeztek gyorsan lépni, mielőtt bezárult volna a kihasználási ablak, és a Google kiadta volna a hivatalos javítócsomagokat.

A Volexity szerint „a patch-gap sebezhetőségek még nagyobb kockázatot jelentenek, mert egy plusz időablakot nyitnak a fenyegetési szereplők előtt, hogy kihasználási kampányokat folytassanak, miközben a nagy nyelvi modellek egyre népszerűbbé és hatékonyabbá válnak a gyors sebezhetőségkutatás és exploit fejlesztés terén.”