Hátsó kapuk és webshell-ek: hogyan jut vissza a támadó a weboldaladra?

Mi az a hátsó kapu?

A hátsó kapu, angolul backdoor, egy rendszerhez való hozzáférés nem dokumentált módja. A NIST fogalomtára biztonsági kockázatként határozza meg. A kifejezés tágabb egy adott fájltípusnál vagy programnyelvnél: a hozzáférés módját írja le. [2]

Szemléltető, kitalált példa: egy módosított bővítmény bizonyos feltételek teljesülésekor megkerüli a rendes jogosultság-ellenőrzést, és olyan műveletet is engedélyez, amelyet a látogató egyébként nem végezhetne el. Ebben a példában a hátsó kapu a rejtett hozzáférési lehetőség.

Ettől érdemes megkülönböztetni a jogosulatlanul létrehozott vagy módosított felhasználói fiókot. A támadó ilyen módon is fenntarthat hozzáférést, de a művelet a szokásos bejelentkezési felületet használhatja. A MITRE a fiókok manipulálását külön technikaként tárgyalja. [3]

A köznyelvben mindkettőre mondhatjuk, hogy „hagytak maguknak egy hátsó bejáratot”. A vizsgálatban azonban fontos külön rögzíteni a rejtett kódot és a visszaélésre használható fiókot, mert eltérő intézkedést igényelnek.

Mi az a webshell?

A webshell a webkiszolgálón elhelyezett, webes kapcsolaton keresztül használható szkript. A támadónak előre meghatározott műveleteket vagy parancsvégrehajtási lehetőséget biztosíthat. Tartozhat hozzá kezelőfelület, de külön kliensprogram is kommunikálhat vele. [1]

A Microsoft kutatói például PHP-, ASP- és JSP-nyelven készült webshell-eket is ismertetnek. Az ilyen kód távoli hozzáférésre, adatlopásra, további eszközök elhelyezésére és más támadói tevékenységek támogatására használható. [4]

Kitalált példa: egy feltöltött PHP-állomány olyan kéréseket fogad, amelyekkel a támadó fájlműveleteket végezhet. Az oldal látogatói közben továbbra is a megszokott honlapot látják. A példában a webshell külön hozzáférési eszköz; a főoldal megjelenése nem mutatja meg a jelenlétét.

Technikai magyarázat: A webshell nem feltétlenül a weboldal adminisztrációs bejelentkezésén keresztül működik. Emiatt a CMS-ben végzett jelszócsere és a webshell eltávolítása külön feladat. A webes elérésű szkript használhatóságát saját működése és a kiszolgáló beállításai határozzák meg. [1]

Miben különbözik a webshell a hátsó kaputól?

A hátsó kapu általános hozzáférési fogalom, a webshell pedig konkrét webes eszköz. A webshell használható hátsó kapuként, de a jogosulatlan visszatéréshez más mechanizmusok is kapcsolódhatnak. [1–3]

Megfigyelt megoldás	Mit érdemes róla külön megállapítani?
Webshell	Milyen műveleteket fogad, és milyen jogosultsággal fut?
Módosított alkalmazáskód	Megkerül-e hozzáférési vagy jogosultsági ellenőrzést?
Jogosulatlan fiók vagy fiókmódosítás	Ki használhatja, és milyen műveleteket végezhet vele?
Időzített feladat	Milyen kódot indít, milyen környezetben és milyen jogosultsággal?
Automatikus fájlbetöltés	Melyik fájl töltődik be, honnan ered, és mit csinál?

A táblázat vizsgálati szempontokat ad. Egy fájl vagy beállítás kártékony jellege a működésének és eredetének elemzésével állapítható meg.

Hogyan kerülhet webshell egy weboldalra?

A webshell jelenléte és az eredeti bejutási út külön kérdés. Az egyik lehetséges belépési pont a veszélyesen megvalósított fájlfeltöltés. Az OWASP ezért a megengedett fájltípusok, a tartalom, a méret, a jogosultságok és a tárolás módjának együttes ellenőrzését tárgyalja. [5]

A Joomla fejlesztői dokumentációja is bemutatja, hogy egy korlátozatlan feltöltés veszélyes programfájl elhelyezéséhez és bizonyos körülmények között kódfuttatáshoz vezethet. [6]

Kitalált eseménysor: egy komponens feltöltési hibáján keresztül a támadó elhelyez egy webshellt. Később a komponenst frissítik, de a külön elhelyezett állomány megmarad. Ebben a példában a hibás feltöltési út kijavítása nem távolítja el a korábban feltöltött fájlt.

A vizsgálatnak ezért két eredményre kell törekednie: feltárni, hogyan szereztek hozzáférést, és azonosítani, mire használták azt. Ha a bejutás útja nem állapítható meg, ezt bizonytalanságként kell dokumentálni.

Hol rejtőzhet a hozzáférést fenntartó működés?

Külön fájlban vagy meglévő program részeként

A webshell mérete és megvalósítása változó lehet. A Microsoft ismertetője szerint az észlelést nehezítheti, hogy a támadók a webalkalmazás meglévő kódjába is beilleszthetnek rosszindulatú részeket, és a webshell-ek átalakíthatók. [4]

Ezért egy ismeretlen fájl keresése csak a vizsgálat egyik része. A meglévő összetevők összehasonlítása a megbízható eredeti csomagokkal más jellegű eltéréseket is feltárhat.

PHP-beállításokon keresztül

A PHP auto_prepend_file beállítása megad egy fájlt, amelyet a fő programfájl előtt automatikusan feldolgoz a rendszer. Ez dokumentált szolgáltatás, szabályos felhasználási lehetőségekkel. [7]

A könyvtárszintű PHP-beállítások egyik forrása a .user.ini fájl lehet. A PHP dokumentációja szerint ennek feldolgozása a CGI/FastCGI futtatási módhoz kötődik; a tényleges működés a környezet beállításaitól függ. [8]

Technikai magyarázat: A .user.ini vagy az auto_prepend_file jelenléte önmagában nem fertőzésjel. A vizsgálat tárgya a beállítás eredete, a hivatkozott fájl és annak működése. Kitalált példa: a támadó egy ilyen beállítással egy jogosulatlan programot töltet be a rendes weboldalkód előtt. Ekkor a rendes programfájl önmagában történő ellenőrzése nem tárja fel a teljes végrehajtási láncot.

Időzített feladatban

A MITRE a cron feladatokkal történő visszaélést külön technikaként kezeli. Az időzítés programok ismételt végrehajtására és hozzáférés fenntartására is felhasználható. [9]

Kitalált példa: egy jogosulatlan feladat időnként újra létrehoz egy korábban törölt állományt. Ebben az esetben a fájl ismételt megjelenése mögött az azt létrehozó feladatot is meg kell találni. A cronfeladatok jelentős része természetesen szabályos üzemeltetési célt szolgál; az értékeléshez a meghívott programot kell azonosítani.

WordPress: miért fontos a mu-plugins vizsgálata?

A WordPress must-use pluginjei, röviden mu-pluginjei, különleges betöltésű bővítmények. Az alapértelmezett helyük a wp-content/mu-plugins könyvtár, és automatikusan engedélyezettek. A normál bővítménylistából nem ugyanúgy kapcsolhatók ki, mint a hagyományos pluginek. [10]

Ez hasznos lehet tárhelyszolgáltatói vagy egyedi üzemeltetési funkciókhoz. A hivatalos WordPress-dokumentáció ugyanakkor arra is felhívja a figyelmet, hogy egy kompromittált mu-plugin nehezebben észrevehető. [10]

Kitalált példa: a tulajdonos kikapcsolja a hagyományos bővítményeket, de a jogosulatlan működést egy mu-plugin okozza. A próbából ezért nem következik, hogy minden bővítményként betöltődő kódot kizárt a vizsgálatból.

Technikai magyarázat: A WordPress alapértelmezésben a mu-plugins könyvtár közvetlen PHP-fájljait tölti be automatikusan. Egy ilyen fájl további alkönyvtári kódot is betölthet. A vizsgálatnál ezért a belépő fájlt és annak hivatkozásait együtt kell értékelni. [10]

A WordPress saját ütemezési rendszere szintén külön ellenőrzési terület. A wp_schedule_event() ismétlődő eseményt regisztrál, amelynek esedékes végrehajtását az alapértelmezett működésben weboldalkérések indítják. Ez nem azonos a kiszolgáló cronrendszerével. [11]

Egy ütemezett esemény azonosítása után annak kezelőjét és eredetét is meg kell vizsgálni. Az esemény neve önmagában nem árulja el, hogy a hozzá tartozó program szabályos-e.

Joomla: a feltöltött fájlon túl is kell vizsgálódni

A Joomla dokumentációja a fájlfeltöltési hibák mellett az SQL-injectiont, az XSS-t és a CSRF-et is külön tárgyalja. Ezek a bejutás vagy visszaélés lehetséges módjai; a hátsó kapu és a webshell a hozzáférés más szempontját írja le. [6]

Joomla-oldalnál is hasznos megkülönböztetni a telepített összetevő eredeti hibáját, a jogosulatlan fájlt és a felhasználói hozzáférést. A komponens javítása, a fájl eltávolítása és egy ismeretlen jogosultság megszüntetése három külön feladat lehet.

Kitalált példa: a támadó egy hibán keresztül fájlt helyez el, majd további művelettel magas jogosultságú fiókot hoz létre. A fájl törlése után a fiók megmarad. A helyreállítást ilyenkor a fájlok és az adatbázisban kezelt hozzáférések szempontjából is értékelni kell.

Ez a példa nem egy Joomla-verzió konkrét hibáját állítja. Azt szemlélteti, hogy a támadó az eredeti bejutás után további hozzáférést alakíthat ki.

Milyen jelek utalhatnak hátsó kapura vagy webshellre?

A fájleltérések és a futó folyamatok, illetve webes események együtt adhatnak használható nyomokat. A Microsoft webshell-vizsgálatai is többféle jel összekapcsolására építenek. [4]

Vizsgálatot indokolhat például egy ismeretlen programfájl, egy nem várt automatikus betöltés, egy jogosulatlan fiókmódosítás vagy egy indokolatlan időzített feladat. Ezeket az oldal dokumentált állapotához kell viszonyítani.

Megfigyelés	Mit mondhat róla a vizsgálat?
Eltérő fájltartalom	Az eredeti csomaghoz képest változás történt; a változás célját elemezni kell.
Kérés egy gyanús fájlra	Az adott címet elérték vagy elérni próbálták; a végrehajtás eredményét külön kell igazolni.
Visszatérő állomány	Meg kell keresni, melyik művelet hozta ismét létre.
Ismeretlen adminisztrátor	A fiók eredetét, jogosultságait és használatát kell feltárni.

Az OWASP naplózási útmutatója többek között a hitelesítési, jogosultsági és alkalmazásesemények rögzítését javasolja. A webkiszolgáló naplója és az alkalmazás naplója eltérő részleteket tartalmazhat. A vizsgálatban azt is rögzíteni kell, mely időszakról milyen adat áll rendelkezésre. [12]

Egy megszokott fájlnév nem igazolja a szabályos tartalmat. Ugyanígy egy szokatlan név sem elég a kártékony működés megállapításához. A bizonyítható megállapítás alapja a konkrét működés és az összefüggő nyomok elemzése.

Miért térhet vissza a fertőzés?

Az alábbiak lehetséges forgatókönyvek, nem egy adott weboldal diagnózisa:

1. Megmaradt egy hozzáférési eszköz. Egy külön webshell vagy más jogosulatlan kód továbbra is használható.
2. Megmaradt egy felhasználói hozzáférés. A támadó egy módosított vagy megszerzett fiókkal újra elvégzi a műveletet.
3. Egy megmaradt feladat újra létrehozza a fájlt. A fájl helyett a létrehozó mechanizmus maradt aktív.
4. Ismét kihasználják a bejutási pontot. Az eredeti sérülékenység továbbra is elérhető.
5. A helyreállítás visszahozza az érintett állapotot. A visszatöltött csomag vagy mentés maga is tartalmazza a problémás összetevőt.

Az első három mechanizmus szakmai hátterét a webshell-ekről, fiókmódosításról és időzített feladatokról szóló leírások adják. [1][3][9] A konkrét okot azonban a saját környezet bizonyítékai alapján kell meghatározni.

Kitalált példa: ugyanaz az idegen hivatkozás jelenik meg másodszor is. Ez lehet megmaradt program eredménye, de lehet újabb támadói művelet is. Az azonos tünetből nem dönthető el, melyik történt.

Hogyan érdemes felépíteni a helyreállítást?

A NIST incidenskezelési ajánlása az észlelés, reagálás és helyreállítás feladatait a szervezet kockázatkezeléséhez kapcsolja. Egy weboldalra alkalmazva is fontos, hogy a működés visszaállítása és az esemény feltárása összekapcsolódjon. [13]

Az alábbi munkamenet szerkesztett, általános javaslat. Az intézkedések sorrendjét a folyamatban lévő károkozás és a hozzáférhető környezet alapján kell alakítani.

1. A nyomok megőrzése és a károkozás korlátozása

Rögzíteni érdemes a riasztásokat, időpontokat, érintett címeket és gyanús állományokat. A vizsgálati másolatot el kell különíteni a használatra szánt mentéstől. Folyamatban lévő károkozásnál a hozzáférés korlátozását a tárhelyszolgáltatóval vagy az üzemeltetővel összehangolva lehet megtervezni.

2. A hozzáférések és a végrehajtási lánc feltárása

A kérdés az, melyik kód, beállítás, fiók vagy feladat ad műveletvégzési lehetőséget. A vizsgálatba az azonosított fájl hivatkozásai és a hozzá tartozó beállítások is beletartoznak. A bizonytalan pontokat külön kell megjelölni.

3. Megbízható állapot kialakítása

Az összetevőket megbízható forrásból származó példányokhoz érdemes viszonyítani. A WordPress hardening útmutatója a megbízható beszerzési forrásokat, a jogosultságokat, a mentéseket és a megfigyelést is a biztonsági feladatok közé sorolja. [14]

4. A bejutás és a megmaradt hozzáférések kezelése

A talált állományok mellett az érintett fiókokat és hozzáférési adatokat is értékelni kell. A jelszócsere végrehajtása önmagában nem ad választ arra, maradt-e önálló webshell. Fordítva: a webshell eltávolítása után is szükség lehet a hozzáférések rendezésére.

5. Ellenőrzés és követés

Dokumentálni kell, mit állítottak helyre, mit ellenőriztek és mi maradt bizonytalan. A további naplózás segíthet az újabb események észlelésében. Az ellenőrzés eredményét a lefedett fájlokhoz, adatokhoz és időszakhoz kell kötni.

Mit igazol a WordPress ellenőrzőösszeg-vizsgálata?

A WP-CLI wp core verify-checksums parancsa az alaprendszer fájljait ellenőrzi. A bővítményekhez külön wp plugin verify-checksums parancs tartozik, amely a WordPress.org által biztosított ellenőrzőösszegeket használja. [15][16]

Technikai magyarázat: Az egyező alaprendszerfájlokból nem következik az adatbázis, az összes egyedi fájl, a PHP-beállítások vagy a felhasználói hozzáférések tisztasága. A bővítményvizsgálatnál az is számít, hogy az adott összetevőhöz rendelkezésre áll-e összehasonlítási adat. A fájleltérés pedig önmagában nem minősíti a változtatást kártékonyként.

Ezért a sikeres ellenőrzés egy meghatározott vizsgálat eredménye. A teljes helyreállítás értékelésében további szempontokkal együtt használható.

Gyakori kérdések

A jelszócsere eltávolítja a webshellt?

A CMS-jelszó megváltoztatása nem töröl egy külön elhelyezett programfájlt. Azt külön kell azonosítani és kezelni. A webshell hozzáférési módját az elemzett kód működése alapján lehet megállapítani. [1]

Ha az oldal rendesen betöltődik, lehet rajta rejtett hozzáférés?

Igen. A webshell a kiszolgálón futó külön hozzáférési eszköz lehet; a rendes oldal megjelenése nem írja le az összes végrehajtható program működését. [4]

Minden mu-plugin vagy .user.ini gyanús?

Nem. Mindkettő dokumentált, szabályos funkció. A vizsgálat feladata a konkrét tartalom, eredet és rendeltetés ellenőrzése. [8][10]

Biztosan hátsó kapu maradt, ha visszatér a probléma?

Ezt a tünet alapján nem lehet kijelenteni. Megmaradt hozzáférés és újabb bejutás is lehet a magyarázat. Az okot az eseménysor és a rendelkezésre álló nyomok alapján kell feltárni.

A következő rész: átirányítások és rosszindulatú JavaScript

A hozzáférés fenntartása után a látogatók felé megjelenő működést vesszük szemügyre. A következő cikk az átirányító fertőzésekről és rosszindulatú JavaScript-kódokról szól: hol kereshetők, hogyan különíthetők el az egyes működési módok, és miért számítanak a megfigyelés körülményei.

Források

Forrásellenőrzés: 2026. október 21. A kitalált példák nem ügyfélincidensek leírásai. A vizsgálati táblázatok és a helyreállítás munkamenete szerkesztett javaslatok; az adott oldal diagnózisát külön vizsgálat adhatja meg.

1. MITRE ATT&CK: Web Shell – T1505.003.
2. NIST: Backdoor.
3. MITRE ATT&CK: Account Manipulation – T1098.
4. Microsoft Security Research (2021): Web shell attacks continue to rise. A működés és észlelés magyarázatához; a cikk nem állít 2026-os gyakorisági adatot.
5. OWASP: File Upload Cheat Sheet.
6. Joomla: Common Vulnerabilities.
7. PHP: Core php.ini directives – auto_prepend_file.
8. PHP: .user.ini files.
9. MITRE ATT&CK: Cron – T1053.003.
10. WordPress: Must-Use Plugins.
11. WordPress: wp_schedule_event().
12. OWASP: Logging Cheat Sheet.
13. NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
14. WordPress: Hardening WordPress.
15. WordPress: wp core verify-checksums.
16. WordPress: wp plugin verify-checksums.

Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !