Новая схема Magecart использует доверенные сервисы Stripe и Google Tag Manager, чтобы выносить украденные платёжные данные с сайтов интернет-магазинов. Для русскоязычной IT-аудитории здесь важен не только сам факт кражи данных карт, но и способ: злоумышленники прячут вредоносную логику внутри инфраструктуры, которую магазины обычно считают «белой» по умолчанию.
Об атаке сообщает BleepingComputer со ссылкой на исследователей Sansec, которые обнаружили новую вредоносную кампанию против Magento и Adobe Commerce. По их данным, зловред загружается через контейнер Google Tag Manager и исполняется на каждой странице, где этот контейнер подключён. Дальше начинается особенно неприятная часть: и сам JavaScript-пейлоад, и украденные данные проходят через домен api.stripe.com. Иными словами, с точки зрения сети и многих базовых политик безопасности трафик выглядит как обычная работа с платёжным провайдером, а не как контакт с подозрительным внешним сервером.
Механика атаки рассчитана на то, что домены Google и Stripe в e-commerce-проектах часто разрешены заранее и без лишних вопросов. Исследователи пишут, что вредоносный код встроен в контейнеры GTM, которые выглядят легитимно. Когда пользователь доходит до checkout-страницы, скрипт обращается к Stripe за конкретной customer-записью с идентификатором cus_TfFjAAZQNOYENR. В полях metadata этой записи хранится JavaScript-код: он собирается по частям и запускается через new Function(). Для защитных механизмов это выглядит не как классический скиммер с отдельного домена, а как нормальная работа с привычным API. Именно поэтому кража данных карт здесь опаснее типового сценария с внедрением внешнего скрипта: она ломает привычную логику allowlist-подхода.
Цель у кампании вполне традиционная для Magecart, а реализация уже нет. Скиммер охотится за данными банковской карты на страницах оформления заказа: номером, сроком действия, CVV, именем владельца. Параллельно он забирает сопутствующие данные, которые полезны для дальнейшего мошенничества, включая billing-адрес, email и телефон. Украденная информация не уходит сразу наружу. Сначала она склеивается в одну строку, маскируется через XOR и сохраняется локально. Затем отдельная процедура, которая запускается после загрузки страницы и повторяется раз в минуту, делит этот blob пополам, создаёт новый объект customer в Stripe и раскладывает украденные данные по metadata-полям. Каждая похищенная карта фактически превращается в поддельную запись клиента в Stripe-аккаунте атакующего. После копирования локальные следы удаляются, чтобы не оставлять артефакты и не загружать одни и те же данные повторно.
Отдельно показателен таймлайн. По данным Sansec, Stripe customer-запись, содержащая скиммер, была создана 24 декабря 2025 года. Это не доказывает, что кампания в точности тогда и стартовала, но довольно уверенно говорит, что операция могла работать как минимум с конца 2025-го. Для защитников это неприятная деталь: получается, злоупотребление доверенными SaaS- и cloud-сервисами могло оставаться незаметным месяцами. В отчётах о компрометации интернет-магазинов обычно обсуждают уязвимые плагины, утечки админ-доступа или плохо обновлённые CMS. Здесь проблема шире: если инфраструктура аналитики и платежей считается заведомо безопасной, злоумышленнику не нужно строить собственную заметную экосистему, он просто арендует доверие чужого бренда.
Sansec также нашла вариант той же кампании, где вместо Stripe используется Google Firestore. В этой версии пейлоад берут из документа tracking/captcha в проекте braintree-payment-app, а украденные данные кладут в другой ключ localStorage, _d_data_customer_. Названия подобраны с понятным умыслом: «braintree», «captcha», «tracking» хорошо растворяются в обычном шуме платёжной инфраструктуры и антибот-защиты. Для разработчиков и DevSecOps это прямой намёк, что простое логирование списка внешних доменов уже не даёт прежнего уровня уверенности. Если домен легитимен, это ещё не делает легитимным конкретный сценарий его использования. Придётся смотреть глубже: какие GTM-контейнеры реально загружаются, какие API-методы вызываются из checkout-потока, что именно прилетает в metadata и почему на клиенте вообще исполняется код, собранный из данных удалённой записи.
Для бизнеса вывод тоже без особой романтики. Интернет-магазин может формально соблюдать базовую гигиену, держать включённый Content Security Policy и всё равно пропустить атаку, если CSP строился вокруг идеи «доверяй известным доменам». В этой модели Stripe и Google Tag Manager становятся удобным туннелем для обхода сетевых фильтров и политик браузера. Для команд, которые поддерживают Magento, Adobe Commerce и другие нагруженные storefront-платформы, это ещё один аргумент в пользу ревизии всех сторонних скриптов, контейнеров тег-менеджера и правок checkout-страниц. Проверять нужно не только кодовую базу, но и операционные процессы: кто имеет доступ к GTM, как аудитируются изменения контейнеров, есть ли детектирование необычных вызовов к платёжным API и сравниваются ли клиентские артефакты с эталонными версиями. Пользователям Sansec советует использовать одноразовые виртуальные карты с лимитами, но для магазинов это, конечно, не решение, а напоминание о цене пропущенного инцидента.
История с Stripe и Firestore показывает неприятный, но уже вполне зрелый тренд: атаки на e-commerce всё реже выглядят как грубый вброс подозрительного скрипта с неизвестного домена. Они всё чаще маскируются под штатную работу облачных сервисов, платёжных шлюзов и маркетинговых инструментов. Для команд безопасности это означает пересмотр самого понятия «доверенный трафик»: если кража данных карт живёт внутри разрешённой инфраструктуры, бороться придётся не со списком доменов, а с поведением, контекстом и аномалиями в цепочке загрузки кода.