2026. szeptember 9-én írtunk egy rendkívül makacs WordPress-fertőzésről, amely a törölt kártékony fájlokat újra és újra visszaállította.
Szeptember 22-én a Wordfence Threat Intelligence is közzétett egy önhelyreállító, rejtőzködő WordPress MU-pluginról szóló részletes technikai elemzést. Az általuk feltárt működés több ponton rendkívül erős egyezést mutat az általunk vizsgált fertőzéssel.
A két elemzés összevetése nemcsak azt mutatja meg, hogyan maradhat életben egy ilyen kártevő a fájlok egyszerű törlése után, hanem azt is, miért lehet félrevezető egy látszólag megtisztított WordPress-oldal.
Mit talált a Wordfence?
A Wordfence által vizsgált kártevő egy WordPress must-use, vagyis MU-pluginként települő hátsó kapu. Ezeket a bővítményeket a WordPress automatikusan betölti, és a hagyományos bővítménylistában sem feltétlenül jelennek meg feltűnően.
A Wordfence részletes elemzése szerint a kártevő:
- változó névvel és hamis bővítmény-metaadatokkal jelenhet meg;
- több mint négyezer különböző fájlnév alatt fordult elő;
- egyedi helyettesítéses titkosítással rejti el a karakterláncait;
- elrejti magát a bővítménylistából, a frissítések közül és a Webhelyegészség felületéről;
- hamis rendszergazdai fiókot hoz létre, vagy átvesz egy meglévő felhasználói fiókot;
- manipulálja a felhasználók listáját és a megjelenített felhasználószámot;
- képes megszerezni és eltárolni a rendszergazdák bejelentkezéskor megadott jelszavát;
- adatbázisban tárolt példányból képes visszaírni saját magát;
- más, számára írható WordPress-telepítésekbe is átmásolhatja magát;
- távolról frissíthető, lecserélhető vagy új funkciókkal bővíthető;
- adatokat küldhet a támadók vezérlőszervereire.
A Wordfence elemzésének egyik legérdekesebb megállapítása az úgynevezett EtherHiding technika alkalmazása. A kártevő Ethereum okosszerződésekből képes lekérni az aktuális vezérlőszerverek címeit, nyilvános RPC-szolgáltatásokon keresztül.
Ez megnehezíti a vezérlési infrastruktúra végleges blokkolását, mert a kártevőnek nem kell egyetlen, a kódba közvetlenül beírt szervercímre támaszkodnia.
Ugyanerről a kártevőről lehet szó?
Teljes bizonyossággal nem állítható, hogy minden általunk talált fájlt ugyanaz a támadási kampány hozott létre. A technikai egyezések azonban rendkívül erősek, és nagy valószínűséggel ugyanahhoz az „SC” jelölésű kártevőcsaládhoz tartozó mintákat vizsgáltunk.
Az általunk talált két orbit-provider-plus.php változat látszólag különböző bővítménynek próbálta mutatni magát:
- az egyik „Orbit Provider Plus”, 1.0.5 verzió és Harper Walker szerzőnév alatt jelent meg;
- a későbbi minta már „Nexus Monitor Lab”, 1.2.0 verzió és Ava Green szerzőnevet használt.
A fájlok mérete, tartalma és SHA-256 lenyomata is eltért. A belső kód azonban mindkét esetben tartalmazta ugyanazokat a jellegzetes SC azonosítókat, valamint a Wordfence által is bemutatott helyettesítéses dekódolási megoldást.
A belső verziójelölés közben SCV:4.2.7 értékről SCV:4.3.24 értékre változott.
Ez pontosan összhangban van a Wordfence azon megállapításával, hogy a fájlnév, a bővítmény neve, a szerző, a verzió és a fájl hashértéke nem használható megbízható azonosítóként. A kártevő ezeket változtathatja, miközben az alapvető működése megmarad.
A Wordfence tapasztalatai és a mi esetünk
| A Wordfence által feltárt működés | Amit a saját esetünkben tapasztaltunk |
|---|---|
| A kártevő MU-pluginként települ | Az orbit-provider-plus.php a wp-content/mu-plugins könyvtárban jelent meg |
| Változó nevet és hamis bővítményadatokat használ | Két különböző bővítménynévvel, szerzővel és verzióval rendelkező mintát találtunk |
| Egyedi helyettesítéses kódolással rejti el a karakterláncait | Mindkét több megabájtos fájlban azonos jellegű dekódoló és nagyméretű helyettesítési táblák voltak |
| Elrejti magát a WordPress adminisztrációs felületein | A fertőzéshez kapcsolódó elemek nem jelentek meg hagyományos telepített bővítményként |
| Rejtett rendszergazdai fiókot hozhat létre | Az adatbázisban jogosulatlan adminisztrátori fiókot találtunk |
| Adatbázisban tárolt forrásból újraírhatja magát | sc_persist_manifest, sc_payload_* és sc_recover_* jellegű adatbázis-bejegyzéseket találtunk |
| Ellenőrzi saját jelenlétét, és visszaállítja a hiányzó fájlt | A törölt fájl egyes kísérletekben 10–15 másodpercen belül újra létrejött |
| Más elérhető WordPress-telepítésekbe is átmásolhatja magát | A fertőzés több fájlt, drop-int, témát és feltöltési könyvtárat is érintett |
| Távolról frissíthető és lecserélhető | A visszatérő fájl tartalma, mérete, metaadatai és belső verziója is megváltozott |
| Az adatbázisban eltárolhatja saját forráskódját | A saját esetünkben is találtunk a helyreállításhoz kapcsolódó adatbázis-bejegyzéseket |
| Ethereum-alapú vezérlőszerver-felderítést használhat | Ennek meglétét a mi környezetünkben hálózati naplók hiányában nem tudtuk közvetlenül igazolni |
Mi magyarázza, hogy nem ugyanaz a fájl tért vissza?
Korábban az egyik legfontosabb kérdés az volt, hogyan jelenhet meg a tárhelyen egy új méretű, új tartalmú és új verziószámú fájl, ha a webes hozzáférést .htaccess fájllal teljesen letiltottuk.
A Wordfence elemzése erre két lehetséges magyarázatot is ad.
Az egyik, hogy a kártevő saját forrásának egy példányát az adatbázisban tárolja, és ebből írja vissza magát. A másik, hogy a támadók távolról új változatot küldhetnek számára, amelyet a kártevő eltárol, majd az eredeti fájl helyére ír.
Így nincs szükség arra, hogy minden visszaállításkor pontosan ugyanaz a fájl jöjjön létre. A kód változtathatja a metaadatokat, a verziószámot és akár a belső szerkezet egyes részeit is.
Ez a működés megmagyarázhatja a két eltérő mintánkat, de önmagában még nem bizonyítja, hogy az adott fájlt melyik konkrét folyamat írta a tárhelyre.
Amit továbbra sem magyaráz meg teljesen
Az egyik kísérlet során a tárhelyen nem maradt WordPress, adatbázis vagy archivált weboldal. A webhely könyvtárában kizárólag a teljes HTTP-hozzáférést tiltó .htaccess volt jelen. Ennek ellenére egyik reggel ismét létrejöttek a kártékony fájlok.
Egy másik ellenőrzésnél teljesen friss WordPress került a tárhelyre, mindössze a két gyári bővítménnyel. A HTTP-hozzáférés ekkor is tiltva volt. Másnap reggel ismét létrejött az mu-plugins könyvtár és benne az orbit-provider-plus.php.
Ez arra utal, hogy a fájlt létrehozó folyamat nem feltétlenül a böngészőből elérhető WordPress-oldalon keresztül indult el.
A .htaccess ugyanis csak a webszerveren keresztül érkező kéréseket tiltja. Nem akadályozza meg:
- a már futó PHP-folyamatokat;
- a felhasználói vagy szerveroldali cronfeladatokat;
- a parancssorból vagy vezérlőpultból indított műveleteket;
- a tárhelyfiók más könyvtáraiból érkező fájlműveleteket;
- az ellopott FTP-, SFTP- vagy tárhely-hozzáférés használatát;
- egy, a webszervert megkerülő helyi folyamat működését.
A rendelkezésünkre álló naplókból nem lehetett egyértelműen meghatározni, ezek közül pontosan melyik írta vissza a fájlt. Ehhez a tárhelyszolgáltató által elérhető folyamat-, audit-, cron-, PHP-FPM- és fájlrendszernaplókra lett volna szükség.
Ezért fontos különválasztani két állítást:
- a fájl bizonyíthatóan újra létrejött akkor is, amikor a webhely HTTP-n nem volt elérhető;
- ebből önmagában nem következik, hogy a teljes tárhelyszerver vagy a szolgáltató infrastruktúrája fertőzött volt.
Azt viszont egyértelműen mutatja, hogy az egyszerű fájltörlés és a WordPress adminisztrációs felület ellenőrzése nem volt elegendő a fertőzés forrásának megszüntetéséhez.
Miért nem elég egy víruskereső vagy a fertőzött fájl törlése?
Az ilyen kártevő több, egymást helyreállítani képes példányból állhat. Amíg ezek közül akár csak egy is megmarad, a fertőzés ismét felépítheti magát.
Egy alapos helyreállítás során ezért egy időben kell ellenőrizni:
- a WordPress összes fájlját;
- az MU-pluginokat és a drop-ineket;
- a témák és bővítmények PHP-fájljait;
- a
.user.ini,.htaccessés PHP-konfigurációs állományokat; - az adatbázis options, posts, postmeta és users tábláit;
- a cron- és Action Scheduler-feladatokat;
- a tömörített mentéseket és gyorsítótárakat;
- a tárhelyfiók alatt található összes további webhelyet;
- az FTP-, tárhely-, adatbázis- és WordPress-hozzáféréseket.
A WordPress biztonsági kulcsait is le kell cserélni, a munkameneteket vissza kell vonni, és minden érintett jelszót kompromittáltnak kell tekinteni. A Wordfence kutatása alapján a kártevő a rendszergazdák bejelentkezéskor megadott jelszavát és munkamenetét is megszerezhette, ezért egy egyszerű jelszócsere önmagában nem elegendő, ha a kártékony kód még fut.
Mit erősített meg számunkra a Wordfence elemzése?
A Wordfence kutatása technikai magyarázatot adott több olyan jelenségre, amelyet korábban közvetlenül megfigyeltünk:
- a változó fájlnév és hamis bővítményadat nem véletlen;
- a különböző hashérték nem jelenti azt, hogy teljesen más kártevőről van szó;
- az adatbázis valóban használható rejtett biztonsági másolatként;
- a kártevő képes saját magát ellenőrizni és visszaállítani;
- a rejtett adminisztrátor a működés tudatos része;
- a fertőzés más elérhető WordPress-telepítésekbe is továbbterjedhet;
- a támadók távolról lecserélhetik vagy frissíthetik a kódot.
A saját esetünkben a fájl visszaírását végző konkrét szerveroldali folyamatot nem sikerült azonosítani. A kártevőcsalád működéséről azonban a Wordfence elemzése lényegében megerősítette mindazt, amire a fájlok, az adatbázis-bejegyzések és az ismételt visszafertőződések alapján következtettünk.
Segítség fertőzött WordPress-oldal helyreállításához
Ha egy WordPress-oldalon törlés után ismét megjelennek a kártékony fájlok, ismeretlen adminisztrátor kerül az adatbázisba, vagy a fertőzés több sikertelen tisztítás után is 24 órán belül visszatér, az oldal egyszerű újratelepítése valószínűleg nem lesz elegendő.
Ilyen esetben a teljes fájlállományt, az adatbázist, a hozzáféréseket és a tárhelyen található további webhelyeket is együtt kell megvizsgálni.