Представьте: вы открываете сайт утром и он вроде бы жив. Главная грузится, меню кликается, формы отправляются, но что-то не так. На мобильном вдруг появляется редирект на "партнёрскую" страницу (и внезапно ваш партнер - это казино). В поиске Google всплывают странные заголовки про казино, которых вы не писали. Хостинг присылает письмо - подозрение на ботнет/майнинг, аккаунт будет заблокирован. Клиенты жалуются, что при оплате карта "вдруг" уходит в ошибку, а в админке - новый пользователь с правами администратора, которого никто не создавал.
Так выглядит современный захват веб-ресурса: не драматичный дефейс и надпись "Hacked by…", а тихая эксплуатация. Сайт превращается в инфраструктурный актив для спама, дорвеев, фишинга, скимминга, ботнета, майнинга и атак на третьих лиц. Владелец часто узнаёт о компрометации последним: когда уже падает трафик, платежи, доверие или приходит блокировка.
Как остановить заражение, зафиксировать доказательства, вернуть контроль, убрать точку входа и снизить вероятность повторного взлома? Расскажем - без героизма, без магии и с фокусом на то, что реально работает на WordPress/Drupal/Joomla/Bitrix и обычных VPS/хостингах.
1) Как выглядит захваченный сайт в 2025–2026 и что делать в первые минуты
Сейчас компрометация редко выглядит однозначно. Злоумышленники не хотят ломать витрину - они хотят незаметно монетизировать ресурс. Поэтому главный навык владельца и администратора - распознавать симптомы и быстро переходить к изоляции и фиксации.
Ниже таблица по самому важному аспекту - симптомы компрометации и первичные действия. Это то, что чаще всего даёт “быстрый диагноз”, пока вы ещё не начали удалять файлы и уничтожать следы.
Первые 15 минут: минимальный протокол (STOP THE BLEEDING)
(Это первая из максимум четырёх bullet-секций.)
- Переведите сайт в режим обслуживания на уровне веб-сервера, а не “плашкой”. Идеально: whitelist IP (ваш офис/VPN) и закрыть остальным.
- Смените все доступы: панель хостинга, SSH, FTP/SFTP, база данных, админки CMS, ключи API, токены, секреты в .env. Считайте, что старые уже утекли.
- Отключите внешние интеграции, где возможно: платежные вебхуки, внешние API-ключи, фоновые cron-задачи отправки писем, если есть признаки утечек/скимминга.
- Зафиксируйте факт инцидента: время обнаружения, симптомы, что изменилось. Это важно для поддержки хостинга, платежек и поисковиков — и просто для вашей же головы.
Ключевой принцип: сначала остановить кровотечение, потом лечить. Если начать “чистить” на живом бою, злоумышленник может наблюдать и перестраиваться, а вы — потеряете следы входа.
2) Почему ломают именно вас: механика массовых атак без романтики
Самая вредная мысль, которую держит малый и средний бизнес: «мы слишком маленькие». В большинстве случаев вас действительно “не выбирали”. Вас нашли так же, как находят всех: сканером.
Массовая атака в 2025–2026 — это pipeline:
- сканирование интернета (CMS fingerprints, плагины, версии, открытые панели, слабые конфиги);
- сопоставление с известными уязвимостями (CVE и “one-day” эксплойты);
- автоматическое внедрение webshell/пользователя/cron/редирект-правил;
- монетизация (дорвеи, ботнет, майнинг, скимминг, фишинг);
- удержание доступа (persistence через плагины, конфиги, БД, задачи планировщика).
Почему CMS - магнит для хакеров
Не потому что CMS плохие, а потому что:
- у них огромная площадь атаки (ядро + плагины + темы + интеграции);
- у них массовость (одна уязвимость - тысячи/миллионы потенциальных целей);
- их часто обновляют нерегулярно;
- администраторы и подрядчики часто оставляют лишние права на запись, тестовые панели, забытые бэкапы.
WordPress остаётся абсолютным лидером по массовым инцидентам из-за экосистемы плагинов и тем: даже если ядро обновлено, один “забытый” плагин может открыть RCE/SQLi/SSRF.
Drupal/Joomla часто страдают от “забытых” обновлений ядра и модулей в корпоративной среде.
Bitrix нередко ломают через модули интеграции, слабую модель прав, неочевидные настройки и устаревшие компоненты.
Почему дефейс стал редкостью
Дефейс - шум. Он ускоряет реакцию владельца и провайдера. Современные атаки предпочитают незаметность:
- SEO-спам бьёт по вашему трафику и репутации, а не по внешнему виду.
- Фишинг на вашем домене использует “белую репутацию”.
- Майнинг и ботнет выжимают ресурсы, пока вы молчите.
- Скиммер на оплате — максимально прибыльный и максимально токсичный для вас.
Отсюда вытекает главный вывод: инцидент-готовность нужна всем, не только крупняку.
3) Протокол восстановления: изоляция → форензика → очистка → устранение входа → возврат в прод
Если упрощать, лечение сайта — это управляемая операция с двумя целями:
- восстановить работоспособность и доверие (пользователи/поисковики/платежи);
- не допустить повторного взлома тем же способом.
Самая частая ошибка — лечить симптом: удалили пару файлов, вроде заработало. Через день всё повторяется, потому что точка входа не закрыта, а persistence остался.
Фаза 1. Изоляция: ограничить доступ и стабилизировать среду
Изоляция - это не только выключить сайт. Это ещё и:
- уменьшить поверхность атаки (закрыть админки по IP, выключить лишние порты, ограничить внешние запросы);
- прекратить утечку данных (если есть подозрение на скимминг/фишинг);
- остановить исполняемый вредонос (майнеры, боты), чтобы не сжечь сервер и не получить бан у провайдера.
Важно: если сайт - e-commerce и есть признаки скимминга, действуйте как при утечке: быстрое отключение оплаты, фиксация, уведомления по требованиям вашего региона/контрактов. Это уже не “техническая проблема”.
Фаза 2. Снапшот и форензика: сначала доказательства, потом удаление
Звучит скучно, но это спасает от повторного взлома.
Сделайте:
- полный архив файлов сайта (включая скрытые), конфиги веб-сервера, .env, .htaccess;
- дамп базы данных;
- копию логов за релевантный период (минимум 7–14 дней, лучше больше): access/error, auth.log, panel logs, FTP logs если есть.
Дальше вы ищете ответ на вопрос: как вошли. Обычно это один из четырёх сценариев:
- уязвимый плагин/модуль/тема (RCE/SQLi/SSRF);
- компрометированный пароль/панель/админка (bruteforce/credential stuffing);
- file upload (webshell в uploads);
- “нуллёные” компоненты/бекдор в шаблоне.
Что смотреть в логах (коротко, по делу)
В access-логах вас интересуют:
- POST к странным путям (особенно в /wp-admin/admin-ajax.php, /xmlrpc.php, кастомные endpoints);
- необычные User-Agent’ы и всплески 404/500;
- запросы к файлам, которых “не должно существовать”;
- цепочки запросов перед изменением файлов (сопоставляйте с timestamps).
В системных логах:
- новые пользователи,
- изменения crontab/systemd timers,
- запуск неизвестных бинарников,
- outbound-коннекты на странные хосты.
Фаза 3. Очистка: не лечить заражённые файлы, а заменять
Самый надёжный подход — чистая замена ядра и кода, точечная миграция контента и медиа.
Почему “лечить файлы” плохо:
- вредонос часто обфусцирован и размазан по десяткам мест;
- вы удалите видимую часть, но оставите persistence;
- через неделю прилетит reinfection тем же ботом.
Практика:
- CMS-ядро и стандартные папки — удалить и заменить чистыми версиями.
- Плагины/модули — переустановить из официальных источников.
- Темы — заменить, либо сделать строгий аудит и дифф.
Самый проблемный участок почти всегда uploads / media. Там нельзя просто “всё снести”, потому что это контент. Но там же часто лежит webshell.
Чек-лист очистки (вторая bullet-секция)
- Найдите и удалите исполняемые файлы в медиа-директориях (.php, .phtml, .pl, .py, .sh, .cgi). В uploads “скриптов быть не должно”.
- Проверьте .htaccess, nginx.conf, include-файлы на условия по User-Agent/Referer, редиректы, скрытые прокси.
- В базе данных:
проверьте таблицы пользователей на “тихих” админов;
просканируйте контент на <script src=…>, base64_decode, подозрительные iframes, inline-JS в постах. - Проверьте планировщик задач: cron/systemd/панельные “Scheduled tasks”.
- Убедитесь, что нет “запасных входов”: лишних админ-аккаунтов, API-ключей, SSH-ключей в authorized_keys.
Фаза 4. Устранение точки входа
Это важнее, чем сама очистка. Если вход не закрыт — всё повторится.
Классические меры:
- обновить/удалить уязвимый плагин или модуль;
- убрать неиспользуемые компоненты;
- закрыть админ-панели по IP/VPN;
- пересмотреть права на запись (частая причина reinfection — writable core);
- запретить исполнение скриптов в uploads (на уровне веб-сервера);
- включить rate-limits на авторизацию, отключить лишние endpoints (например, XML-RPC, если не нужен).
Фаза 5. Возврат в прод: аккуратное включение и мониторинг
Возвращать сайт надо как систему после аварии:
- сначала staging/тест;
- потом ограниченный вывод в прод;
- потом наблюдение.
Если это SEO-спам: готовьтесь, что поисковики не “простят” мгновенно. Нужно:
- убрать дорвеи/инъекции,
- пересобрать sitemap,
- запросить переобход,
- проверить ручные санкции/предупреждения.
Если был скимминг: кроме техники, есть юридический и репутационный контур. Не прячьте голову — лучше управлять последствиями, чем потом догонять.
4) Hardening после лечения: как не попасть в цикл “взлом → чистка → взлом”
После восстановления многие делают типичную ошибку: “сайт работает — всё”. Но атакующий бот вернётся туда же, потому что он сканирует по шаблону. Значит, вам нужно сделать так, чтобы повторная попытка стала:
- либо невозможной,
- либо заметной на ранней стадии,
- либо слишком дорогой по времени.
Контрмеры, которые реально дают эффект
WAF/CDN
Cloudflare или аналог — не панацея, но резко снижает шум ботов и массовых атак. Особенно полезно для:
- фильтрации простых exploit-попыток;
- rate-limits на логин;
- защиты от базового DDoS;
- быстрой блокировки стран по необходимости.
File Integrity Monitoring (FIM)
Любое изменение core-файлов ночью — повод для тревоги. FIM можно реализовать:
- специализированными агентами,
- проверками хешей,
- CI-подобными “diff against baseline” на деплое.
Минимизация привилегий
Критично: приложение не должно иметь права переписывать собственный код.
На практике:
- read-only для core/тем/плагинов;
- write только для uploads/cache там, где нужно;
- отдельный пользователь под процесс веб-сервера;
- запрет исполнения из uploads.
2FA и управление доступами
Админки без 2FA в 2026 — это как офис без замков.
Плюс: отдельные учётки, запрет общих логинов, удаление аккаунтов подрядчиков после работ.
Бэкапы вне сервера (off-site)
Бэкап на том же VPS — не бэкап. При компрометации злоумышленник часто:
- шифрует и данные, и бэкапы;
- удаляет снапшоты;
- оставляет “подарок” на будущее.
Хорошая схема: S3-хранилище с правами “только запись” (append-only), версионирование, отдельные ключи, ротация.
Минимальный “пакет зрелости” (третья bullet-секция)
- WAF/CDN включен, базовые правила и rate-limits настроены.
- Admin-панели ограничены по IP/VPN, 2FA включена для всех.
- Core и код — read-only, uploads — без исполнения.
- Бэкапы off-site + проверка восстановления (не только “делаем”, но и “можем восстановить”).
- Мониторинг изменений файлов + алерты на аномалии (CPU, исходящие соединения, ошибки 5xx, всплески POST).
Взломать можно любой сайт
Вопрос в том, что произойдёт после. Современная компрометация редко кричит о себе. Она тихо живёт рядом с вами: в редиректах “только для мобил”, в дорвеях “только для роботов”, в webshell в uploads, в фильтрах почты, в ночных cron-задачах. Поэтому ключевые навыки владельца — не “найти волшебный плагин”, а действовать по протоколу: изоляция → фиксация → чистая замена → устранение входа → hardening и мониторинг.
И ещё один вывод, без морали: инцидент-план нужен до инцидента. Компании и команды, которые заранее знают, где у них бэкапы, кто имеет доступ, как ограничить сайт и как собрать логи, поднимаются быстро и управляемо. Те, кто надеется “авось”, чаще платят дважды — временем и репутацией.