Накратко: Дали един сървър е хакнат чрез PHP2Shell, не може да се види по един-единствен признак. Няма публикувани, потвърдени Indicators of Compromise; откриването се основава на анализ на поведението. Типични признаци са нови PHP файлове, непознати cron задачи и необичайни връзки. Първо запазете логовете от 20 октомври нататък, преди да промените каквото и да било.
Има ли недвусмислени признаци за атака с PHP2Shell?
Не, и това е честният отговор. За много известни уязвимости производителите или фирмите по сигурност публикуват конкретни следи: имена на файлове, контролни суми, IP адреси. За PHP2Shell такива потвърдени Indicators of Compromise досега няма.
Какво е известно: според съобщения в медиите първият опит за атака е наблюдаван на 17 октомври, четири дни преди пачовете от 21 октомври. Cloudflare съобщи за други опити. Потвърдени успешни атаки в голям мащаб според BSI отначало не са били известни. Който е бил достъпен незащитен между 17 октомври и собствения си пач, трябва затова да провери, вместо да се надява.
За оценката значение има най-вече периодът. Между първия наблюдаван опит за атака на 17 октомври и пачовете на 21 октомври не е имало официална актуализация. Всеки публично достъпен PHP сървър е бил през това време потенциално уязвим. Колко дълго сървърът Ви е бил отворен допълнително, зависи от това кога е внесена актуализацията и PHP е рестартиран. Колкото по-дълъг е този период и колкото по-чувствителни са данните, например клиентски акаунти, поръчки или кандидатури, толкова по-основателна трябва да бъде проверката.
Типични признаци, че един сървър е хакнат
След успешно изпълнение на код атакуващите обикновено се опитват да се закрепят и да използват сървъра. От това възникват признаци, които не са специфични за PHP2Shell, но имат значение при всяка проверка за проникване:
- Нови или променени PHP файлове, особено в директории за качвания, кеш или изображения, където иначе не лежат PHP файлове.
- Непознати cron задачи или планирани задачи, например за потребителя на уеб сървъра.
- Необичайни изходящи връзки към непознати адреси, високо мрежово натоварване или изпращане на имейли, което никой не е задействал.
- Нови администраторски акаунти в CMS или магазин, променени пароли, непознати SSH ключове.
- Необичайно натоварване: постоянно високо натоварване на процесора от непознати процеси, често знак за крипто майнинг.
- Видими последици: пренасочвания към чужди страници, спам страници в индекса на Google, предупреждения в браузъра или в Search Console.
Нито един от тези признаци сам по себе си не доказва проникване, а липсата им не доказва обратното. Решаваща е цялостната картина.
Първи проверки без унищожаване на следи
Преди да изтриете или рестартирате нещо: запазете логовете. Специализираната преса съветва сървърните логове от 20 октомври нататък да се съхраняват. Копирайте логовете на уеб сървъра, на PHP и на системата на сигурно място извън сървъра.
След това помагат проверки само за четене. Пътищата и потребителските имена се различават според системата:
# PHP файлове, променени от 17.10. насам
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP файлове в директории за качвания (пример WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# cron задачи на потребителя на уеб сървъра и в цялата система
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# активни мрежови връзки с процес
ss -tunp
# последни влизания
last -n 30
Имайте предвид: атакуващите могат да фалшифицират времевите печати на файловете. Незабележителен резултат от find затова не е оправдание. Как да анализирате логове целево, описва страницата Анализ на логовете на уеб сървъра след атака; как да откриете задни вратички, страницата Разпознаване и премахване на уеб шелове.
Ако намерите конкретни признаци, например непознат PHP файл в папката за качвания: не го изтривайте, не настройвайте наново, не „поправяйте набързо“ приложението. Изключете сървъра от мрежата или го изолирайте, запазете логовете и образ на системата и започнете структурирана обработка на инцидента.
Какво не трябва да правите
- Само да пачнете и да продължите. Пачът не премахва вече внедрен злонамерен софтуер.
- Незабавно да изтриете подозрителни файлове. Така изчезват доказателствата какво е станало и кои данни може да са засегнати.
- Да настроите сървъра наново, преди да е направен архив. Причината остава неясна, а задна вратичка в базата данни или в данните за достъп преживява новата инсталация.
- Да възстановите стари резервни копия без проверка. И едно резервно копие може вече да съдържа задната вратичка.
- Да забравите данните за достъп. След изпълнение на код паролите за базата данни, API ключовете и други данни за достъп може да са изтекли от конфигурационни файлове. Подновете ги след почистването, не преди това, за да не прочете новите още активният атакуващ.
Когато съмнението се потвърди
Тогава става дума за повече от техника. Проверете с Вашето длъжностно лице по защита на данните дали е нужно уведомяване по ОРЗД; срокът е 72 часа от узнаването, подробности на страницата Задължение за уведомяване по ОРЗД. Информирайте рано Вашия киберзастраховател, ако има такъв, и изяснете с адвокат дали да се подаде сигнал. Ние даваме общи бележки по темата, а не правни консултации.
Как помага PHP SOS конкретно?
С нашия Incident Response отработваме едно съмнение структурирано:
- Запазване: Логове от 20 октомври нататък и, където е нужно, образ на системата, преди нещо да бъде променено.
- Разследване: Анализ на поведението на файлове, процеси, връзки и акаунти; при нужда с доказателствена стойност пред съд чрез ИТ форензика.
- Почистване и затваряне: Премахване на задни вратички, актуализиране на PHP, подновяване на данните за достъп, заздравяване на сървъра.
- Документиране, докато инцидентът бъде приключен и документиран, като основа за защитата на данните, застраховката и управителите.
Често задавани въпроси
Доказва ли PHP актуализацията, че сървърът ми е чист?
Не. Пачът затваря уязвимостта за в бъдеще, но не премахва вече внедрен злонамерен софтуер. Той не казва и дали преди пача някой е проникнал.
Има ли скенер, който сигурно разпознава атаки с PHP2Shell?
Досега не. Няма публикувани, потвърдени Indicators of Compromise, по които скенер би могъл да търси целево. Скенерите за зловреден софтуер намират познати уеб шелове, но оценката на един сървър се основава на анализ на поведението.
Трябва ли да съобщя съмнението на органа по защита на данните?
Това зависи от това дали може да са засегнати лични данни. ОРЗД предвижда за подлежащи на уведомяване нарушения на сигурността на данните срок от 72 часа от узнаването. Изяснете го рано с Вашето длъжностно лице по защита на данните или с адвокат; ние не даваме правни консултации.
Да настроя ли хакнатия сървър просто наново?
Не като първа стъпка. Първо запазете логовете и, ако е възможно, образ на системата. Който настрои наново веднага, губи следите, които показват какво е станало и кои данни може да са засегнати.