Как понять, что сайт взломали, и что делать в первые часы

Сайт может продолжать открываться и принимать заявки, даже если злоумышленник уже получил доступ к файлам, панели управления или серверу.

Некоторые атаки заметны сразу: посетителей перенаправляет на чужой ресурс, на страницах появляется реклама или браузер показывает предупреждение об опасности. Другие могут месяцами оставаться незаметными: злоумышленник создаёт скрытые страницы, отправляет спам, крадёт данные или сохраняет резервный доступ к серверу.

При подозрении на взлом недостаточно удалить найденный файл. Правильная последовательность действий выглядит так:

зафиксировать признаки → ограничить дальнейший ущерб → определить точку входа → удалить последствия → закрыть уязвимость → безопасно восстановить работу.

Атака, уязвимость и взлом — не одно и то же

В журналах практически любого публичного сайта можно увидеть попытки подобрать пароль, запросы к несуществующим административным страницам и автоматическое сканирование известных уязвимостей. Само по себе это ещё не означает успешный взлом.

О компрометации говорят последствия: несанкционированное изменение файлов или данных, появление неизвестных пользователей и ключей, выполнение постороннего кода, доступ к закрытой информации либо использование сервера для чужих задач.

Недоступность сайта, высокая нагрузка или ошибка базы данных также не доказывают атаку. Такие проблемы могут возникнуть из-за обновления, нехватки ресурсов или ошибки в коде. Поэтому важен не отдельный симптом, а совокупность признаков.

Явные признаки взлома сайта

Посетителей перенаправляет на другой сайт

Вредоносный редирект нередко срабатывает выборочно: только на мобильных устройствах, при переходе из поисковой системы, для незарегистрированных пользователей или один раз для каждого посетителя. Из-за этого владелец сайта может не увидеть проблему при обычной проверке.

Источник перенаправления может находиться в изменённом JavaScript, базе данных, конфигурации сайта, файле .htaccess, рекламном скрипте или подключаемом внешнем ресурсе.

На страницах появился чужой контент

К явным признакам относятся ссылки на казино и займы, поддельные формы входа, страницы на другом языке, скрытый текст, неизвестная реклама, изменённые контакты или реквизиты. Иногда злоумышленник добавляет файлы для загрузки либо подменяет отдельные элементы страницы, не затрагивая остальной сайт.

Браузер или поисковая система предупреждает об опасности

Google Search Console может сообщить о взломанном контенте, фишинговых страницах, вредоносном программном обеспечении или нежелательных загрузках. Проверьте раздел «Проблемы безопасности», сообщения владельцу ресурса и статус сайта в Google Safe Browsing.

Появились неизвестные администраторы

Проверьте пользователей CMS, учётные записи панели хостинга, системных пользователей сервера, SSH-ключи, FTP- и SFTP-доступы, пользователей базы данных, а также доступы к CDN, DNS и облачным сервисам. Неизвестная учётная запись часто используется как резервный путь после удаления основного вредоносного файла.

Сайт рассылает спам или создаёт необычную нагрузку

На проблему могут указывать неизвестные письма в почтовой очереди, попадание IP-адреса сервера в спам-листы, рост исходящих соединений или ограничения со стороны почтового провайдера.

Неожиданная нагрузка на CPU, память или сеть также требует проверки. Причиной могут быть скрытая рассылка, майнер, массовая генерация страниц, участие сервера в чужой атаке или вредоносные фоновые задачи. Однако высокая нагрузка сама по себе не является доказательством взлома.

Неочевидные признаки компрометации

В поиске появились неизвестные страницы

Проверьте выдачу с помощью запроса:

site:example.ru

Дополнительно используйте сочетания с тематикой, которой на сайте быть не должно. Злоумышленники могут создавать тысячи страниц, не связанных с основным меню. Иногда они отдаются только поисковому роботу, генерируются динамически или скрываются от владельца по IP-адресу и cookie.

Изменились мета-теги и сниппеты

Заголовки и описания страниц могут рекламировать посторонние услуги, хотя при открытии сайта всё выглядит нормально. В таком случае нужно проверить HTML-код, шаблоны CMS, SEO-плагины, данные в базе, кэш сайта и CDN. Полезно также сравнить содержимое, которое получает обычный посетитель и поисковый робот.

Появились неизвестные задания и службы

Вредоносный код может восстанавливать удалённые файлы по расписанию. Проверьте системный cron, задания отдельных пользователей и CMS, очереди фоновых задач, systemd timers, службы и автоматические задания панели хостинга.

Неожиданно меняются файлы

Особого внимания требуют PHP-файлы в каталогах изображений и загрузок, изменения системных файлов CMS без обновления, скрытые файлы в публичных каталогах, новые правила в .user.ini или .htaccess, а также код с длинными закодированными строками.

Название или внешний вид файла ещё не доказывают его вредоносность. Сравнивайте проект с доверенной версией из Git, чистым дистрибутивом CMS или резервной копией, созданной до инцидента.

Сервер обращается к неизвестным внешним ресурсам

Компрометированное приложение может устанавливать соединения с неизвестными доменами и IP-адресами, внешними API, хранилищами файлов, прокси или нестандартными портами. Поэтому анализировать нужно входящий и исходящий трафик.

Что делать в первые 60 минут

1. Назначьте ответственного за инцидент. Один человек должен фиксировать события, координировать разработчика, хостинг и руководство, а также вести единый журнал действий.
2. Зафиксируйте признаки. Сохраните скриншоты, URL, время обнаружения, сообщения браузера и Search Console, имена подозрительных файлов, IP-адреса и уже выполненные действия.
3. Сохраните технические данные. До удаления файлов желательно сделать снимок сервера, копию файловой системы и базы данных, сохранить журналы веб-сервера, PHP, приложения и авторизации, а также сведения о процессах, соединениях, пользователях, ключах и заданиях.
4. Ограничьте дальнейший ущерб. Временно закройте затронутую часть сайта, отключите уязвимую функцию, загрузку файлов, рассылку или скомпрометированный API-ключ. Полная остановка сервера нужна не всегда, но сайт нельзя оставлять публичным, если он вредит посетителям или раскрывает данные.
5. Меняйте доступы с доверенного устройства. Если компьютер администратора заражён, новый пароль также может попасть к злоумышленнику.
6. Подключите специалистов. В зависимости от масштаба сообщите хостинг-провайдеру, разработчику, ответственному за безопасность и руководству. При возможной утечке персональных или платёжных данных отдельно оцените обязанности по уведомлению согласно применимому законодательству.

При смене доступов проверьте корпоративную почту, аккаунт регистратора домена, панель хостинга, CMS, SSH- и SFTP-ключи, базу данных, резервное хранилище, API-токены и вебхуки. Недостаточно заменить пароль: нужно завершить активные сессии, отозвать старые ключи и удалить неизвестные способы восстановления доступа.

Чего нельзя делать сразу после обнаружения

Не удаляйте первый найденный файл и не считайте проблему решённой

Один вредоносный файл может быть только видимой частью атаки. Злоумышленник мог создать дополнительного администратора, добавить SSH-ключ, изменить cron, установить веб-шелл, встроить код в базу данных или скопировать пароли и токены.

Не восстанавливайте резервную копию вслепую

Копия может уже содержать вредоносный код, быть создана после проникновения или возвращать уязвимый компонент и старые пароли. Сначала определите предположительную дату и причину компрометации, затем выбирайте источник для восстановления.

Не обновляйте всё подряд до сохранения данных

Массовое обновление изменит тысячи файлов и затруднит построение временной линии. Сначала сохраните необходимые данные, затем обновляйте или переустанавливайте компоненты по контролируемому плану.

Не доверяйте старым ключам и одному сканеру

После инцидента прежний пароль или SSH-ключ нельзя считать надёжным только потому, что он продолжает работать. Антивирус или сканер CMS тоже не подтверждает, что закрыта точка входа, не осталось другой учётной записи и злоумышленник не закрепился на уровне сервера.

Как проводить расследование

Постройте временную линию

Определите, когда появились первые признаки и когда сайт последний раз точно работал нормально. Сопоставьте это с обновлениями, входами в административную часть, созданием файлов и пользователей, подозрительными запросами, исходящими соединениями и рассылкой.

Проверьте журналы

Наиболее полезны access- и error-логи nginx или Apache, журналы PHP-FPM, CMS и приложения, системный журнал, история SSH-авторизации, действия в панели хостинга и облачном кабинете, журналы базы данных, DNS, почты, WAF и CDN.

Копии журналов следует хранить там, где потенциальный злоумышленник не сможет их изменить или удалить.

Сравните файлы с доверенной версией

Используйте Git-репозиторий, официальный дистрибутив CMS, чистый релиз приложения, проверенную резервную копию или контрольные суммы. Проверяйте публичный каталог, конфигурацию, временные файлы, пользовательские загрузки, домашние каталоги, служебные скрипты, общие библиотеки и автоматические задания.

Проверьте CMS и базу данных

В базе могут находиться скрытые административные аккаунты, вредоносный JavaScript, изменённые шаблоны, спамные страницы, редиректы, неизвестные интеграции и токены. Поэтому очистка только файловой системы часто оказывается недостаточной.

Определите точку входа

Частые причины — уязвимая CMS или библиотека, необновлённый плагин, украденный пароль, заражённый компьютер разработчика, утёкший API-ключ, небезопасная загрузка файлов, ошибка в правах доступа, учётная запись бывшего сотрудника, уязвимость другого сайта на сервере или скомпрометированная сторонняя зависимость.

Если удалить последствия, но не закрыть точку входа, заражение обычно повторяется.

Как безопасно очистить и восстановить сайт

Предпочитайте чистую сборку

Если злоумышленник получил доступ к серверу или большому количеству файлов, надёжнее развернуть новое окружение, установить актуальное программное обеспечение, загрузить код из доверенного репозитория и перенести только проверенные данные. После этого создаются новые секреты и ключи, проверяется конфигурация, а трафик переключается после тестирования.

Точечная очистка на скомпрометированной системе не всегда позволяет доказать отсутствие скрытого доступа.

Закройте исходную уязвимость

До возвращения сайта в публичный доступ обновите или удалите уязвимые компоненты, сократите права на запись, исправьте обработку загрузок, закройте лишние порты, удалите неиспользуемые учётные записи, включите многофакторную аутентификацию и настройте мониторинг.

Проверяйте резервную копию до восстановления

Для выбранной копии нужно сопоставить дату создания с предполагаемой датой проникновения, проверить файлы и базу, версии CMS и зависимостей, а также актуальность пользовательских данных. Иногда безопаснее восстановить только данные, а программный код развернуть заново.

Смените все связанные секреты

После восстановления замените или отзовите пароли администраторов и базы данных, SSH-ключи, API-токены, SMTP-пароли, секреты вебхуков, ключи платёжных систем, CDN и облачного хранения, ключи подписи сессий и резервные коды MFA. Затем принудительно завершите активные сессии.

Как убедиться, что сайт действительно очищен

• Нет неизвестных администраторов, системных пользователей и SSH-ключей.
• Проверены cron-задачи, timers, службы и фоновые процессы.
• Код совпадает с доверенной версией, а в каталогах загрузок нет исполняемых файлов.
• База данных проверена на посторонние вставки и скрытые аккаунты.
• Все пароли, ключи и токены заменены, активные сессии отозваны.
• Уязвимый компонент обновлён, исправлен или удалён.
• Исходящие соединения и почтовая очередь соответствуют штатной работе.
• DNS, аккаунт регистратора и сертификаты не изменены.
• Search Console не показывает новых проблем безопасности.
• Формы, оплата и интеграции работают штатно.
• Настроены уведомления о повторных признаках атаки.

Что контролировать после запуска

В первые дни после восстановления следите за изменениями файлов, созданием пользователей, входами в административную часть, ошибками приложения, нагрузкой на сервер, исходящими соединениями, почтовой очередью, новыми заданиями, изменениями DNS и сертификатов. Отдельно проверяйте Search Console и появление неизвестных страниц в поиске.

Если проблема повторилась, вероятно, осталась незакрытая точка входа, скрытый механизм восстановления или скомпрометированный внешний доступ.

Когда можно разбираться самостоятельно

Владелец небольшого сайта может выполнить первичные действия самостоятельно, если есть проверенная резервная копия, известна причина проблемы, нет признаков системного доступа и не обрабатываются критичные данные. Также нужны навыки работы с CMS, файлами и журналами и возможность безопасно ограничить работу сайта.

Когда нужен специалист

Лучше не экспериментировать на рабочем сервере, если злоумышленник получил административный или системный доступ, обнаружены веб-шеллы и неизвестные процессы, затронуто несколько сайтов, могли быть раскрыты персональные или платёжные данные либо сервер рассылает спам.

Помощь специалиста также нужна, если вредоносные файлы появляются повторно, неизвестна точка входа, нет чистой резервной копии, сайт критичен для бизнеса или необходимо сохранить данные для расследования.

Как снизить риск повторного взлома

После устранения инцидента обновите CMS и зависимости, сократите права файлов и пользователей, включите многофакторную аутентификацию, храните секреты вне исходного кода и используйте отдельные учётные записи сотрудников. Резервные копии нужно регулярно проверять, а изменения файлов, журналы и аномалии — контролировать автоматически.

Подробный профилактический список собран в статье «Как защитить сайт: основные меры безопасности».

Вывод

Главный признак успешного реагирования — не исчезновение видимого баннера или редиректа. Необходимо понять, как злоумышленник получил доступ, какие действия успел выполнить и где мог сохранить возможность вернуться.

Правильная последовательность:

сохранить данные → ограничить ущерб → расследовать → закрыть точку входа → восстановить чистую систему → заменить доступы → усилить мониторинг.

Чем раньше начата фиксация событий и чем меньше хаотичных изменений сделано на сервере, тем выше вероятность установить причину и восстановить сайт без повторного заражения.

Официальные источники

• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• OWASP: Logging Cheat Sheet
• OWASP: Secrets Management Cheat Sheet
• CISA: Compromised Web Servers and Web Shells
• Google Search Console: Security Issues Report
• Google: восстановление сайта после взлома