Stručně: Zda byl server napaden přes PHP2Shell, nelze poznat z jediného znaku. Neexistují zveřejněné potvrzené indikátory kompromitace (IOC); detekce se opírá o analýzu chování. Typickými známkami jsou nové soubory PHP, neznámé cron úlohy a neobvyklá spojení. Nejprve zajistěte logy od 20. října, než cokoli změníte.
Existují jednoznačné známky útoku PHP2Shell?
Ne, a to je poctivá odpověď. U mnoha známých zranitelností zveřejňují výrobci nebo bezpečnostní firmy konkrétní stopy: názvy souborů, kontrolní součty, IP adresy. Pro PHP2Shell takové potvrzené indikátory kompromitace zatím neexistují.
Co je známo: podle zpráv médií byl první pokus o útok pozorován 17. října, čtyři dny před záplatami z 21. října. Cloudflare hlásil další pokusy. Potvrzené úspěšné útoky v širokém měřítku nebyly podle BSI (německý Spolkový úřad pro informační bezpečnost) zpočátku známy. Kdo byl mezi 17. říjnem a vlastní záplatou nechráněně dostupný, měl by proto kontrolovat, ne doufat.
Pro posouzení je rozhodující především období. Mezi prvním pozorovaným pokusem o útok 17. října a záplatami 21. října neexistovala žádná oficiální aktualizace. Každý veřejně dostupný server s PHP byl v této době potenciálně napadnutelný. Jak dlouho byl váš server otevřený navíc, závisí na tom, kdy byla aktualizace nasazena a PHP restartováno. Čím delší toto období a čím citlivější data, například zákaznické účty, objednávky nebo přihlášky, tím důkladnější by měla být kontrola.
Typické známky napadeného serveru
Po úspěšném spuštění kódu se útočníci většinou snaží uchytit a server využít. Z toho vyplývají známky, které nejsou specifické pro PHP2Shell, ale počítají se při každé kontrole průniku:
- Nové nebo změněné soubory PHP, zejména ve složkách pro nahrávání, cache nebo obrázky, kde jinak žádné soubory PHP neleží.
- Neznámé cron úlohy nebo plánované úkoly, například pro uživatele webového serveru.
- Neobvyklá odchozí spojení na neznámé adresy, vysoké zatížení sítě nebo rozesílání pošty, které nikdo nevyvolal.
- Nové administrátorské účty v CMS nebo e-shopu, změněná hesla, neznámé klíče SSH.
- Nápadná zátěž: trvale vysoké vytížení CPU neznámými procesy, často známka těžby kryptoměn.
- Viditelné následky: přesměrování na cizí stránky, spamové stránky v indexu Google, varování v prohlížeči nebo v Search Console.
Žádná z těchto známek sama průnik nedokazuje a jejich absence nedokazuje opak. Rozhodující je celkový obraz.
První kontroly bez zničení stop
Než cokoli smažete nebo restartujete: zajistěte logy. Odborný tisk radí uchovat logy serveru od 20. října. Zkopírujte logy webového serveru, PHP a systému na bezpečné místo mimo server.
Poté pomohou čistě čtecí kontroly. Cesty a uživatelská jména se liší podle systému:
# Soubory PHP změněné od 17. 10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# Soubory PHP ve složkách pro nahrávání (příklad WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cron úlohy uživatele webového serveru a systémové
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktivní síťová spojení s procesem
ss -tunp
# poslední přihlášení
last -n 30
Pozor: útočníci mohou časová razítka souborů falšovat. Nenápadný výsledek find proto není osvobozením. Jak logy cíleně vyhodnotit, popisuje stránka Vyhodnocení logů webového serveru po útoku; jak najít zadní vrátka, stránka Rozpoznání a odstranění webshellů.
Pokud najdete konkrétní indicie, například neznámý soubor PHP ve složce pro nahrávání: nemazat, nenasazovat znovu, aplikaci „rychle neopravovat“. Server odpojit od sítě nebo izolovat, zajistit logy a obraz systému a zahájit strukturované zpracování incidentu.
Co byste neměli dělat
- Jen záplatovat a pokračovat. Záplata už vložený škodlivý software neodstraní.
- Podezřelé soubory ihned smazat. Tím zmizí doklady o tom, co se stalo a která data mohou být dotčena.
- Nasadit server znovu dřív, než je vše zajištěno. Příčina zůstane nejasná a zadní vrátka v databázi nebo přístupových údajích přežijí novou instalaci.
- Obnovit staré zálohy bez kontroly. I záloha může zadní vrátka už obsahovat.
- Zapomenout na přístupové údaje. Po spuštění kódu mohla z konfiguračních souborů uniknout hesla k databázi, klíče API a další přístupové údaje. Obnovte je po vyčištění, ne dříve, aby je aktivní útočník hned neviděl také.
Pokud se podezření potvrdí
Pak jde o víc než o techniku. Ověřte s pověřencem pro ochranu osobních údajů, zda je nutné hlášení podle GDPR; lhůta činí 72 hodin od okamžiku, kdy jste se o incidentu dozvěděli, podrobnosti na stránce Oznamovací povinnost podle GDPR. Včas informujte svou kyberpojišťovnu, pokud ji máte, a s právníkem ujasněte, zda podat trestní oznámení. K tomu dáváme obecné pokyny, ne právní poradenství.
Jak konkrétně pomáhá PHP SOS?
Prostřednictvím naší reakce na incidenty (incident response) zpracujeme podezření strukturovaně:
- Zajistit: logy od 20. října a, kde je to nutné, obraz systému, než se cokoli změní.
- Vyšetřit: analýza chování souborů, procesů, spojení a účtů; v případě potřeby soudně použitelně pomocí IT forenzní analýzy.
- Vyčistit a uzavřít: odstranit zadní vrátka, aktualizovat PHP, obnovit přístupové údaje, zabezpečit server.
- Zdokumentovat, dokud není incident uzavřen a zdokumentován, jako podklad pro ochranu osobních údajů, pojištění a vedení.
Časté dotazy
Dokazuje aktualizace PHP, že je můj server čistý?
Ne. Záplata zranitelnost uzavře pro budoucnost, ale už vložený škodlivý software neodstraní. Neříká ani nic o tom, zda se někdo dostal dovnitř před záplatou.
Existuje skener, který útoky PHP2Shell spolehlivě pozná?
Zatím ne. Neexistují zveřejněné potvrzené indikátory kompromitace (IOC), podle kterých by skener mohl cíleně hledat. Skenery malwaru najdou známé webshelly, hodnocení serveru se ale opírá o analýzu chování.
Musím podezření nahlásit úřadu pro ochranu osobních údajů?
Záleží na tom, zda mohou být dotčeny osobní údaje. GDPR stanoví pro hlášení porušení zabezpečení údajů lhůtu 72 hodin od okamžiku, kdy jste se o něm dozvěděli. Ujasněte to včas s pověřencem pro ochranu osobních údajů nebo s právníkem; právní poradenství neposkytujeme.
Mám napadený server prostě nasadit znovu?
Ne jako první krok. Nejprve zajistěte logy a, pokud je to možné, obraz systému. Kdo ihned nasadí znovu, ztratí stopy, které ukazují, co se stalo a která data mohou být dotčena.