Восстановление сайта после взлома

Клиент: Сайт производственной компании на 1С-Битрикс.
Проблема: Злоумышленники подобрали слабый пароль к админ-панели и получили полный доступ. Они создали нового пользователя с правами администратора, добавили в настройках сайта скрытый редирект на свои ресурсы и загрузили несколько вредоносных скриптов.
Что сделано:

1. Диагностика: Проанализировал логи доступа в Битриксе и обнаружил множественные попытки входа с разных IP, а затем успешный вход с паролем. В файловой системе нашёл подозрительные php-файлы в папке upload и в корне.
2. Очистка и восстановление: Удалил всех подозрительных пользователей из базы данных (через phpMyAdmin). Удалил все вредоносные файлы, найденные сканером и вручную. Восстановил файлы ядра и модулей из резервной копии (благо, была). Проверил настройки системы — обнаружил в файле /bitrix/.settings.php и в базе данных вредоносные вставки, отвечающие за редирект. Удалил их.
3. Закрытие уязвимостей и усиление защиты: Сменил пароль администратора на сложный. Настроил двухфакторную аутентификацию для всех пользователей с доступом к админке. Включил защиту от подбора паролей (брутфорс) в настройках Битрикс. Ограничил доступ к папке /bitrix/admin/ по IP-адресам сотрудников (через .htaccess).
4. Работа с поисковыми системами: Сайт не попал под санкции, так как редирект был скрытым и недолгим, но для профилактики проверил статус в Вебмастере.
5. Профилактика: Настроил уведомления в Telegram о всех входах в админку.
6. Результат: Сайт восстановлен. Клиент осознал цену слабых паролей. Теперь вход в админку возможен только по сложному паролю и с подтверждением по SMS.

Клиент: Сервис по бронированию отелей на Django (Python).
Проблема: Сайт работал, но администраторы заметили странную активность: в базу данных добавлялись подозрительные записи, а иногда сайт перенаправлял на сторонние ресурсы. Антивирусных сканеров для Django мало, проблема сложная.
Что сделано:

1. Диагностика и анализ инцидента: Проанализировал логи сервера и нашёл запросы к странным URL, которых не должно быть. Проверил зависимости проекта (файл requirements.txt). Обнаружил, что одна из используемых библиотек была обновлена до версии, содержащей известную уязвимость, позволяющую выполнить произвольный код. Злоумышленники использовали эту уязвимость. В файлах проекта нашёл несколько новых файлов с подозрительным именем и содержимым (бэкдоры на Python).
2. Очистка и восстановление: Удалил все подозрительные файлы. Откатил версию уязвимой библиотеки до безопасной. Проверил базу данных на наличие вредоносных записей — нашёл и удалил их. Восстановил чистые версии файлов из системы контроля версий (Git).
3. Закрытие уязвимостей и усиление защиты: Зафиксировал безопасную версию библиотеки в requirements.txt. Обновил все остальные зависимости до актуальных безопасных версий. Настроил регулярное сканирование зависимостей на наличие уязвимостей с помощью специальных инструментов (например, safety). Сменил все ключи доступа и пароли.
4. Работа с поисковыми системами: Проверил статус в Google Search Console и Яндекс.Вебмастере — сайт не был помечен, так как взлом был направлен на кражу данных, а не на порчу контента для пользователей.
5. Профилактика: Внёс в процесс разработки обязательную проверку безопасности зависимостей перед обновлением.
6. Результат: Уязвимость закрыта, сайт очищен. Клиент внедрил регулярный аудит безопасности кода. Инцидент не повлиял на репутацию, так как был обнаружен на ранней стадии.

Клиент: Интернет-магазин детских товаров на WooCommerce.
Проблема: Утром клиент обнаружил, что сайт не открывается, а вместо главной страницы — чёрный экран с надписью «Hacked by ...». Паника, звонки от клиентов, репутация под угрозой. Хостинг уже приостановил аккаунт.
Что сделано:

1. Диагностика и анализ инцидента: Первым делом запросил у хостинга доступ к логам ошибок и дампу базы данных. В логах обнаружил множественные запросы к уязвимому скрипту в плагине для галерей, который не обновлялся 2 года. Злоумышленники использовали известную уязвимость для загрузки бэкдора (веб-шелла).
2. Очистка и восстановление: Через FTP нашёл и удалил все подозрительные файлы (несколько скриптов в папке wp-content/uploads и в корне). Они и выполняли роль бэкдора и выводили страницу взлома. Восстановил все файлы ядра WordPress и плагинов из официальных источников, заменив ими подозрительные. Проверил базу данных — в ней были добавлены вредоносные JavaScript-вставки в описание товаров (которые перенаправляли на фишинг). Очистил их прямыми SQL-запросами. Удалил всех подозрительных пользователей с правами администратора.
3. Закрытие уязвимостей и усиление защиты: Удалил тот самый уязвимый плагин, так как обновлений для него уже не было, и заменил его на современный аналог. Обновил ядро WordPress и все остальные плагины до актуальных версий. Сменил все пароли (к хостингу, FTP, админке, базе данных) на сложные. Настроил права доступа к файлам (644) и папкам (755).
4. Работа с поисковыми системами: Сайт уже был помечен в Google Safe Browsing как опасный. Подал заявку на пересмотр через Google Search Console, приложив отчёт о проделанной работе. В Яндекс.Вебмастере проверил статус, подал заявку на снятие санкций.
5. Профилактика: Настроил ежедневное резервное копирование на внешний диск и подключил плагин безопасности с файрволом и мониторингом целостности файлов.
6. Результат: Сайт восстановлен и работает через 6 часов. Через 3 дня санкции с поисковиков сняты, трафик вернулся. Клиент получил полностью защищённый сайт и детальный план действий на будущее.