Злоумышленники приспособили Stripe для скрытого хищения платежных данных: новый вариант Magecart

Исследователи компании Sansec (специализирующейся на безопасности электронной коммерции) выявили новую кампанию, которая эксплуатирует платежную инфраструктуру Stripe сразу в двух ролях. Во‑первых, скиммер хранится в метаданных тестового клиента Stripe и загружается оттуда в момент оформления заказа. Во‑вторых, украденные номера карт, срок действия и CVV‑коды записываются обратно в тот же аккаунт - как фиктивные записи о покупателях. Таким образом, Stripe становится одновременно командным сервером и хранилищем для вывода данных. При этом все соединения идут через домен api.stripe.com, который большинство магазинов пропускают в своих правилах безопасности.

Как работает схема

Загрузчик помещается в реальный контейнер Google Tag Manager (идентификатор GTM‑P6KZMF63 и другие). Этот контейнер срабатывает на каждой странице, но активируется только на страницах оформления заказа. Через две секунды после загрузки страницы код обращается к API Stripe и извлекает из поля metadata конкретного клиента (cus_TfFjAAZQNOYENR) скиммер, разбитый на несколько частей - от meta0 до meta10. Затем эти фрагменты склеиваются и выполняются с помощью new Function(). Такая конструкция - по сути, удаленное выполнение произвольного кода со стороны Stripe.

Скиммер ждет нажатия на кнопку оформления заказа. Как только пользователь кликает, код собирает все поля карты (номер, месяц и год истечения, CVV), а также полный адрес доставки и итоговую сумму заказа. Все данные объединяются в одну строку, которая шифруется XOR с ключом EGAU3X9PAMJ8RYRNJSPV и сохраняется в локальном хранилище браузера (localStorage) под ключом cus_customer_id. Сама кража не отправляет данные - выводом занимается отдельная функция в том же загрузчике.

Через одну секунду после загрузки страницы и затем каждые 60 секунд загрузчик проверяет наличие записи в localStorage. Если она есть, функция pdat разделяет значение пополам и отправляет каждую половину POST‑запросом на тот же api.stripe.com, но уже в метод создания нового клиента. В теле запроса указывается фиктивный email и два поля метаданных: metadata[customer_id] и metadata[device_id]. После успешной отправки запись из localStorage удаляется.

Секретный ключ на клиентской стороне

Каждый загрузчик содержит жестко прописанный секретный ключ Stripe (Bearer sk_test_51Shuxz4fAPbvfTkr...). Это тестовый ключ (префикс sk_test_), который Stripe выдает для разработки, но он дает полный доступ к аккаунту. Размещение такого ключа в клиентском коде - грубейшая ошибка. В отчете Sansec подчеркивается, что это само по себе является признаком компрометации, поскольку легитимная интеграция никогда не передает секретные ключи в браузер.

Использование тестового режима говорит о том, что злоумышленники не пытаются проводить транзакции через Stripe. Им нужна только инфраструктура: бесплатная база данных для хранения украденных карт и точка раздачи вредоносного кода. Домен api.stripe.com по умолчанию разрешен политиками безопасности содержимого (CSP) и сетевыми фильтрами, поэтому скиммер легко обходит защиту.

Кого затрагивает атака

Селекторы в коде скиммера явно ориентированы на платформы Magento и Adobe Commerce - например, используются атрибуты payment[cc_cid], payment[cc_exp_year] и другие, характерные именно для этих систем. Значит, под удар попадают онлайн‑магазины на базе Magento. Запись в Stripe с датой создания 24 декабря 2025 года указывает, что кампания активна как минимум с конца прошлого года. Исследователи также обнаружили вариант с использованием Google Firestore вместо Stripe - там скиммер загружается из документа с говорящим именем captcha в проекте braintree‑payment‑app, что маскируется под легитимный трафик защиты от ботов.

Последствия

Подобный метод почти не оставляет следов в журналах магазина. Весь вредоносный трафик уходит на домены, которые администраторы вряд ли станут блокировать. Обнаружить атаку можно только при аудите клиентских скриптов: любое обращение к api.stripe.com или firestore.googleapis.com из браузера с секретным ключом Stripe должно немедленно настораживать. Кроме того, стоит проверять контейнеры Google Tag Manager на предмет тегов, которых не добавляла сама команда магазина. Профилактика включает мониторинг уязвимостей ядра Magento и регулярное сканирование на наличие скиммеров.

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

GTM container IDs

• GTM-P6KZMF63
• GTM-55976FLP
• GTM-MSDHV3HG
• GTM-TV4CSHVN

stripe customer ID hosting the skimmer payload

• cus_TfFjAAZQNOYENR

localStorage keys

• cus_customer_id
• _d_data_customer_

XOR key

• EGAU3X9PAMJ8RYRNJSPV

filler email used in fake Stripe customer records

• johndoe@gmail.com