Как выявить и разобрать компрометацию интернет-магазина

Иногда взлом интернет-магазина не выглядит как классическая поломка сайта. Магазин может открываться, каталог может работать, часть заказов может оформляться, а настоящая проблема проявляется только в одном месте — например, в корзине, на этапе оплаты или в расхождении между фактом платежа и историей заказов.

Именно такой сценарий особенно опасен. Он не всегда сразу даёт понять, что речь идёт не о баге модуля и не о случайной ошибке интеграции, а о последовательной компрометации с несколькими этапами: проникновение, закрепление, скрытая подмена платёжного потока и попытка монетизации.

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

Как развивался инцидент

По внутренней хронологии изменений стало ясно, что атака развивалась поэтапно, а не одномоментно.

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

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

Примерно спустя два месяца произошёл первый очевидный бизнес-инцидент: была скомпрометирована страница one-page checkout. В корзине появилась ссылка на сторонний процессор оплаты картой. Эта ссылка не имела отношения к штатной платёжной схеме магазина и уводила пользователя на чужой маршрут оплаты. На этом этапе подмена была обнаружена и удалена, что позволило временно остановить первый вид мошеннического сценария.

Однако расследование показало, что это был не финал, а лишь один из эпизодов. Примерно через три недели после удаления посторонней ссылки произошёл следующий этап атаки — уже на уровне платёжного модуля. В результате платежи через Google Pay и Apple Pay начали уходить не по штатной схеме, а в сторону злоумышленников. При этом покупки не фиксировались в истории магазина: в системе не появлялись нормальные заказы, не формировалась ожидаемая запись об оплате, и для администратора это могло выглядеть как загадочное исчезновение заказов.

Какие признаки выдали проблему

В подобных инцидентах редко бывает один идеальный индикатор. Обычно картина складывается из нескольких тревожных сигналов:

• на checkout-странице появляется лишняя ссылка или неожиданный маршрут оплаты;
• клиент завершает оплату, но заказ не появляется в истории магазина;
• меняются файлы, которые никто из администраторов не редактировал;
• в системе остаются служебные точки входа, пригодные для повторного доступа;
• временные интервалы изменений растянуты на недели, что говорит о повторных возвратах злоумышленника;
• часть изменённых файлов выглядит почти штатно, но изменена в подозрительное время;
• есть разрыв между логикой оплаты на фронтенде и тем, что реально фиксируется в системе заказов.

Какие файлы оказались затронуты или потребовали отдельной проверки

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

1. Подозрительно изменённые или затронутые файлы

В рамках инцидента внимание привлекли следующие типы файлов:

• конфигурационный файл приложения с параметрами подключения и ключами;
• контроллер платёжного модуля;
• AJAX-контроллер корзины;
• контроллеры модулей отзывов, подписки и wish-list;
• отдельные файлы в корне сайта;
• служебные PHP-файлы, появившиеся или изменённые в нетипичное время.

Типовой перечень того, что обычно попадает в такую выборку:

• app/config/parameters.php
• modules/.../controllers/front/payment.php
• modules/.../controllers/front/ajax.php
• modules/.../controllers/front/verification.php
• modules/.../controllers/front/lists.php
• modules/.../controllers/front/PostComment.php
• файлы в корне сайта вроде phpinfo.php.

2. Потенциально опасные штатные точки входа, которые обязательно проверялись

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

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

В типовом случае это выглядит так:

• admin.../filemanager/upload.php
• admin.../backup.php
• различные старые ajax.php, drawer.php, get-file-admin.php;
• служебные upload/download-обработчики;
• корневой phpinfo.php.

3. Каталоги, где искали следы закрепления

Отдельно проверялись:

• config/
• controllers/
• override/
• classes/
• modules/
• административный каталог;
• корень сайта;
• каталоги изображений на наличие нестандартных index.php;
• места, где могли появиться скрытые загрузчики или мини-бэкдоры.

Почему нельзя считать подозрительным любой найденный eval, base64_decode или move_uploaded_file

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

Во многих CMS и модулях легитимно встречаются:

• move_uploaded_file() — в формах загрузки изображений и файлов;
• base64_decode() — в API, PDF-библиотеках, криптографии, логотипах, вебхуках;
• php://input — в обработчиках API, webhook и AJAX;
• gzuncompress() — в PDF и графических библиотеках;
• eval() — в старом ядре CMS, автозагрузке и модульной логике.

Поэтому опасна не сама функция, а её контекст:

• файл изменён недавно без понятной причины;
• находится в нетипичном месте;
• не соответствует официальной версии;
• добавляет внешний URL;
• подменяет payment flow;
• создаёт скрытый канал доступа;
• не связан с бизнес-логикой сайта.

Набор тестов, который помогает выявить инфекцию

Ниже — практический список проверок, который полезно выполнять при подозрении на компрометацию интернет-магазина.

1. Поиск недавно изменённых PHP-файлов

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

Что смотреть:

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

2. Проверка синтаксиса изменённых файлов

Каждый подозрительный PHP-файл стоит прогнать через php -l.

Это не выявляет взлом напрямую, но даёт важную информацию:

• файл рабочий или битый;
• это случайная порча или аккуратно внедрённый код;
• пытался ли злоумышленник оставить исполнимый файл.

3. Поиск опасных функций по исходникам

Следующий тест — поиск по таким шаблонам:

• eval(
• assert(
• base64_decode(
• gzinflate(
• gzuncompress(
• str_rot13
• shell_exec
• system(
• passthru
• proc_open
• popen
• php://input
• file_put_contents
• move_uploaded_file
• подозрительные include и require.

Это не финальный приговор, а фильтр для ручного анализа.

4. Проверка файлов в корне сайта

Любые PHP-файлы в корне сайта заслуживают отдельного внимания, особенно если это:

• phpinfo.php;
• тестовые загрузчики;
• старые отладочные скрипты;
• временные миграционные файлы;
• одноразовые служебные страницы.

Даже если такой файл безобиден, он расширяет поверхность атаки.

5. Проверка административных файловых менеджеров и backup-скриптов

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

6. Поиск PHP-кода в непрофильных файлах

Нужно отдельно искать не только .php, но и любые файлы, содержащие <?php:

• .txt
• .ico
• .jpg
• .phtml
• .phar
• временные файлы;
• файлы без расширения.

Этот тест помогает находить маскировку.

7. Проверка каталогов изображений и вложенных index.php

Наличие большого количества index.php в каталогах изображений само по себе может быть нормой, но важно проверять:

• совпадают ли они с типовым содержимым;
• не отличаются ли по размеру;
• не содержат ли лишний код;
• не появились ли они волнами в подозрительные даты.

8. Сравнение с чистой версией CMS и модулей

Очень важный тест — сравнить изменённые файлы с официальными оригиналами:

• ядра CMS;
• платёжного модуля;
• корзины;
• checkout-модуля;
• сторонних интеграций.

Именно так чаще всего выявляется скрытая вставка ссылки, подмена redirect, замена webhook-логики или внедрение постороннего URL.

9. Ручная проверка платёжного потока

Нужно не только читать код, но и тестировать бизнес-логику:

• что происходит после нажатия кнопки оплаты;
• куда ведёт ссылка;
• какие URL вызываются;
• появляется ли заказ в системе;
• меняется ли статус корзины;
• создаётся ли запись об оплате;
• что происходит при Google Pay, Apple Pay и card payment.

Если деньги уходят, а заказ не появляется — это один из самых сильных индикаторов компрометации.

10. Проверка логов веб-сервера и PHP

Смотреть нужно:

• access.log
• error.log
• php-fpm logs
• логи платёжных модулей;
• логи webhook.

Искать стоит:

• неожиданные POST-запросы;
• обращения к нестандартным контроллерам;
• вызовы upload- и ajax-обработчиков;
• аномальные переходы на внешние URL;
• запросы к скрытым служебным маршрутам.

11. Проверка прав и владельцев файлов

Важно убедиться, что:

• файлы принадлежат ожидаемому пользователю;
• нет внезапных root-owned файлов в web-каталогах;
• права не слишком широкие;
• upload-каталоги не исполняемые без необходимости.

12. Проверка повторного появления изменений

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

Что особенно важно в подобных расследованиях

Главная ошибка — остановиться на первом найденном симптоме.

Если вы нашли и удалили вредоносную ссылку в корзине, это ещё не означает, что проблема решена. В описанном случае именно так и произошло: сначала была обнаружена и удалена ссылка на сторонний процессор оплаты картой, но спустя три недели выяснилось, что злоумышленник сохранил доступ и уже вмешался в платёжный модуль глубже. В итоге Google Pay и Apple Pay начали работать в интересах атакующего, а покупки не фиксировались в истории магазина.

Практические выводы

По итогам расследования можно сделать несколько важных выводов.

1. Взлом интернет-магазина часто развивается волнами. Сначала идёт подготовка и закрепление, затем пауза, потом бизнес-атака на оплату.
2. Если страдает checkout, проверять нужно не только шаблоны корзины. Обязательно анализируются платёжные контроллеры, redirect-логика, webhook и история заказов.
3. Нельзя ограничиваться поиском одного вредоносного файла. Нужно смотреть на всю цепочку событий, интервалы изменений и повторяемость аномалий.
4. Служебные файлы вроде phpinfo.php, filemanager, backup-скриптов и upload-обработчиков резко повышают риск. Их лучше удалить или жёстко ограничить.
5. Лучший способ убедиться, что активная фаза атаки остановлена, — пройти полный цикл проверок. Файлы, логи, права, платёжный поток, сравнение с оригиналами и наблюдение после очистки должны рассматриваться как единый процесс.

Заключение

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

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

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

🛡️ Нужна проверка магазина после взлома?

SOLLER.LV поможет провести технический аудит, проверить checkout и платёжные модули, найти следы закрепления, сравнить файлы с оригиналами и оценить, остановлена ли активная фаза компрометации.