# Разпознаване и премахване на уеб шел

> Разпознаване на уеб шел след PHP2Shell: намерете подозрителни PHP файлове, процеси и връзки, запазете следите и премахнете задните вратички.

Източник: https://phpsos.de/bg/ratgeber/webshell-erkennen/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Уеб шел разпознавате по нови или променени PHP файлове на нетипични места, по чужди процеси на потребителя на уеб сървъра и по необичайни връзки. Запазете следите, преди да изтриете нещо, и възстановете кода от чист източник. Само пачът не премахва задна вратичка.

## Защо уеб шеловете са тема след PHP2Shell

Уязвимостите CVE-2026-109618 и CVE-2026-109619 в самия PHP позволяват отдалечено изпълнение на злонамерен код без вход в системата. Очевидна цел след успешна атака е трайна задна вратичка, т.е. уеб шел. Тя остава, дори PHP междувременно да е актуализиран.

Според медийни съобщения първи опит за атака е наблюдаван още на 17.10.2026, а пачовете последваха на 21.10. Който е бил уязвим през този период, трябва да провери целенасочено. Потвърдени Indicators of Compromise засега не са публикувани. Затова търсенето се опира на отклонения в поведението, а не на готов списък.

> **Действайте веднага:**
> Ако намерите уеб шел на сървър с данни на клиенти: не изтривайте прибързано. Първо запазете доказателствата, после изолирайте сървъра и планирайте по-нататъшната обработка.

## Как да разпознаете уеб шел: проверка на файловете

Повечето уеб шелове са PHP файлове в уеб директорията. Подозрителни са файлове, създадени или променени след 17.10., PHP файлове в папки за качване и кеш, както и файлове със замъглен код. Следните команди не променят нищо, само изброяват:

```bash
# PHP файлове, променени след 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls

# PHP файлове в папки за качване, кеш или tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls

# Типично замъгляване: eval в комбинация с декодиране
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"

# Необичайно дългите редове често сочат към пакетиран код
grep -rlE ".{3000,}" /var/www --include="*.php"
```

Намерените файлове са индикации, а не доказателства. Някои добавки законно използват кодиран код. Сравнявайте подозрителните файлове с оригиналния пакет на производителя. Най-надеждно е сравнение с контролни суми или със система за контрол на версиите като Git:

```bash
# Отклонения от последното известно състояние в Git хранилището
git -C /var/www/projekt status --porcelain
```

Времевият печат може да е подправен. Затова не разчитайте само на датата на промяна на файла.

### Кои признаци правят един файл подозрителен

| Признак | Защо буди подозрение |
|---|---|
| PHP файл в папка за качване или за изображения | Там трябва да има само медия |
| Двойно разширение като `.jpg.php` или `.php.png` | Маскировка като безобиден файл |
| Много дълги редове без пренасяне | Типично за пакетиран или шифрован код |
| Име на файл, подобно на основен файл, но го няма в оригиналния пакет | Маскировка в позната среда |
| Собственикът или правата се различават от съседните файлове | Файлът е създаден по друг начин |

Колкото повече признаци се съберат, толкова по-голяма е вероятността за находка. Отваряйте подозрителните файлове само като текст, никога през браузъра, защото извикване през уебсайта би изпълнило кода.

## Проверка на процеси, връзки и cron задачи

Активният уеб шел често оставя следи извън файловата система. Потребителят на уеб сървъра, например `www-data`, `apache` или `nginx`, обикновено не стартира шелове, мрежови инструменти или компилатори.

```bash
# Процеси на типичните потребители на уеб сървъра
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"

# Отворени мрежови връзки със съответния процес
sudo ss -tunap | grep -E "php|www-data|apache|nginx"

# Планирани задачи на потребителя на уеб сървъра
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
```

Подозрителни са трайните изходящи връзки към непознати адреси, процесите с криптични имена и cron задачите, които изтеглят файлове от интернет. Проверете и логовете за достъп за заявки към файлове, които преди не са съществували. Как се прави това, описва наръчникът [Анализ на логовете на уеб сървъра след атака](https://phpsos.de/bg/ratgeber/logfiles-auswerten/).

## Запазване на следите, преди да премахнете

Който първо изтрие, губи отговора на най-важните въпроси: как е влязъл атакуващият, какво е видял, кои данни са засегнати? Тези отговори са Ви нужни за евентуално уведомление по ОРЗД, за застрахователите и за решението дали други системи са застрашени.

Разумен ред:

1. Документирайте състоянието: списък на процесите, мрежови връзки, влезли потребители.
2. Копирайте подозрителните файлове и логове с контролна сума, без да ги отваряте или изпълнявате.
3. Ако е възможно, направете образ на системата или snapshot на виртуалната машина.
4. Изключете сървъра от мрежата или рязко ограничете достъпа до него.

При системи с чувствителни данни или възможен правен спор запазването трябва да е съдебно-технически коректно. Основна информация ще намерите на страницата [ИТ криминалистика след атака срещу уеб сървър](https://phpsos.de/bg/leistungen/it-forensik/).

## Правилно премахване на уеб шелове

Изтриването на отделен файл рядко е краят. Атакуващите често създават няколко достъпа: още файлове на скрити места, записи в конфигурационни файлове като `.htaccess` или `.user.ini`, нови администраторски акаунти в приложението или cron задачи. Надеждното почистване следва тези стъпки:

- Приведете PHP до поправена версия (8.5.12, 8.4.27, 8.3.36, 8.2.35 или потвърден backport) и рестартирайте всички PHP процеси.
- Инсталирайте кода на приложението наново от чист източник, вместо да поправяте отделни файлове.
- Прехвърляйте само проверено съдържание като качени файлове и база данни и там търсете целенасочено внедрен код.
- Сменете всички данни за достъп: база данни, SSH, FTP, администраторски акаунти, API ключове.
- Ограничете правата за запис на уеб сървъра до необходимото и забранете изпълнението на PHP в папките за качване.

За WordPress има собствени типични скривалища, описани в наръчника [Откриване на задни вратички в WordPress](https://phpsos.de/bg/ratgeber/backdoor-wordpress-finden/). След това уебсайтът трябва известно време да се наблюдава по-внимателно, за да се забележи рано повторен достъп.

## Как конкретно помага PHP SOS?

- Запазваме логовете, файловете и състоянието на системата по проследим начин, преди нещо да бъде променено.
- Търсим задни вратички във файловете, базата данни, cron задачите и конфигурацията и оценяваме находките.
- Инсталираме приложението наново от чист източник, сменяме достъпите и заздравяваме сървъра.
- Документираме инцидента, докато бъде приключен, като основа за уведомления и за застрахователите.

Хода на едно почистване описва услугата [Премахване на злонамерен софтуер и уеб шелове](https://phpsos.de/bg/leistungen/malware-entfernung/).


## Често задавани въпроси

**Какво е уеб шел?**  
Уеб шелът е внедрен файл, най-често PHP, чрез който атакуващите могат да управляват сървъра отдалечено. Често се маскира като безобиден файл с неподозрително име и остава активен и след актуализация.

**Открива ли антивирусният скенер всеки уеб шел?**  
Не. Скенерите разпознават известни модели, а нови или силно прикрити варианти се промъкват. За PHP2Shell освен това няма публикувани, потвърдени Indicators of Compromise, затова анализът на поведението е по-важен от списък със сигнатури.

**Достатъчно ли е да изтрия намерения файл?**  
Обикновено не. Атакуващите често създават няколко достъпа, например още файлове, cron задачи или нови администраторски акаунти. Без анализ на причината и смяна на всички данни за достъп повторен достъп е вероятен.

**Трябва ли да уведомя някого, след като открия уеб шел?**  
Ако може да са засегнати лични данни, може да съществува задължение за уведомяване по ОРЗД, по правило в рамките на 72 часа. Изяснете това с длъжностното лице по защита на данните или с адвокат; това не е правна консултация.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)
- [ОРЗД, чл. 33: Уведомяване на надзорния орган](https://dsgvo-gesetz.de/art-33-dsgvo/)