Накратко: Уеб шел разпознавате по нови или променени PHP файлове на нетипични места, по чужди процеси на потребителя на уеб сървъра и по необичайни връзки. Запазете следите, преди да изтриете нещо, и възстановете кода от чист източник. Само пачът не премахва задна вратичка.
Защо уеб шеловете са тема след PHP2Shell
Уязвимостите CVE-2026-109618 и CVE-2026-109619 в самия PHP позволяват отдалечено изпълнение на злонамерен код без вход в системата. Очевидна цел след успешна атака е трайна задна вратичка, т.е. уеб шел. Тя остава, дори PHP междувременно да е актуализиран.
Според медийни съобщения първи опит за атака е наблюдаван още на 17.10.2026, а пачовете последваха на 21.10. Който е бил уязвим през този период, трябва да провери целенасочено. Потвърдени Indicators of Compromise засега не са публикувани. Затова търсенето се опира на отклонения в поведението, а не на готов списък.
Ако намерите уеб шел на сървър с данни на клиенти: не изтривайте прибързано. Първо запазете доказателствата, после изолирайте сървъра и планирайте по-нататъшната обработка.
Как да разпознаете уеб шел: проверка на файловете
Повечето уеб шелове са PHP файлове в уеб директорията. Подозрителни са файлове, създадени или променени след 17.10., PHP файлове в папки за качване и кеш, както и файлове със замъглен код. Следните команди не променят нищо, само изброяват:
# 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:
# Отклонения от последното известно състояние в Git хранилището
git -C /var/www/projekt status --porcelain
Времевият печат може да е подправен. Затова не разчитайте само на датата на промяна на файла.
Кои признаци правят един файл подозрителен
| Признак | Защо буди подозрение |
|---|---|
| PHP файл в папка за качване или за изображения | Там трябва да има само медия |
Двойно разширение като .jpg.php или .php.png |
Маскировка като безобиден файл |
| Много дълги редове без пренасяне | Типично за пакетиран или шифрован код |
| Име на файл, подобно на основен файл, но го няма в оригиналния пакет | Маскировка в позната среда |
| Собственикът или правата се различават от съседните файлове | Файлът е създаден по друг начин |
Колкото повече признаци се съберат, толкова по-голяма е вероятността за находка. Отваряйте подозрителните файлове само като текст, никога през браузъра, защото извикване през уебсайта би изпълнило кода.
Проверка на процеси, връзки и cron задачи
Активният уеб шел често оставя следи извън файловата система. Потребителят на уеб сървъра, например www-data, apache или nginx, обикновено не стартира шелове, мрежови инструменти или компилатори.
# Процеси на типичните потребители на уеб сървъра
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 задачите, които изтеглят файлове от интернет. Проверете и логовете за достъп за заявки към файлове, които преди не са съществували. Как се прави това, описва наръчникът Анализ на логовете на уеб сървъра след атака.
Запазване на следите, преди да премахнете
Който първо изтрие, губи отговора на най-важните въпроси: как е влязъл атакуващият, какво е видял, кои данни са засегнати? Тези отговори са Ви нужни за евентуално уведомление по ОРЗД, за застрахователите и за решението дали други системи са застрашени.
Разумен ред:
- Документирайте състоянието: списък на процесите, мрежови връзки, влезли потребители.
- Копирайте подозрителните файлове и логове с контролна сума, без да ги отваряте или изпълнявате.
- Ако е възможно, направете образ на системата или snapshot на виртуалната машина.
- Изключете сървъра от мрежата или рязко ограничете достъпа до него.
При системи с чувствителни данни или възможен правен спор запазването трябва да е съдебно-технически коректно. Основна информация ще намерите на страницата ИТ криминалистика след атака срещу уеб сървър.
Правилно премахване на уеб шелове
Изтриването на отделен файл рядко е краят. Атакуващите често създават няколко достъпа: още файлове на скрити места, записи в конфигурационни файлове като .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. След това уебсайтът трябва известно време да се наблюдава по-внимателно, за да се забележи рано повторен достъп.
Как конкретно помага PHP SOS?
- Запазваме логовете, файловете и състоянието на системата по проследим начин, преди нещо да бъде променено.
- Търсим задни вратички във файловете, базата данни, cron задачите и конфигурацията и оценяваме находките.
- Инсталираме приложението наново от чист източник, сменяме достъпите и заздравяваме сървъра.
- Документираме инцидента, докато бъде приключен, като основа за уведомления и за застрахователите.
Хода на едно почистване описва услугата Премахване на злонамерен софтуер и уеб шелове.
Често задавани въпроси
Какво е уеб шел?
Уеб шелът е внедрен файл, най-често PHP, чрез който атакуващите могат да управляват сървъра отдалечено. Често се маскира като безобиден файл с неподозрително име и остава активен и след актуализация.
Открива ли антивирусният скенер всеки уеб шел?
Не. Скенерите разпознават известни модели, а нови или силно прикрити варианти се промъкват. За PHP2Shell освен това няма публикувани, потвърдени Indicators of Compromise, затова анализът на поведението е по-важен от списък със сигнатури.
Достатъчно ли е да изтрия намерения файл?
Обикновено не. Атакуващите често създават няколко достъпа, например още файлове, cron задачи или нови администраторски акаунти. Без анализ на причината и смяна на всички данни за достъп повторен достъп е вероятен.
Трябва ли да уведомя някого, след като открия уеб шел?
Ако може да са засегнати лични данни, може да съществува задължение за уведомяване по ОРЗД, по правило в рамките на 72 часа. Изяснете това с длъжностното лице по защита на данните или с адвокат; това не е правна консултация.