«Сайт украли, а мы не заметили»: история одного взлома и восстановления

Звонок раздался в пятницу вечером. На экране — номер владельца ювелирного интернет-магазина. «Сергей, у нас проблема. Менеджеры говорят, что заказов почти нет. А в прошлом месяце было 50–60 в день. Трафик упал. Google нас убил?»

Я открыл статистику. Данные Яндекс.Метрики выглядели зловеще — красная линия трафика из Google устремилась вниз, как нож гильотины . За две недели мы потеряли 85% посетителей. Но главный ужас был в другом: мы даже не заметили, что сайт умирает. Владелец спокойно пил кофе, маркетолог отчитывался о росте трафика из Яндекса, а сайт… сайт уже три недели работал на хакеров.

Это история о том, как мы почти потеряли бизнес из-за скрытого взлома, и как я его возвращал. Спойлер: happy end есть, но осадок остался навсегда.

День первый: «Google нас убил» — с чего всё началось

В марте 2025 года мы получили срочный вызов от владельца ювелирного интернет-магазина с многолетней историей .

Симптомы:

• Заказы упали с 50–60 в день до 5–10
• Менеджеры жаловались, что «звонков почти нет»
• Трафик из Google по данным Метрики рухнул на 85%
• При этом трафик из Яндекса оставался стабильным

Владелец был в панике: «Мы не меняли рекламу, сайт работал, что случилось?»

Первая гипотеза — очередное обновление алгоритмов Google. Такое бывает: вылетели из топа по ключевым запросам, надо разбираться. Но когда мы зашли в Google Search Console, нас ждал сюрприз пострашнее.

Шок-диагностика: сайт вроде работает, но Google его не видит

Открываю Google Search Console. Выбираю главную страницу. Нажимаю «Проверить URL». И вижу :

Странно. Сайт открывается. Я вижу каталог, корзину, всё работает. Почему Google-бот не может его прочитать?

Дальше — больше. В разделе «Безопасность и ручные действия» висит красное уведомление :

Ручные санкции Google — это приговор. Это не алгоритм, который можно перехитрить. Это живые люди в Google, которые посмотрели на сайт и сказали: «Вы нарушаете правила, мы убираем вас из выдачи». Такое происходит редко, но когда случается — последствия катастрофические .

Вопрос: за что? Клиент клялся, что ничего не нарушал. Никаких накруток, никакого спама. Я верил. Но Google так просто не ошибается.

Охота на призрака: почему мы не видели взлом

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

И тут — озарение. На одном из форумов я наткнулся на обсуждение похожей проблемы . Человек писал: «Угнали домен, а я не заметил». Домен — это адрес сайта в интернете. Если украли домен, сайт перестаёт быть вашим. Но наш домен был на месте. Whois показывал владельца — клиента. В чём подвох?

Я решил провести простой тест. Открыл VPN с американским IP (чтобы Google-бот думал, что я из США) и зашёл на сайт. И обомлел.

Вместо ювелирного магазина я увидел страницу с заголовком «kpkototo» — типичный лендинг онлайн-казино с азартными играми . Для российских пользователей сайт выглядел нормально. Для иностранных — подменялся на спам-контент.

Это называется «клоакинг» (cloaking) — техника, при которой поисковому роботу показывают один контент, а обычному пользователю — другой . Google запрещает это категорически. И когда его боты увидели, что сайт вместо ювелирных украшений отдаёт казино, они наложили ручные санкции.

Как хакеры это сделали?

Они взломали сайт (скорее всего, через уязвимый плагин или старую версию CMS), внедрили скрипт, который анализировал IP-адрес посетителя .

• Если IP российский — показываем нормальный магазин, чтобы владелец ничего не заподозрил
• Если IP иностранный (а у Google-ботов часто зарубежные адреса) — показываем страницу казино

Хакеры зарабатывали на спам-трафике: их страницы казино содержали ссылки и редиректы, за которые им платили . А наш клиент получал бан от Google и терял продажи. И самое страшное — он ничего не замечал, потому что из России сайт выглядел нормально.

Расследование: как хакеры проникли и сколько сидели внутри

Найдя «скелет в шкафу», мы начали криминалистический анализ .

Шаг 1. Логи доступа

Мы подняли все логи веб-сервера за последние 6 месяцев. И нашли странные POST-запросы к папке /bitrix/ в ноябре прошлого года — за 4 месяца до обнаружения взлома .

Шаг 2. Поиск «закладок» (веб-шеллов)

Хакеры, получив доступ, почти всегда оставляют «чёрный ход» — специальный скрипт (веб-шелл), чтобы вернуться . Мы запустили поиск по всем файлам с подозрительным содержимым: system(), eval(), base64_decode(). Обнаружили два зашифрованных PHP-файла с именами .500.php и system.php в корневой директории. Они были датированы ноябрём .

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

Шаг 3. Точка входа

Как они попали в ноябре? Мы проверили версию CMS. Она была устаревшей. В логах нашли запрос к странице восстановления пароля администратора, который выглядел подозрительно. Оказалось, что модуль восстановления пароля в старой версии CMS имел уязвимость, позволяющую сбросить пароль админа без подтверждения по email .

Хакеры просто зашли в админку под нашим логином, загрузили веб-шелл через форму загрузки файлов — и всё .

План реанимации: как мы возвращали сайт к жизни

Когда мандраж прошёл, мы составили чёткий план. Вот он, пошагово .

Этап 1. Изоляция и резервное копирование

Мы заблокировали доступ к сайту извне через .htaccess, разрешив вход только с IP-адресов нашей команды . Затем сделали полный дамп базы данных и бекап всех файлов — «как есть», со всеми вирусами, для последующего анализа.

Этап 2. Уничтожение малвари

Мы вручную удалили все подозрительные PHP-файлы. Переустановили ядро CMS из официального репозитория, заменив все системные файлы на заведомо чистые .

Нашли в базе данных внедрённый JavaScript-код, который срабатывал при заходе с определённых IP. Очистили таблицы post и options.

Этап 3. Зашивка дыр

Мы обновили CMS до последней версии, удалили все неиспользуемые плагины и темы . Сменили все пароли: от админки, от FTP, от хостинга, от базы данных . Настроили двухфакторную аутентификацию .

Этап 4. Обращение в Google

Когда сайт был чист, мы отправили запрос на пересмотр в Google Search Console . Приложили подробный отчёт: что нашли, как исправили, какие меры приняли, чтобы защититься в будущем.

Через 12 дней пришло уведомление: «Ручные меры сняты» .

Этап 5. Возвращение трафика

Индексация восстанавливалась постепенно. Через месяц трафик из Google вернулся к 70% от прежнего уровня. Ещё через два месяца мы превысили докризисные показатели .

Почему мы «не заметили» взлом: 5 фатальных ошибок

Разбирая этот кейс, я выделил 5 ошибок, которые сделали взлом незаметным . Проверьте себя.

Ошибка 1. Мы не мониторили Google Search Console

Если бы администратор раз в неделю заглядывал в GSC, он бы увидел, что страницы выпадают из индекса за месяц до того, как упали продажи. GSC — это самый важный инструмент для SEO. Игнорировать его нельзя.

Ошибка 2. Мы использовали только один источник проверки

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

Ошибка 3. Автоматические обновления были отключены

CMS и плагины не обновлялись месяцами. Хакеры использовали уязвимость, которая была исправлена за полгода до атаки .

Ошибка 4. Мы не проверяли целостность файлов

Весь вредоносный код был внутри файлов, которые изменили свою контрольную сумму. Никто не следил за изменениями .

Ошибка 5. Самый слабый пароль победил

Пароль администратора CMS был «Admin123». Его могли подобрать даже не хакеры, а школьник-энтузиаст. Система не блокировала подбор паролей .

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

Если вы читаете этот текст и у вас ёкнуло сердце — проверьте себя по этому чек-листу :

1. Откройте Google Search Console → раздел «Безопасность и ручные действия». Если там есть красное уведомление — срочно читайте дальше.
2. Проверьте сайт из-за границы с помощью VPN (США, Германия). Отличается ли содержимое от того, что видите вы?
3. Скачайте лог-файлы сервера и поищите подозрительные POST-запросы к таким файлам, которых у вас быть не должно (cmd.php, shell.php, x.php).
4. Проверьте, когда последний раз менялись системные файлы (index.php, wp-config.php). Если дата не совпадает с вашими действиями — тревога.
5. Создайте срочный бекап. Лучше иметь копию «грязного» сайта, чем не иметь ничего.

Главный вывод для бизнеса: профилактика дешевле лечения

Кейс с ювелирным магазином обошёлся клиенту в сумму, сопоставимую с годовым бюджетом на безопасность. В деньгах это были миллионы потерянной выручки + гонорар нашей команды на восстановление . Если бы он вложил 100–200 тысяч рублей в год в безопасность (обновления, мониторинг, WAF, дорогой хостинг), он бы сэкономил в 10 раз больше.

Что я внедрил у себя после этого случая (и вам советую):

• Еженедельная проверка GSC — по понедельникам, как чистка зубов .
• Автоматическое обновление CMS и плагинов (минорные версии).
• Настройка 2FA для всех пользователей с доступом в админку .
• Система мониторинга целостности файлов — если index.php изменился, мне приходит SMS.
• Регулярные проверки с помощью VPN (под разными IP).

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