Подрядчик ушёл, а заявки не приходят. Что мы нашли за 14 часов

Контекст

Поручение на аудит поступило в день, когда заказчик инициировал расторжение договора с прежним SEO-подрядчиком.

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

Внешние ограничения определили темп:

• работы выполнялись параллельно с процедурой расторжения договора;
• часть доступов могла быть аннулирована в любой момент;
• любая обнаруженная инфраструктурная проблема требовала быстрого решения по принципу «зафиксировать и защитить».

Поэтому методика строилась с приоритетом на сохранение доказательств и минимизацию необратимых действий.

Хронология

• 22 апреля — первый контакт
  Заказчик выходит на исполнителя по рекомендации. Сформулирован общий запрос: оценить состояние сайта, дать заключение.
• 27 апреля, 19:34 МСК — передача доступов
  Заказчик передаёт административные доступы единым документом. Между первым контактом и передачей доступов — пять дней внутренних согласований.
• 29 апреля, 13:00 МСК — триггер срочности
  Заказчик сообщает: процедура расторжения договора с прежним подрядчиком инициирована в этот же день. Подрядчик одновременно уточняет дальнейшие действия по поддерживаемой инфраструктуре. Аудит переходит в срочный режим.
• 29 апреля, 14:42 МСК — первая критическая находка
  Через API Яндекс.Метрики установлено: на сайте подключён счётчик с чужим идентификатором, родной счётчик не получает данных с 27 марта 2024 года. Подмена в HTML-коде сайта подтверждена.
• 29 апреля, 15:12–16:36 МСК — зачистка доступов
  Сменены пароли всех ключевых учётных записей, удалены четыре «лишних» административных аккаунта. Полный пакет обновлённых учётных данных передан заказчику документом.
• 29 апреля, ~22:00 МСК — вторая критическая находка
  В корне сайта обнаружен PHP-скрипт без авторизации: при каждом обращении к нему пароль главного администратора сбрасывается на пароль, прописанный прямо в коде закладки. Имя файла маскирует его под стандартную обёртку CMS.
• 29 апреля, 22:30 МСК — нейтрализация
  Скрытый канал доступа заменён на ловушку того же имени: запросы журналируются с IP, User-Agent и заголовками, заказчик уведомляется почтой. Период наблюдения — 14 дней.
• 29–30 апреля, 22:50–03:30 МСК — ночной разбор материалов
  Скачаны и зафиксированы хешами 11 архивов из служебной директории CMS (19 ГБ). Извлечены и сравнены SQL-дампы базы данных за разные периоды. Восстановлен исходный robots.txt.
• 30 апреля, утро — финальный пакет
  Отчёт 14 разделов, 100 страниц. Отдельно подготовлены проекты регуляторных документов: первичное уведомление (24 часа) и отчёт о расследовании (72 часа). Решение об отправке оставлено за заказчиком.

Критическая фаза от триггерного сообщения до проверки ловушки — 9 часов 31 минута. Среднее время отклика заказчика на запросы исполнителя в активной фазе — около двух минут. Без такого темпа бизнес-согласований компрессия аудита в одни сутки была бы невозможна.

Что нашли

Перед детальным разбором — хронология значимых событий в инфраструктуре сайта, восстановленная по HTTP-заголовкам, API Яндекса и временным меткам в базе данных.

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

1. Полная копия сайта 12 ГБ — открыта для скачивания

Главная находка обнаружена в первые минуты сканирования: архив /public_html.zip объёмом 12 ГБ был доступен по прямому адресу без авторизации.

Внутри — полная файловая структура сайта: исходный код, CMS-модули, конфиги, база данных, выгрузки заявок, фотоархив. Срок действия в HTTP-заголовках был выставлен до 29 апреля 2027 года — то есть архив должен был оставаться доступным ещё год.

При построчном анализе SQL-дампа из утёкшего архива установлено: реальных субъектов персональных данных в утечке — 26 уникальных лиц. С поправкой на ботовые записи, тестовые заявки самого подрядчика и групповые дубли. Это и есть юридически значимый объём — категория «Б» по ПП №1286, упрощённая процедура уведомления (менее 100 субъектов).

2. Десять архивов с резервными копиями и три служебных скрипта в корне

Помимо главного архива в корне сайта обнаружены ещё десять малых архивов с резервными копиями и три PHP-скрипта без авторизации.

Архивы (auth.zip, cabinet.zip, cart.zip, gallery.zip, info.zip, news.zip, product.zip, projects.zip, sales.zip, tariffs.zip) — фрагменты разделов сайта на разных датах: от ноября 2022 до февраля 2023. Скрипты — fixit.php, spread.php, readme.php — не относятся к стандартной поставке CMS и не имеют контроля доступа.

3. spread.php — скрытый канал доступа (бэкдор / чёрный ход)

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

В стандартной поставке Bitrix есть легитимный файл bitrix/spread.php — однострочная обёртка для модуля массовых рассылок:

Этот файл существует в любой инсталляции Bitrix с начала 2010-х. Любой разработчик с опытом видел его сотни раз и не относится к нему с подозрением.

Атакующий использовал то же самое имя — spread.php, — но положил свой PHP в корень сайта, где штатного файла с таким именем быть не должно. При беглом просмотре корневого перечня файл выглядит как ожидаемый системный — это эксплуатация привычки восприятия Bitrix-разработчика.

В резервной копии сайта от 20 марта 2024 года в корне такого файла нет — значит, добавлен позднее этой даты. Размер файла — 276 863 байта, в основной части — копия исходного HTML главной страницы для маскировки ответа; меньшая часть кода выполняла подмену пароля.

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

• каждый входящий запрос журналируется с IP, User-Agent, полным набором заголовков;
• журнал пишется в файл выше корня сайта (недоступен из веба);
• при поступлении запроса заказчику уходит уведомление почтой;
• в ответ отдаётся копия исходного HTML — внешне поведение не отличается от прежнего.

4. Подмена счётчика Метрики и накрутка ботами

27 марта 2024 года счётчик Метрики на сайте был заменён на идентификатор, не принадлежащий заказчику. С этой же даты в БД сайта начали поступать заявки с признаками автоматизированного поведения.

Из 386 заявок, накопленных в базе за период, 87 пришлись на апрель 2024 года и имели типичные маркеры накрутки: одинаковые временные интервалы, шаблонные имена, отсутствие источника перехода. Реальный поток заявок до подмены счётчика — 2-13 в месяц.

Сама по себе подмена счётчика делает аналитику в Метрике непригодной для принятия решений: владелец сайта видит чужую картину трафика, а накрутка ботов — встроена в контур чужого аккаунта.

5. Модуль webprostor.smtp — почему «за 4 месяца — два клиента»

17 сентября 2025 года в 17:18 МСК на сайт установлен сторонний модуль, перехватывающий уведомления о заявках. Технически он подменял механизм отправки исходящей почты: письма уходили через сторонний почтовый сервер с переписанным полем «От» и без сохранения журнала отправок. Для владельца это означает простую вещь — заявка на сайте оставлена, но уведомление о ней до него не доходит.

Заказчик передал служебный лог самого модуля (webprostor.smtp_logs.xls) за период с 17 сентября 2025 года по 12 марта 2026 года. По этому логу — 20 попыток отправки уведомлений о заявках; в каждой из 20 строк поле «Отправлено» пустое, что соответствует ошибке доставки. То есть за полгода 20 потенциальных клиентов оставили заявки на сайте, и ни один ответ от компании до них не дошёл.

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

Динамика реальных заявок до и после установки модуля — по записям в базе данных сайта:

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

6. Как подрядчик подстраивается под изменения 152-ФЗ — за ваш счёт

Пять технических правок инфраструктуры сайта в 2024-2025 годах пришлись строго на окна между принятием поправок к 152-ФЗ и их вступлением в силу.

Что вступало в силу:

• 420-ФЗ — в силу с 30 мая 2024 года. Кратно увеличил штрафы за утечки персональных данных, ввёл оборотные штрафы для повторных инцидентов, ужесточил требования к согласиям и журналированию.
• 134-ФЗ — в силу с 30 ноября 2025 года. Расширил состав охраняемых ПД, ввёл уголовную ответственность за неправомерную передачу/использование ПД (ст. 272.1 УК РФ).

Что объединяет эти правки. Каждая отдельная — обычная задача подрядчика: «настроить капчу», «обновить счётчик», «добавить SMTP-модуль». Их совокупность во времени — нет.

Каждая правка делает сайт менее эффективным как бизнес-канал: формы упрощаются, заявки не доходят, аналитика уходит чужому. И одновременно — снижает фактический объём реальных персональных данных, попадающих в БД сайта: меньше полей в формах, ботовый поток разбавляет реальные заявки фейковыми именами и телефонами, перехваченные уведомления отрезают канал реального общения с клиентом.

Юридическую ответственность по новым, более строгим нормам несёт оператор сайта — то есть заказчик. Чем меньше у него в БД реальных ПД, чем менее очевиден поток заявок — тем ниже его потенциальные обязательства и риски при проверке. На бумаге это выглядит как «подрядчик помог снизить риски». На практике — это снижение работает за счёт бизнес-функции сайта: меньше реальных заявок, меньше реальных клиентов, меньше выручки.

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

Как работали

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

Доказательства прежде всего

Каждая находка зафиксирована тремя способами: прямой HTTP-снимок ответа сервера, снимок Wayback Machine для исторической верификации, SHA-256 на скачанные артефакты. Итоговый архив доказательств — 33 ГБ, 16 разделов, хеш на каждый файл; ссылки и фрагменты включены в отчёт со ссылками на индекс архива.

Нейтрализация вместо удаления

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

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

В CMS были обнаружены четыре «лишних» административные учётные записи. Поскольку процедура расторжения договора с прежним подрядчиком ещё не была завершена, эти записи удалены превентивно — до завершения процедуры, чтобы исключить возможность последующего входа. Пароль базы данных сменён синхронно, резервная копия сайта (12 ГБ) и четыре tar-архива из служебной директории CMS сохранены локально.

Что закрыто

Что из этого следует