Miért fertőződik újra a WordPress oldalam a tisztítás után?

Ha a WordPress oldal a tisztítás után újra megfertőződik, az általában nem azt jelenti, hogy ugyanaz a törölt fájl „visszanőtt”. Valami lehetővé teszi, hogy a támadó vagy egy megmaradt kódrészlet ismét létrehozza. Ez lehet rejtett backdoor, sérülékeny plugin, ellopott jelszó, fertőzött másik weboldal ugyanazon a tárhelyen vagy rosszul megválasztott visszaállítási pont.

A tartós helyreállítás ezért nem ér véget a látható malware törlésével. Meg kell válaszolni, honnan indult a támadás, milyen hozzáférést szerzett a támadó, mit módosított, és milyen mechanizmus biztosította a fennmaradást.

Ha csak a tünetet távolítjuk el, az oldal lehet, hogy néhány óráig vagy napig tisztának látszik, majd ismét átirányít, spamet generál vagy ismeretlen fájlokat hoz létre.

Az újrafertőződés tipikus tünetei

• a törölt PHP fájl ugyanott újra megjelenik,
• új, véletlenszerű nevű fájlok keletkeznek,
• visszatér a mobilos vagy Google-ből érkező átirányítás,
• a Search Console ismét spam URL-eket mutat,
• új admin felhasználó jelenik meg,
• a .htaccess többször visszaíródik,
• a pluginfrissítések után ismét leáll vagy fertőzött lesz az oldal,
• a víruskereső mindig ugyanazt a fájlt törli, de nem találja a létrehozóját,
• több, egy tárhelyen lévő WordPress oldal felváltva fertőződik.

Az időbeli minta fontos. Ha a fertőzés mindig egy cron futás, admin belépés vagy bizonyos HTTP kérés után tér vissza, ez közelebb visz a forráshoz.

Miért tér vissza a malware?

Megmaradt egy backdoor

A látható payload mellett gyakran van egy kisebb loader vagy webshell. Lehet egy pluginfájlban, az uploads könyvtárban, must-use pluginként vagy akár a WordPress könyvtárán kívül. Feladata csak annyi, hogy kérésre újra letöltse a kártékony kódot.

Nyitva maradt a sérülékenység

Ha a fertőzés egy sebezhető pluginon keresztül jutott be, a fájlok törlése nem javítja a plugint. A támadó automatizált keresője újra megtalálhatja ugyanazt az endpointot.

Kiszivárgott egy hozzáférés

Admin-, tárhely-, SFTP- vagy vezérlőpult-jelszó is kiszivároghatott. Az XML-RPC és a belépési felület automatizált próbálkozások célpontja lehet. Ha csak egy WordPress jelszó változik, de a támadó másik csatornával rendelkezik, a kompromittálás folytatódik.

Másik oldal fertőzi vissza

Megosztott tárhelyen több weboldal futhat azonos rendszerfelhasználó alatt. Egy elavult, elfelejtett WordPress telepítésből a támadó hozzáférhet a már kitisztított oldal fájljaihoz is.

Fertőzött mentés került vissza

A mentés készülhetett a kompromittálás után, vagy tartalmazhatott olyan backdoort, amely még nem okozott látható tünetet. A dátum önmagában nem bizonyítja, hogy egy mentés tiszta.

Kompromittáltsági jelek és perzisztencia

Vizsgálandó helyek:

wp-content/uploads/**/*.php
wp-content/mu-plugins/*.php
wp-content/cache/**/*.php
wp-config.php
.htaccess
../logs/
../tmp/

Gyanús mechanizmusok:

WordPress cron esemény ismeretlen callbackkel
rendszerszintű cron vagy scheduled task
automatikusan betöltött wp_options érték
ismeretlen admin vagy application password
pluginba rejtett távoli kódletöltés
közvetlen POST kérés egy PHP backdoorra

Ne csak módosítási dátum alapján keress. A támadó megtarthat régi timestampet, és a kód lehet adatbázisban vagy külső szerveren is.

Hogyan derítsd ki a kiindulási pontot?

1. Mentsd le a fertőzött állapotot és a naplókat.
2. Készíts idővonalat az első tünettől az újrafertőződésig.
3. Hasonlítsd össze a két fertőzött állapot fájljait.
4. Határozd meg, melyik fájl jelent meg először.
5. Keresd meg az azt megelőző HTTP kéréseket az access logban.
6. Ellenőrizd az admin belépéseket, felhasználókat és application passwordöket.
7. Vizsgáld át a WordPress és rendszerszintű cron feladatokat.
8. Nézd át az ugyanazon tárhelyen futó összes weboldalt.
9. Ellenőrizd a telepített pluginverziók ismert sérülékenységeit.
10. Forgasd le az összes releváns hitelesítő adatot.

A WebShield fejlett naplózási rendszere abban segít, hogy ne csak a létrejött fertőzött fájlt lássuk, hanem azt a kérést vagy eseményt is, ahonnan a folyamat elindult. Így célzottan kezelhető a kiindulási pont.

Hogyan tisztítsd meg tartósan?

• Cseréld le a WordPress core fájlokat hivatalos forrásból.
• Telepítsd újra tiszta csomagból a szükséges plugineket és sablonokat.
• Töröld a nem használt bővítményeket, sablonokat és régi telepítéseket.
• Távolítsd el a backdoorokat minden tárhelyen lévő oldalról.
• Javítsd vagy cseréld le a sérülékeny komponenst.
• Vizsgáld át az adatbázist, cron eseményeket és admin fiókokat.
• Cseréld le az admin-, tárhely-, SFTP-, adatbázis- és API-jelszavakat.
• Generálj új WordPress salts értékeket.
• Kapcsold be a kétfaktoros hitelesítést.
• Üríts minden cache-réteget.
• Figyeld fokozottan a fájl- és HTTP-aktivitást a helyreállítás után.

Ha az oldal átirányít, a WordPress átirányítás megszüntetéséről szóló cikk segít a feltételes payload vizsgálatában. Ha a scanner tisztát jelez, nézd át azt is, mi maradhat rejtve a Wordfence előtt.

Miért nem elég egy mentés?

A mentés a rendelkezésre állást segíti, nem azonosítja a támadót és nem zárja be a belépési pontot. Ha sérülékeny plugin, ellopott jelszó vagy szomszédos fertőzött oldal marad a rendszerben, a visszaállított példány is veszélyben van.

Gyakori mentésre szükség van, de a mentéseket külső helyen kell tárolni és visszaállítással tesztelni. A WordPress biztonsági GYIK részletesen tárgyalja a mentési gyakoriságot, a menedzselt WordPress védelem pedig a folyamatos monitorozás és helyreállítás szerepét.

Hogyan építs incidens-idővonalat?

Az újrafertőződés vizsgálatánál ne csak fájllistát készíts. Egy idővonal segít összekötni az eseményeket. Indulj az első biztosan ismert tünetből, majd haladj visszafelé a naplókban.

09:12 gyanús POST kérés egy plugin endpointjára
09:12 új PHP fájl jön létre az uploads könyvtárban
09:14 közvetlen kérés érkezik az új fájlra
09:15 ismeretlen admin fiók készül
09:18 módosul a .htaccess
10:03 megjelenik az első látogatói átirányítás

Ez a sorrend többet mond, mint az, hogy öt fertőzött fájlt találtunk. Megmutathatja, melyik volt a kezdeti kérés, melyik fájl szolgált backdoorként, és milyen másodlagos hozzáférést hozott létre a támadó.

Ha nincs alkalmazásszintű napló, használd a webszerver access logját, tárhelynaplókat, fájl-metaadatokat, adatbázis-időpontokat és külső monitorozást. Az időzónákat egységesítsd, különben ugyanaz az esemény több órás eltéréssel jelenhet meg.

Hogyan bizonyítható, hogy a helyreállítás tartós?

Teljes bizonyosság ritkán adható egyetlen ellenőrzéssel. A bizalom több jelből épül:

• a WordPress core ellenőrzőösszegei megfelelnek,
• a komponensek ismert, tiszta forrásból származnak,
• nincs futtatható PHP indokolatlan könyvtárban,
• az adminok és application passwordök listája ismert,
• a cron események indokolhatók,
• a sérülékeny belépési pontot javították,
• minden érintett hozzáférést lecseréltek,
• a fájlmonitor nem jelez ismeretlen változást,
• több várható támadási cikluson át nem tér vissza a tünet.

A megfigyelési idő az incidenstől függ. Egy óránként aktiválódó cron gyorsan tesztelhető, egy ritkább támadási hullámhoz hosszabb monitorozás kell. Dokumentáld, mit ellenőriztetek, milyen hozzáférések változtak, és melyik sérülékenységet zártátok le.

Ugyanaz a fertőzés tért vissza, vagy új támadás történt?

Fontos különbség, hogy a korábbi perzisztencia aktiválódott-e újra, vagy egy új támadó ugyanazon vagy másik résen keresztül jutott be. Ha ugyanazok a fájlnevek, kódminták, külső domainek és HTTP útvonalak jelennek meg, valószínűbb a megmaradt backdoor vagy nyitva hagyott eredeti belépési pont.

Új kompromittálásra utalhat:

• más malware család vagy eltérő obfuszkáció,
• teljesen más támadott plugin endpoint,
• új forrás IP-k és user-agent minták,
• eltérő cél, például átirányítás helyett adatlopás,
• olyan friss plugin sérülékenység, amely az első incidenskor még nem volt ismert.

Ehhez őrizd meg mindkét incidens mintáit. A fájl hash, teljes kód, külső domainek, kérések és idővonal összehasonlítható. Ha minden tisztításkor csak törlöd a fájlokat és kiüríted a naplókat, elveszíted ezt az összevetési lehetőséget.

Az sem kizárt, hogy ugyanazon automatizált támadó másik módszerre váltott. Például az első alkalommal egy sérülékeny upload funkciót használt, később pedig a megszerzett admin fiókkal telepített plugint. A két esemény technikailag eltérő, de ugyanahhoz a kezdeti kompromittáláshoz kapcsolódik.

Mit ellenőrizz több weboldalas tárhelyen?

Listázd az összes domaint, aldomaint, staging példányt és elfelejtett teszttelepítést. Ellenőrizd, melyik rendszerfelhasználó tulajdonában vannak a fájlok, és képes-e az egyik oldal PHP folyamata írni a másik könyvtárába.

Minden telepítésnél vizsgáld át a verziókat, adminokat, cron feladatokat és ismeretlen PHP fájlokat. Egyetlen elavult oldal elég lehet az egész tárhely visszafertőzéséhez. Hosszabb távon használj külön rendszerfelhasználót, elkülönített PHP poolt és a szükséges minimumra szűkített fájljogosultságokat.

Megelőzés

Az újrafertőződés kockázatát csökkenti:

• felügyelt, gyors frissítés,
• sérülékenységfigyelés,
• minimális admin jogosultság,
• kétfaktoros hitelesítés,
• fájlváltozás- és belépésfigyelés,
• HTTP kérések megőrzése és elemzése,
• több weboldalas tárhelyek megfelelő izolációja,
• gyakori mentés,
• rendszeres visszaállítási próba.

Mikor kell szakértő?

Kérj segítséget, ha a fertőzés már egyszer visszatért, több oldal érintett, nem áll rendelkezésre napló, üzletileg kritikus webshopról van szó, vagy nem tudod biztosan, melyik hozzáférés kompromittálódott.

Ilyenkor a gyors törlés helyett incidenskezelési folyamat kell. Az SOS helyreállítás során a cél a működés helyreállítása mellett a perzisztencia és a belépési pont megszüntetése.

Gyakori hibák újrafertőződés esetén

Az egyik leggyakoribb hiba a takarítás ismétlése ugyanazzal a módszerrel. Ha az első scanner csak a payloadot találta meg, a második futtatás is ugyanazt fogja törölni, miközben a létrehozó backdoor változatlan marad.

Szintén kockázatos csak a „gyanúsan friss” fájlokra koncentrálni. A támadó módosíthat régi fájlt, visszaállíthat timestampet, adatbázisba rejthet kódot vagy távoli szerverről töltheti be a payloadot. A fájlidő segédjel, nem ítélet.

Kerüld ezeket:

• a naplók törlését a vizsgálat előtt,
• a fertőzött állapot mentés nélküli felülírását,
• csak az admin jelszó cseréjét,
• az összes tárhelyen lévő másik oldal figyelmen kívül hagyását,
• a sérülékeny plugin változatlan visszatelepítését,
• ismeretlen fájlok automatikus fehérlistázását,
• a helyreállítás utáni monitorozás kihagyását.

Ügynökségi környezetben különösen fontos tisztázni a felelősséget. Ki frissíti a plugineket, ki kezeli a tárhelyet, kinél vannak az admin hozzáférések, és ki figyeli a riasztásokat? Ha mindenki azt feltételezi, hogy a másik fél végzi ezeket, ugyanaz a rés hosszú ideig nyitva maradhat.

Mit adj át a helyreállítás végén?

Egy jó incidenslezárás nem csak annyit mond, hogy „kész”. Tartalmazza:

• a megtalált fertőzés rövid leírását,
• az ismert vagy valószínű belépési pontot,
• az eltávolított backdoorokat és fiókokat,
• a frissített vagy lecserélt komponenseket,
• a lecserélendő hozzáférések listáját,
• az elvégzett ellenőrzéseket,
• a fennmaradó bizonytalanságokat,
• a következő napokra javasolt monitorozást.

Ez azért is fontos, mert ha később új esemény történik, összehasonlítható az előző incidenssel. Így eldönthető, hogy ugyanaz a támadási út tért vissza, vagy egy új sérülékenységről van szó.

Összefoglalás

A WordPress azért fertőződik újra, mert megmaradt egy visszajutási lehetőség: backdoor, sebezhető plugin, ellopott hozzáférés, fertőzött mentés vagy másik kompromittált oldal. Tartós eredményt a teljes környezet, a naplók és az események idővonalának vizsgálata ad. A cél nem pusztán a malware törlése, hanem annak bizonyítása, hogy a támadó útját is lezártuk.

• WordPress
• újrafertőződés
• backdoor
• incidenskezelés