Иногда взлом интернет-магазина не выглядит как классическая поломка сайта. Магазин может открываться, каталог может работать, часть заказов может оформляться, а настоящая проблема проявляется только в одном месте — например, в корзине, на этапе оплаты или в расхождении между фактом платежа и историей заказов.
Именно такой сценарий особенно опасен. Он не всегда сразу даёт понять, что речь идёт не о баге модуля и не о случайной ошибке интеграции, а о последовательной компрометации с несколькими этапами: проникновение, закрепление, скрытая подмена платёжного потока и попытка монетизации.
Ниже — практическая история обнаружения подобного инцидента, перечень затронутых файлов и набор тестов, которые помогают выявить инфекцию и подтвердить, что активная фаза взлома действительно остановлена.
По внутренней хронологии изменений стало ясно, что атака развивалась поэтапно, а не одномоментно.
Сначала был затронут каталог сайта. Это был ранний этап компрометации, когда в файловой структуре появились изменения, не соответствующие обычной работе магазина. Примерно через две недели произошло следующее действие злоумышленников: были созданы или закреплены дополнительные точки доступа — бэкдоры и вспомогательные файлы, которые позволяли возвращаться в систему и продолжать вмешательство даже после частичной очистки.
Затем наступил период относительного затишья. На первый взгляд могло показаться, что всё ограничилось локальными изменениями, но на самом деле это был только подготовительный этап.
Примерно спустя два месяца произошёл первый очевидный бизнес-инцидент: была скомпрометирована страница one-page checkout. В корзине появилась ссылка на сторонний процессор оплаты картой. Эта ссылка не имела отношения к штатной платёжной схеме магазина и уводила пользователя на чужой маршрут оплаты. На этом этапе подмена была обнаружена и удалена, что позволило временно остановить первый вид мошеннического сценария.
Однако расследование показало, что это был не финал, а лишь один из эпизодов. Примерно через три недели после удаления посторонней ссылки произошёл следующий этап атаки — уже на уровне платёжного модуля. В результате платежи через Google Pay и Apple Pay начали уходить не по штатной схеме, а в сторону злоумышленников. При этом покупки не фиксировались в истории магазина: в системе не появлялись нормальные заказы, не формировалась ожидаемая запись об оплате, и для администратора это могло выглядеть как загадочное исчезновение заказов.
В подобных инцидентах редко бывает один идеальный индикатор. Обычно картина складывается из нескольких тревожных сигналов:
При расследовании важно честно разделять две группы: файлы, которые действительно были изменены в подозрительное время и попали в основной круг проверки, и штатные системные файлы, которые сами по себе не означают взлом, но обязательно анализируются как потенциальные точки входа.
В рамках инцидента внимание привлекли следующие типы файлов:
Типовой перечень того, что обычно попадает в такую выборку:
app/config/parameters.phpmodules/.../controllers/front/payment.phpmodules/.../controllers/front/ajax.phpmodules/.../controllers/front/verification.phpmodules/.../controllers/front/lists.phpmodules/.../controllers/front/PostComment.phpphpinfo.php.Дополнительно всегда анализируются файлы, через которые злоумышленник может упростить себе доступ, загрузку или выгрузку данных:
В типовом случае это выглядит так:
admin.../filemanager/upload.phpadmin.../backup.phpajax.php, drawer.php, get-file-admin.php;phpinfo.php.Отдельно проверялись:
config/controllers/override/classes/modules/index.php;Одна из самых частых ошибок при расследовании — объявить вредоносным любой файл, где встречаются «страшные» функции. Это неправильно.
Во многих CMS и модулях легитимно встречаются:
move_uploaded_file() — в формах загрузки изображений и файлов;base64_decode() — в API, PDF-библиотеках, криптографии, логотипах, вебхуках;php://input — в обработчиках API, webhook и AJAX;gzuncompress() — в PDF и графических библиотеках;eval() — в старом ядре CMS, автозагрузке и модульной логике.Поэтому опасна не сама функция, а её контекст:
Ниже — практический список проверок, который полезно выполнять при подозрении на компрометацию интернет-магазина.
Первый тест — найти все PHP-файлы, изменённые в подозрительный период, исключив кэш, vendor, загрузки и медиа. Это позволяет быстро сузить круг проверки до реально затронутых файлов.
Что смотреть:
Каждый подозрительный PHP-файл стоит прогнать через php -l.
Это не выявляет взлом напрямую, но даёт важную информацию:
Следующий тест — поиск по таким шаблонам:
eval(assert(base64_decode(gzinflate(gzuncompress(str_rot13shell_execsystem(passthruproc_openpopenphp://inputfile_put_contentsmove_uploaded_fileinclude и require.Это не финальный приговор, а фильтр для ручного анализа.
Любые PHP-файлы в корне сайта заслуживают отдельного внимания, особенно если это:
phpinfo.php;Даже если такой файл безобиден, он расширяет поверхность атаки.
Если в админке есть файловый менеджер, загрузчик файлов, скачивание резервных копий или устаревшие скрипты обслуживания, их нужно читать отдельно. Именно такие точки часто становятся удобным инструментом как для первичного входа, так и для повторного закрепления.
Нужно отдельно искать не только .php, но и любые файлы, содержащие <?php:
.txt.ico.jpg.phtml.pharЭтот тест помогает находить маскировку.
Наличие большого количества index.php в каталогах изображений само по себе может быть нормой, но важно проверять:
Очень важный тест — сравнить изменённые файлы с официальными оригиналами:
Именно так чаще всего выявляется скрытая вставка ссылки, подмена redirect, замена webhook-логики или внедрение постороннего URL.
Нужно не только читать код, но и тестировать бизнес-логику:
Если деньги уходят, а заказ не появляется — это один из самых сильных индикаторов компрометации.
Смотреть нужно:
access.logerror.logphp-fpm logsИскать стоит:
Важно убедиться, что:
root-owned файлов в web-каталогах;Очень важный тест после очистки — наблюдение. Если после удаления вредоносного кода через несколько дней или недель снова появляются изменения в других файлах, значит первичный вредоносный код удалён не полностью, остался бэкдор или есть компрометация через панель, модуль или украденные доступы.
Главная ошибка — остановиться на первом найденном симптоме.
Если вы нашли и удалили вредоносную ссылку в корзине, это ещё не означает, что проблема решена. В описанном случае именно так и произошло: сначала была обнаружена и удалена ссылка на сторонний процессор оплаты картой, но спустя три недели выяснилось, что злоумышленник сохранил доступ и уже вмешался в платёжный модуль глубже. В итоге Google Pay и Apple Pay начали работать в интересах атакующего, а покупки не фиксировались в истории магазина.
По итогам расследования можно сделать несколько важных выводов.
Этот инцидент показал типичную, но очень опасную схему: сначала компрометация файловой структуры, затем закрепление через бэкдоры, затем подмена поведения checkout-страницы, а позже — вмешательство непосредственно в платёжный модуль.
Снаружи это может выглядеть как странный баг корзины или проблемы с фиксацией заказов. На практике же это может быть хорошо растянутая во времени атака, где злоумышленник сначала получает доступ, потом сохраняет его, а затем начинает извлекать деньги через подмену оплаты.
Поэтому любой случай, когда в корзине появляется лишняя ссылка, покупатель оплачивает заказ, а запись не появляется в системе, код платёжного модуля меняется без санкционированных работ, а между инцидентами есть интервалы в недели, нужно рассматривать как полноценную компрометацию до тех пор, пока не доказано обратное.
SOLLER.LV поможет провести технический аудит, проверить checkout и платёжные модули, найти следы закрепления, сравнить файлы с оригиналами и оценить, остановлена ли активная фаза компрометации.