Óvakodj a fekete macskától! – avagy egy WordPress-fertőzés, amelynek 9 élete van

Egy átlagos WordPress-fertőzés eltávolítása többnyire jól követhető művelet: azonosítjuk a fertőzött fájlokat, megkeressük azt a „rést”, ahol bejutott. Ezt a rést „betömjük”, kitisztítjuk az adatbázist, frissítjük vagy újratelepítjük a rendszert, lecseréljük a hozzáféréseket, majd monitorozzuk napokon/heteken át a weboldalt. De mi történik akkor, ha a kártevő nem egyetlen fájlban él? Mi van, ha a fájlrendszerben, az adatbázisban, a WordPress időzített feladataiban, az aktív sablonban, a PHP-konfigurációban és még az adminisztrátor böngészőjében is elhelyezi a saját tartalék példányait?

2026 szeptemberében pontosan ilyen fertőzéssel találkoztunk egy magyar WordPress-oldalon. Amit először egy szokványos helyreállítási munkának gondoltunk, néhány nap alatt egy rendkívül makacs, önmagát újraépítő kártevő elleni nyomozássá vált.

A címben szereplő fekete macska csak metafora: a cikk nem az ALPHV/BlackCat zsarolóvírusról szól. A „kilenc élet” arra a kilenc, egymástól részben független fennmaradási mechanizmusra utal, amelyet a Monarx kutatói ennél a WordPress-malware-kampánynál azonosítottak.

Nem egy fájl, hanem egy önjavító rendszer

A Monarx 2026. augusztus 17-én megjelent technikai elemzése szerint ez a kártevő nem egyetlen PHP-fájlra épít. Több rétegben helyez el egymást visszaállítani képes komponenseket. Ha ezek közül csak a legfeltűnőbbet töröljük, valamelyik másik példány rövid időn belül újra létrehozhatja az egész rendszert.

Ez alapvetően különbözik attól a fertőzéstől, amelynél találunk egy módosított index.php fájlt vagy egyetlen webshellt. Itt maga a fennmaradás a kártevő egyik fő funkciója.

A Monarx által leírt család többek között az alábbi helyeken és rétegekben képes megkapaszkodni:

• automatikusan betöltődő wp-content/mu-plugins/ fájlban;
• a wp-content/db.php, advanced-cache.php vagy object-cache.php drop-in fájlokban;
• az aktív sablon functions.php fájljában;
• .htaccess, .user.ini vagy php.ini állományokban elhelyezett auto_prepend_file direktívával;
• a WordPress adatbázisának wp_options táblájában tárolt kód- és konfigurációs másolatokban;
• WP-Cron-feladatokban;
• rejtett adminisztrátori fiókokban és ellopott munkamenetekben;
• cache-, guard- és telepítőfájlokban, illetve feltöltött ZIP-csomagokban;
• az adminisztrátor böngészőjében regisztrált Service Worker-ben.

A felsorolás nem azt jelenti, hogy minden fertőzött oldalon minden elem azonos néven és azonos formában jelenik meg. A fájlnevek, az adatbázis-opciók egy része és az időzített feladatok neve telepítésenként változhat.

Miért ideális rejtekhely az MU-plugin?

Az MU-plugin – vagyis must-use plugin – legitim WordPress-funkció. Az ide helyezett PHP-fájlok automatikusan betöltődnek, nem kell őket külön bekapcsolni, és a normál bővítménylistában sem ugyanúgy jelennek meg, mint a hagyományos pluginek. A WordPress hivatalos dokumentációja szerint az MU-pluginek csak a fájl eltávolításával kapcsolhatók ki.

Ez rendszergazdai és tárhelyszolgáltatói funkciókhoz hasznos, egy támadónak viszont kiváló rejtőzködési lehetőség. Egy adminisztrátor végignézheti a telepített bővítmények szokásos listáját úgy, hogy a kártevő közben továbbra is minden WordPress-kérésnél lefut.

A saját vizsgálatunkban egy több megabájtos, erősen obfuszkált orbit-provider-plus.php fájl jelent meg az mu-plugins könyvtárban. Ez a konkrét fájlnév a mi esetünkben volt megfigyelhető; önmagában nem tekinthető a teljes malware-család állandó elnevezésének.

Parancsvezérlés blokkláncon keresztül

A Monarx elemzésének egyik legérdekesebb megállapítása, hogy a kártevő a vezérlőszerverek címét nyilvános Ethereum RPC-végpontokon keresztül, okosszerződés-lekérdezéssel tudja feloldani. Így nem feltétlenül tartalmaz egy könnyen letiltható, állandó vezérlődomaint vagy IP-címet.

A fertőzés időszakosan kapcsolatba léphet a vezérlő infrastruktúrával, információt küldhet az oldalról, majd új kódot, szabályokat vagy fennmaradási komponenseket fogadhat. A Monarx szerint az összegyűjtött adatok között lehet az oldal elérési útja, az aktív bővítmények listája, az adminisztrátorok adatai és hamisított, hosszabb ideig érvényes WordPress-munkamenet is.

Ez azért fontos, mert egy fertőzött WordPress-mag egyszerű újratelepítése nem feltétlenül zárja ki a támadót. Ha megmarad egy rejtett admin, egy ellopott jelszó, egy érvényes munkamenet, egy adatbázisban tárolt visszaállító példány vagy egy böngészőben futó komponens, az oldal ismét kompromittálható.

Saját esetünk: egy hónapos mentés sem volt elég

Az eset egy tárhelyszolgáltatói értesítéssel kezdődött: a szolgáltató jelezte a weboldal tulajdonosának, hogy fertőzést talált. Az első vizsgálat igazolta a riasztást. Nem egyetlen gyanús fájl volt az oldalon, hanem több káros PHP-állomány és adatbázisban tárolt fertőzési nyom.

Az adatbázisban gyanús időzített feladatokat, rejtett adminisztrátori felhasználót és fennmaradást szolgáló opciókat találtunk. A támadói adminisztrátor a WordPress Felhasználók képernyőjén nem feltétlenül látszott, közvetlen adatbázis-lekérdezéssel azonban azonosítható volt. Ez egybevág a Monarx leírásával: a kártevő képes úgy módosítani a felhasználólekérdezéseket, hogy a saját fiókját elrejtse a szokásos adminisztrációs felületekről.

Mivel régebbi, bizonyíthatóan tiszta biztonsági mentés nem állt rendelkezésre, visszaállítottuk a körülbelül egy hónappal korábbi legöregebb elérhető mentést. Ezután következett a szokásos helyreállítási folyamat: WordPress-mag és bővítmények újratelepítése, hozzáférések cseréje, adatbázis-ellenőrzés és a gyanús állományok eltávolítása.

Néhány nappal később azonban ismét megjelentek a káros fájlok.

Az újabb fertőzési körben többek között az alábbiakat találtuk:

• nagyméretű, obfuszkált PHP-fájlt az mu-plugins könyvtárban;
• auto_prepend_file direktívát tartalmazó .user.ini állományokat;
• egy automatikusan betöltött, hash-szerű nevű PHP-loadert;
• módosított vagy létrehozott db.php fájlt;
• adatbázisban tárolt fennmaradási adatokat és cronbejegyzéseket;
• új, rejtett adminisztrátori felhasználót;
• feltöltési könyvtárban elhelyezett, visszatelepítésre használható állományokat.

A legárulkodóbb jelenség az volt, hogy az egyik fertőzött fájlt nem lehetett tartósan eltávolítani. Átnevezés vagy törlés után nagyjából 10–15 másodpercen belül újra létrejött. Az új példány mérete és tartalma kissé eltért az előzőtől, tehát nem egyszerű fájlkezelői megjelenítési hibáról volt szó: valamilyen aktív folyamat vagy másik fennmaradási komponens újra előállította.

Ez pontosan az a helyzet, amelyben a „találd meg és töröld a vírusos fájlt” módszer már nem működik.

A böngésző is a fertőzési lánc része lehet

A Monarx kutatása szerint a malware Service Workert is regisztrálhat az adminisztrációs és bejelentkezési útvonalakhoz. A Service Worker eredetileg legitim böngészőtechnológia: a háttérben futva képes kéréseket kezelni és gyorsítótárazott válaszokat visszaadni. Az MDN dokumentációja lényegében a böngésző és a hálózat közé ékelődő, programozható proxyként írja le.

Kártékony felhasználás esetén ugyanez a mechanizmus képes lehet:

• a wp-login.php felé küldött bejelentkezési adatok elfogására;
• egy aktív adminisztrátori munkamenet felhasználására;
• a káros plugin WordPressen keresztüli visszatelepítésére;
• háttérben végrehajtott későbbi próbálkozásokra.

Ezért ennél a fertőzésnél a szerver kitisztítása önmagában nem elég. Minden olyan böngészőben és eszközön, amelyről a fertőzés idején beléptek az adminisztrációba, ellenőrizni kell a domainhez tartozó Service Workereket, majd törölni kell a webhelyadatokat. A régi adminisztrátori munkameneteket szerveroldalon is érvényteleníteni kell.

Meddig tart a WordPress, és hol kezdődik a szerver?

A második megjelenés után módszeresen kizártuk az általunk elérhető lehetséges forrásokat. Ellenőriztük a WordPress fájljait, az adatbázist, a cronbejegyzéseket, az adminisztrátorokat, a sablont, a bővítményeket, feltöltési könyvtárat valamint a böngésző service workereit, előzményeket, sütiket. A káros állomány mégis aktívan visszaíródott. Sőt, amikor már adatbázis és egyetlen fájl sem volt a tárhelyen, és még a külső HTTP-kéréseket is tiltottuk, akkor is visszaépült az mu-plugin könyvtára és benne a kérdéses káros fájl — ráadásul mindig reggel 7:15 és 7:45 közötti időpontban. Ez mindenképp valamilyen időzített tárhelyszintű folyamatra utal.

Megmaradtak ugyanis azok a szerveroldali rétegek, amelyekhez egy megosztott tárhely ügyfeleként nem volt közvetlen hozzáférésünk: a futó PHP-folyamatok, a PHP-FPM állapota, az OPcache, a tárhelyszintű cronok, a folyamatnaplók és az ugyanazon fiókhoz vagy környezethez tartozó más webhelyek közötti esetleges kapcsolat.

Ez nem bizonyítja, hogy maga a tárhelyszerver vagy a szolgáltató infrastruktúrája fertőzött volt. A rendelkezésünkre álló adatokból a visszaírást végző konkrét folyamatot nem lehetett azonosítani. A probléma az volt, hogy a szükséges szerveroldali adatok és műveletek nélkül nem lehetett ellenőrizhető módon lezárni a vizsgálatot, a tárhelyszolgáltató pedig nem biztosított ehhez megfelelő együttműködést.

Egy ilyen incidensnél nem elég azt látni, hogy a víruskereső pillanatnyilag nulla találatot jelez. Azt is meg kell tudni magyarázni, mi hozta létre újra a fájlt, melyik folyamat futtatta, és valóban megszűnt-e az összes fennmaradási útvonal.

Amikor a költözés a biztonságosabb döntés

Mivel a tárhelyszolgáltató nem volt igazán partner, hogy a nála futó folyamatokat ellenőrizze, amely a fájlok visszaépülését okozhatta, így végül a költözés mellett döntöttünk. Nem a fertőzött telepítést másoltuk át egy másik szerverre, hanem az új tárhelyen tiszta környezetet építettünk:

1. A WordPress magját hivatalos forrásból telepítettük.
2. Csak a szükséges bővítményeket telepítettük újra, szintén hivatalos csomagból.
3. Az adatbázist külön elemeztük és alaposan megtisztítottuk a káros opcióktól, cronbejegyzésektől, munkamenetektől és ismeretlen adminisztrátoroktól.
4. A feltöltött képeket típusellenőrzés után újraformáztuk, majd csak a szükséges médiaállományokat vittük tovább.
5. Lecseréltük a tárhely-, adatbázis- és WordPress-jelszavakat, valamint a WordPress hitelesítési kulcsait és salt értékeit.
6. A legitim adminisztrátorok jelszavait újra beállítottuk, a kétlépcsős azonosítást bekapcsoltuk.
7. Az adatbázist először izolált tesztkörnyezetben indítottuk el, majd fájl-, felhasználó-, cron- és checksum-ellenőrzéseket végeztünk.
8. Az új tárhelyen a kritikus időszak után is figyeltük az ismert fájlok, rejtett adminok és adatbázis-bejegyzések esetleges visszatérését.
9. Elemeztük a hiba – és access naplók bejegyzéseit.

A költözés tehát nem egy fertőzött mentés átmásolását jelentette. Az egy új, ellenőrzött telepítés volt, amelybe csak a megtisztított adatokat és a szükséges, nem futtatható médiaállományokat emeltük át.

Mire érdemes keresni?

A Monarx által közölt indikátorok és a saját esetünk alapján különösen indokolt a teljes körű vizsgálat, ha az alábbi jelek közül több egyszerre jelenik meg:

• ismeretlen vagy szokatlanul nagy PHP-fájl a wp-content/mu-plugins/ könyvtárban;
• SC_DB_BEGIN, SC_ADV_BEGIN vagy SC_TH_BEGIN jelölések;
• auto_prepend_file a .user.ini, php.ini vagy .htaccess fájlban;
• ismeretlen db.php, advanced-cache.php vagy object-cache.php;
• hash-szerű nevű PHP-fájlok a WordPress könyvtáraiban;
• ismeretlen vagy véletlenszerű nevű adminisztrátor közvetlenül a wp_users és wp_usermeta táblában;
• sc_payload_*, sc_persist_manifest, sc_recover_* vagy hasonló adatbázis-opciók;
• ismeretlen WP-Cron-feladatok;
• feltöltési könyvtárban található PHP- vagy gyanús ZIP-fájl;
• a törlés után másodperceken vagy perceken belül újra megjelenő állomány;
• ismeretlen Service Worker az adminisztrátor böngészőjében.

Egyetlen jel önmagában nem mindig bizonyít fertőzést. A db.php, az advanced-cache.php, az MU-plugin vagy egy cronfeladat legitim bővítményhez és tárhelyszolgáltatáshoz is tartozhat. Az eredetét, tartalmát, létrehozási körülményeit és a többi indikátorral való kapcsolatát együtt kell vizsgálni.

*Frissítés – A cikk megjelenése után egy rendszergazda kolléga jelezte, hogy ugyanehhez a malware-családhoz köthető fertőzést távolítottak el. Náluk a visszatérés egyik kulcsa nem PHP-fájl, hanem .wp-object-cache-<hex>.dat és .dat.lkg néven tárolt, tömörített önmentő archívum volt. Az archívum további példányai a sablon- és feltöltési könyvtárakban, <hex>.zip néven rejtőztek. A fertőzést csak a PHP szerveroldali leállítása és valamennyi fájl-, adatbázis-, cron- és felhasználói komponens egyidejű eltávolítása után sikerült megszakítani.

A helyreállítás helyes sorrendje

Ennél a malware-családnál a sorrend döntő. Ha a fő fájlt úgy töröljük, hogy közben a PHP még futtatja valamelyik visszaállító komponenst, maga a törlés válthatja ki az újragenerálást.

Az incidenskezelés biztonságos menete ezért a következő:

1. Az oldal izolálása, a PHP-futtatás leállítása vagy legalább a külső kommunikáció korlátozása.
2. A fájlrendszer és az adatbázis pillanatfelvételének megőrzése a vizsgálathoz.
3. A futó PHP-folyamatok leállítása, a PHP-FPM újraindítása és az OPcache ürítése tárhelyszolgáltatói vagy rendszergazdai közreműködéssel.
4. Az MU-plugin és az összes másodlagos fájlpéldány eltávolítása.
5. A .user.ini, .htaccess, drop-in és sabloninjektálások megtisztítása.
6. Az adatbázis-opciók, transiensek, cronfeladatok, rejtett adminok és munkamenetek ellenőrzése.
7. Az adminisztrátori böngészők Service Worker- és webhelyadatainak törlése.
8. A tárhelyhez tartozó összes többi webhely átvizsgálása.
9. A WordPress, a bővítmények és a sablonok hivatalos forrásból történő újratelepítése, majd valamennyi hozzáférés cseréje.
10. Többszöri utóellenőrzés percekkel, órákkal és napokkal később.

Ha a tárhelyen nem állítható le a PHP, nem üríthető az OPcache, nem vizsgálhatók a folyamatok, és a szolgáltató sem végzi el ezeket ellenőrizhető módon, a helyreállítás eredménye nem igazolható kellő bizonyossággal. Ilyen helyzetben a tiszta újratelepítéssel végrehajtott tárhelyköltözés racionális kockázatcsökkentő lépés lehet.

Mit tanít a kilenc életű fertőzés?

Az első tanulság, hogy a biztonsági mentés kora önmagában nem bizonyítja annak tisztaságát. A fertőzés heteken át rejtve maradhat, vagy az oldal egy megmaradt hozzáférésen, adatbázis-komponensen, böngészőn, illetve másik webhelyen keresztül újra kompromittálódhat.

A második, hogy a WordPress-fertőzés nem kizárólag fájlrendszeri probléma. Vizsgálni kell az adatbázist, a felhasználókat, a munkameneteket, a cronfeladatokat, a PHP-konfigurációt, a böngészőket és megosztott tárhelyen a szomszédos telepítéseket is.

A harmadik pedig az, hogy az incidenskezeléshez együttműködő tárhelyszolgáltató szükséges. Egy ügyfél nem látja a PHP-FPM teljes folyamatállapotát, az OPcache tartalmát vagy a szerveroldali auditnaplókat. Ha egy fájl aktívan visszaíródik, ezek nélkül legfeljebb azt lehet dokumentálni, hogy a jelenség megtörténik – azt nem, hogy melyik folyamat okozza.

Ez a WordPress-kártevő azért különösen veszélyes, mert nem egyetlen búvóhelyet keres. Tartalékokat épít magának, figyeli a saját példányait, és a rendszer több rétegét használja fel arra, hogy visszatérjen. Egyetlen fájl törlése ezért nem feltétlenül a fertőzés végét jelenti. Néha csak elveszünk tőle egy életet a kilencből, de hacsak egy élete marad, visszaépíti a másik nyolcat is.

Ha hasonló problémával szembesül, keressen minket!