# Jak poznat a odstranit webshell

> Jak poznat webshell po PHP2Shell: najděte podezřelé soubory PHP, procesy a spojení, zajistěte stopy a nechte zadní vrátka bezpečně odstranit.

Zdroj: https://phpsos.de/cs/ratgeber/webshell-erkennen/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Webshell poznáte podle nových nebo změněných souborů PHP na nezvyklých místech, podle cizích procesů uživatele webového serveru a podle neobvyklých spojení. Zajistěte stopy dřív, než cokoli smažete, a obnovte kód z čistého zdroje. Samotná záplata zadní vrátka neodstraní.

## Proč jsou webshelly po PHP2Shell téma

Zranitelnosti CVE-2026-109618 a CVE-2026-109619 v samotném PHP umožňují spuštění škodlivého kódu na dálku bez přihlášení. Logickým cílem po úspěšném útoku je trvalá zadní vrátka, tedy webshell. Zůstane na místě, i když je PHP mezitím aktualizováno.

Podle zpráv médií byl první pokus o útok pozorován už 17. 10. 2026, záplaty následovaly 21. 10. Kdo byl v tomto období zranitelný, měl by se cíleně podívat. Potvrzené indikátory kompromitace zatím zveřejněny nejsou. Hledání se proto opírá o nápadnosti v chování, nikoli o hotový seznam.

> **Jednejte ihned:**
> Pokud na serveru s údaji zákazníků najdete webshell: nic ukvapeně nemažte. Nejdřív zajistěte důkazy, pak server izolujte a naplánujte další postup.

## Jak webshell poznat: kontrola souborů

Většina webshellů jsou soubory PHP ve webovém adresáři. Nápadné jsou soubory, které vznikly nebo se změnily po 17. 10., soubory PHP ve složkách pro nahrávání a cache a soubory se zakódovaným kódem. Následující příkazy nic nemění, jen vypisují:

```bash
# Soubory PHP změněné od 17. 10. 2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls

# Soubory PHP ve složkách upload, cache nebo tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls

# Typické zakódování: eval v kombinaci s dekódováním
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"

# Neobvykle dlouhé řádky často značí zabalený kód
grep -rlE ".{3000,}" /var/www --include="*.php"
```

Nálezy jsou indicie, nikoli důkazy. Některé pluginy legitimně používají kódovaný kód. Porovnejte podezřelé soubory s původním balíčkem výrobce. Nejspolehlivější je porovnání s kontrolními součty nebo s verzovacím systémem, například Git:

```bash
# Odchylky od posledního známého stavu v repozitáři Git
git -C /var/www/projekt status --porcelain
```

Časové razítko lze zfalšovat. Nespoléhejte proto jen na datum změny souboru.

### Podle čeho je soubor podezřelý

| Znak | Proč je nápadný |
|---|---|
| Soubor PHP ve složce pro nahrávání nebo obrázky | Tam mají ležet jen média |
| Dvojitá přípona jako `.jpg.php` nebo `.php.png` | Maskování za neškodný soubor |
| Velmi dlouhé řádky bez zalomení | Typické pro zabalený nebo šifrovaný kód |
| Název podobný jádrovému souboru, ale není v původním balíčku | Maskování ve známém prostředí |
| Vlastník nebo práva se liší od sousedních souborů | Soubor vznikl jinou cestou |

Čím více znaků se sejde, tím vyšší je pravděpodobnost nálezu. Podezřelé soubory otevírejte jen jako text, nikdy přes prohlížeč, protože zavolání přes web by kód spustilo.

## Kontrola procesů, spojení a úloh cron

Aktivní webshell často zanechává stopy mimo souborový systém. Uživatel webového serveru, například `www-data`, `apache` nebo `nginx`, běžně nespouští shelly, síťové nástroje ani kompilátory.

```bash
# Procesy typických uživatelů webového serveru
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"

# Otevřená síťová spojení s příslušným procesem
sudo ss -tunap | grep -E "php|www-data|apache|nginx"

# Plánované úlohy uživatele webového serveru
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
```

Nápadná jsou trvalá odchozí spojení na neznámé cíle, procesy s nesrozumitelnými názvy a úlohy cron, které stahují soubory z internetu. Zkontrolujte také přístupové logy na požadavky na soubory, které dříve neexistovaly. Jak na to, popisuje příručka [Vyhodnocení logů webového serveru po útoku](https://phpsos.de/cs/ratgeber/logfiles-auswerten/).

## Zajistěte stopy dřív, než cokoli odstraníte

Kdo maže jako první, ztratí odpověď na nejdůležitější otázky: jak se útočník dostal dovnitř, co viděl, jaká data jsou dotčena? Tyto odpovědi potřebujete pro případné hlášení podle GDPR, pro pojišťovny a pro rozhodnutí, zda jsou ohroženy další systémy.

Rozumné pořadí:

1. Zdokumentujte stav: seznam procesů, síťová spojení, přihlášení uživatelé.
2. Zkopírujte podezřelé soubory a logy s kontrolním součtem, aniž byste je otevírali nebo spouštěli.
3. Pokud možno vytvořte obraz systému nebo snapshot virtuálního stroje.
4. Odpojte server od sítě nebo přístup výrazně omezte.

U systémů s citlivými daty nebo možným soudním sporem by mělo zajištění proběhnout forenzně čistě. Souvislosti najdete v článku [IT forenzní analýza po útoku na webový server](https://phpsos.de/cs/leistungen/it-forensik/).

## Jak webshelly čistě odstranit

Smazání jednoho souboru je zřídka konec. Útočníci často zřizují více přístupů: další soubory na skrytých místech, záznamy v konfiguračních souborech jako `.htaccess` nebo `.user.ini`, nové účty správce v aplikaci nebo úlohy cron. Spolehlivé vyčištění sleduje tyto kroky:

- Přivést PHP na opravený stav (8.5.12, 8.4.27, 8.3.36, 8.2.35 nebo potvrzený backport) a restartovat všechny procesy PHP.
- Kód aplikace nasadit znovu z čistého zdroje místo opravování jednotlivých souborů.
- Převzít jen ověřený obsah, například nahrané soubory a databázi, a v něm cíleně hledat podstrčený kód.
- Změnit všechny přístupové údaje: databáze, SSH, FTP, účty správců, klíče API.
- Omezit práva webového serveru k zápisu na nezbytné minimum a zakázat spouštění PHP ve složkách pro nahrávání.

Pro WordPress existují vlastní typické úkryty, které popisuje příručka [Jak najít zadní vrátka ve WordPressu](https://phpsos.de/cs/ratgeber/backdoor-wordpress-finden/). Poté by měl být web po nějakou dobu přísněji sledován, aby byl opětovný přístup včas zaznamenán.

## Jak konkrétně pomáhá PHP SOS?

- Logy, soubory a stav systému zajistíme doložitelným způsobem, dříve než cokoli změníme.
- Hledáme zadní vrátka v souborech, databázi, úlohách cron a konfiguraci a nálezy zařadíme.
- Aplikaci znovu nasadíme z čistého zdroje, změníme přístupy a server zabezpečíme.
- Incident dokumentujeme až do uzavření jako podklad pro hlášení a pojišťovny.

Průběh čištění popisuje služba [Nechat odstranit malware a webshelly](https://phpsos.de/cs/leistungen/malware-entfernung/).


## Časté dotazy

**Co je webshell?**  
Webshell je podstrčený soubor, většinou PHP, přes který mohou útočníci server ovládat na dálku. Často se maskuje jako neškodný soubor s nenápadným názvem a zůstává aktivní i po aktualizaci.

**Najde antivirový skener každý webshell?**  
Ne. Skenery poznají známé vzory, nové nebo silně zakódované varianty jim proklouznou. K PHP2Shell navíc nejsou zveřejněny žádné potvrzené indikátory kompromitace (IOC), proto je důležitější analýza chování než seznam signatur.

**Stačí nalezený soubor smazat?**  
Většinou ne. Útočníci často zřizují několik přístupů, například další soubory, úlohy cron nebo nové účty správce. Bez analýzy příčiny a výměny všech přístupových údajů je opětovný přístup pravděpodobný.

**Musím po nálezu webshellu něco hlásit?**  
Pokud mohou být dotčeny osobní údaje, může existovat oznamovací povinnost podle GDPR, zpravidla do 72 hodin. Ujasněte si to s pověřencem pro ochranu osobních údajů nebo s právníkem; nejde o právní poradenství.

## Zdroje

- [php.net: bezpečnostní oznámení](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI: německý Spolkový úřad pro informační bezpečnost](https://www.bsi.bund.de/)
- [GDPR čl. 33: oznámení dozorovému úřadu](https://dsgvo-gesetz.de/art-33-dsgvo/)