Удаление вирусов с сайта

Клиент: Сайт агентства недвижимости на WordPress.
Проблема: Внезапно сайт перестал привлекать посетителей из поиска. В Яндекс.Вебмастере появилось уведомление: «Сайт заражён вредоносным кодом». При переходе с мобильных устройств происходил редирект на фишинговый сайт. Хостинг пригрозил заблокировать аккаунт.
Что сделано:

1. Диагностика и поиск вирусов: Скачал все файлы сайта и базу данных. Прогнал файлы через антивирусные сканеры (AI-BOLIT, Virusdie). Обнаружил десятки заражённых файлов ядра WordPress и плагинов, а также вставки вредоносного кода в базе данных (в таблицах wp_options и wp_posts).
2. Анализ причин заражения: Выяснил, что взлом произошёл через устаревшую версию плагина для галерей, в которой была известная уязвимость. Злоумышленники загрузили через неё бэкдор-скрипт.
3. Очистка и восстановление: Полностью удалил все заражённые файлы и переустановил чистые версии ядра WordPress и всех плагинов с официальных источников. Вручную очистил базу данных от вредоносных вставок (с помощью SQL-запросов). Удалил всех подозрительных пользователей с правами администратора.
4. Защита и профилактика: Обновил всё до актуальных версий. Сменил все пароли (к базе, FTP, админке). Установил и настроил плагин безопасности с функцией файрвола и мониторинга целостности файлов. Настроил права доступа к папкам (755) и файлам (644).
5. Результат: Через неделю после отправки заявки в Яндекс сайт был исключён из списка заражённых. Трафик восстановился. Клиент получил подробный отчёт и рекомендации по безопасности.

Клиент: Интернет-магазин косметики на 1С-Битрикс (Аспро: Максимум).
Проблема: Пользователи жаловались, что при переходе на сайт их иногда перенаправляет на сайты онлайн-казино. Продажи упали, репутация страдала. Встроенный антивирус Битрикс молчал.
Что сделано:

1. Диагностика: Проверил логи сервера и нашёл подозрительные запросы к файлам, которых не должно быть в стандартной поставке. Вручную проверил все недавно изменённые файлы. Обнаружил зашифрованный код в файле index.php в корне и в нескольких файлах ядра.
2. Поиск бэкдоров: Код был зашифрован и вставлен в начало файлов. После расшифровки (с помощью онлайн-дешифраторов) увидел, что это бэкдор, который открывает злоумышленникам доступ к сайту и позволяет менять DNS-записи на лету.
3. Очистка и восстановление: Заменил все заражённые файлы на чистые из бэкапа (благо, клиент делал копии). Проверил базу данных на наличие подозрительных записей — нашёл в таблице b_option вредоносную настройку, которая и вызывала редирект. Удалил бэкдор и все связанные файлы.
4. Закрытие уязвимости: Выяснил, что уязвимость была в старом, уже не используемом компоненте, который забыли удалить. Полностью удалил этот компонент.
5. Результат: Редиректы исчезли. Клиент заказал ежемесячный аудит безопасности, чтобы предотвратить подобное в будущем.

Клиент: Сайт IT-компании на Django (Python).
Проблема: Сайт работал крайне медленно, процессор сервера постоянно был загружен на 100%. Хостинг заподозрил неладное и пригрозил отключением. Никаких внешних признаков взлома (редиректов, спама) не было.
Что сделано:

1. Диагностика нагрузки: Зашёл на сервер по SSH, запустил top и увидел, что процесс python потребляет аномально много ресурсов. Проверил запущенные процессы — обнаружил скрытый процесс с именем, похожим на системный, но в нестандартной папке.
2. Поиск вредоносного кода: Проанализировал все недавно изменённые файлы проекта. В одном из вспомогательных скриптов нашёл зашифрованный код, который при расшифровке оказался библиотекой для скрытого майнинга криптовалют (криптомайнером). Он запускался в фоне и грузил процессор.
3. Очистка: Удалил вредоносный скрипт и все связанные с ним файлы. Завершил подозрительный процесс.
4. Проверка уязвимости: Проанализировал логи доступа и обнаружил, что злоумышленники получили доступ через уязвимость в одной из Python-библиотек, которая использовалась на сайте. Обновил эту библиотеку до защищённой версии.
5. Восстановление и защита: Сменил все пароли (к серверу, к базе). Настроил более строгие правила файрвола.
6. Результат: Нагрузка на сервер упала до нормальной, сайт перестал «тормозить». Клиент избежал блокировки хостинга.