Por Dentro de um Skimmer de Pagamento WooCommerce: Como os Carders Migraram de Páginas de Phishing para Backdoors de Checkout

Resumo Executivo

Durante anos, o ponto de entrada para dados de cartão roubados era a página falsa: portais de empréstimos falsos, sites de resgate de recompensas, iscos de reentrega de encomendas e logins bancários semelhantes que enganavam as vítimas para digitarem os detalhes dos seus cartões num formulário controlado por um atacante. Os contactos HUMINT da CloudSEK com operadores ativos em mercados de carding (Savastan0, Cvvhub, Jerrys, Zillion, Proton, VClub, Pepe, lojas focadas em CVV e vários fóruns apenas por convite) indicam uma clara mudança na técnica. Os atores mais técnicos abandonaram em grande parte o phishing autónomo para comprometimento direto de sites de e-commerce legítimos  obtendo acesso a web-shells, plantando um backdoor no fluxo de pagamento ou nas suas proximidades, e recolhendo silenciosamente dados de cartão de clientes reais durante compras genuínas.

Esta publicação analisa um desses artefatos: um altamente ofuscado do lado do cliente skimmer de pagamento recuperado de uma loja WooCommerce comprometida que executa WooCommerce Payments (Stripe). O skimmer personifica o elemento de pagamento real do Stripe, valida cartões em tempo real para que a vítima nunca suspeite de nada.

Esta análise é defensiva na sua intenção. Descreve o comportamento, a cadeia de ataque, os indicadores de comprometimento e a remediação para que comerciantes, fornecedores de alojamento e defensores possam detetar e remover esta classe de ameaça. Deliberadamente, não reproduz uma versão funcional ou reutilizável do código malicioso.

Análise

1. Contexto: A Transição do Phishing para o Comprometimento do Checkout

O phishing de cartão tradicional depende de convencer uma vítima a visitar uma página controlada por um atacante e a inserir dados voluntariamente. Isso Envio de spam o modelo enfrenta atrito: domínios são rapidamente queimados, listas de navegação segura do navegador detetam iscas conhecidas e as taxas de conversão dependem da qualidade do gancho de engenharia social.

O comprometimento do checkout remove esse atrito completamente. Em vez de atrair as vítimas para um site falso, o atacante leva o roubo para onde os clientes já confiam no ambiente: uma loja real, um carrinho real, um checkout real. Este é o Magecart modelo, nomeado em homenagem ao conjunto de grupos que foram pioneiros na injeção de skimmers JavaScript em lojas online comprometidas. Principais vantagens para o atacante:

• A confiança é herdada: A vítima está num site que escolheu, com um certificado TLS válido e uma marca familiar. Não há nada em que "cair".
• Os dados são recentes e de alto valor: Os cartões são capturados no momento de uma compra real, emparelhados com detalhes de faturação e e-mail, exatamente os Fullz que são vendidos a um preço premium.
• Persistência e discrição: Um skimmer bem escondido pode funcionar por meses, e como o pagamento legítimo ainda é concluído, nem o cliente nem o comerciante notam algo errado.

Os dados recolhidos desta forma alimentam diretamente as mesmas lojas de carding da deep web, dark web e surface web que anteriormente dependiam de despejos de phishing.

2. A Amostra em Resumo (sender.js)

3. Análise Técnica (Comportamental)

O seguinte descreve o que o código faz a nível comportamental, o entendimento que um defensor precisa para detetá-lo e remediá-lo. Detalhes de implementação que auxiliariam a reprodução foram intencionalmente omitidos.

‍

Skimmer de Pagamento de E-Commerce - Fluxo de Ataque

3.1 Ofuscação e ocultação de strings

O script começa com um grande array de fragmentos de string que é rotacionado no momento do carregamento, além de uma função de consulta que mapeia índices numéricos de volta para essas strings. Todo identificador significativo, IDs de elementos, nomes de eventos, mensagens de erro, seletores de destino são referenciados através desta consulta, em vez de aparecerem como texto simples. Este é o formato de saída padrão de ofuscadores JavaScript comuns e é projetado para frustrar varreduras ingênuas baseadas em grep e revisões de código casuais.

Além disso, a amostra contém uma camada de codificação personalizada construída a partir de Base64 mais escape/unescape de URL e um auxiliar de inversão de string por caractere. Dois grandes blobs codificados são incorporados na tabela de strings; estes decodificam para a marcação e estilização do formulário de pagamento falso (ver 3.3). Um defensor deve tratar a presença de codificação de string multiestágio e desenvolvida internamente dentro de um script de checkout como um forte sinal de alerta por si só, pois bibliotecas de pagamento legítimas não ocultam seu próprio DOM.

3.2 Segmentação de plataforma

O skimmer visa especificamente o WooCommerce Payments. Ele procura pelo contêiner de pagamento Stripe na página (o nó wcpay-payment-element / StripeElement) e só é ativado quando encontra um checkout correspondente. Essa segmentação restrita reduz o ruído e mantém o skimmer inativo em páginas onde seria visível ou inútil.

3.3 Injeção de formulário falso (técnica de "sobreposição")

Em vez de ler o iframe real do Stripe (que é de origem cruzada e protegido), o skimmer constrói seu próprio formulário semelhante e o posiciona sobre ou em linha com a área de pagamento genuína. Os blobs decodificados contêm o HTML e o CSS inline para este formulário falso, estilizado para corresponder ao layout de campo do próprio Stripe (número do cartão, validade, CVC), até o comportamento do placeholder e o estilo de foco.

Os campos controlados pelo invasor são identificáveis por uma convenção de nomenclatura consistente: IDs de entrada com sufixo _sb (por exemplo, os campos de número do cartão, validade e código de segurança). Como estes são elementos DOM de primeira parte injetados na página, os dados digitados neles são totalmente legíveis pelo script do invasor, ao contrário do iframe real e isolado do Stripe.

3.4 Validação em tempo real para evitar suspeitas

O aspecto mais "profissional" desta amostra é o quanto ela se esforça para parecer legítima. Ela reimplementa as mesmas verificações do lado do cliente que um checkout real executa:

• Detecção de bandeira de cartão / BIN. Ele inspeciona os dígitos iniciais para classificar o cartão (por exemplo, os intervalos 4, 5, 34/37, 6011/65, série 2) e ajusta o comprimento esperado e o comprimento do CVV de acordo, de modo que um Amex mostra um código de segurança de 4 dígitos e um PAN de 15 dígitos, etc.
• Soma de verificação de Luhn. Ele executa o algoritmo padrão de Luhn mod-10 para que um número obviamente inválido acione a mesma mensagem "número do cartão inválido" que um formulário genuíno exibiria.
• Validação de validade. Ele valida o intervalo do mês e verifica a validade em relação ao mês/ano atual, rejeitando datas expiradas ou impossíveis.

O efeito é que a vítima experimenta um campo de checkout com sensação totalmente normal que formata à medida que você digita, erros inline amigáveis, mascaramento correto enquanto cada tecla digitada está sendo capturada. Não há nenhum sinal visual.

3.5 Furtividade e disfarce de pegada

O skimmer trabalha ativamente para parecer uma infraestrutura de site benigna:

• Ele armazena o estado no localStorage sob chaves criadas para se assemelhar a artefatos de marketing/análise (por exemplo, um prefixo no estilo fbpixel_), de modo que uma rápida olhada no armazenamento do navegador não o destaca.
• Ele define um sinalizador de exclusão do Google Analytics (ga-disable-G-3SDSS99J4N), suprimindo a coleta do GA na página, o que provavelmente reduz a chance de que os próprios registros de análise do comerciante detectem comportamento anômalo em torno do elemento injetado.
• Ele usa um marcador armazenado para desduplicar vítimas, evitando a exfiltração repetida do mesmo cartão para que o tráfego de saída permaneça mínimo e sem padrões.

‍

3.6 Coleta e exfiltração de dados

Assim que um cartão passa pela própria validação do skimmer, o script também extrai o e-mail do cliente do checkout e o agrupa com o PAN, validade e CVV capturados. O registro combinado é passado pela camada de codificação personalizada (Base64 + escape + reversão) e transmitido para um endpoint de coleta controlado pelo invasor. A codificação do payload ajuda o tráfego de exfiltração a se misturar em strings de consulta ou solicitações de beacon de aparência comum e a evadir regras DLP simples de correspondência de strings.

‍

4. Cadeia de Ataque Reconstruída

Com base na amostra e em informações de inteligência humana corroborantes, a operação de ponta a ponta geralmente segue esta sequência:

1. Acesso inicial: O ator obtém acesso à loja, geralmente por meio de um plugin/tema vulnerável ou desatualizado, credenciais de administrador expostas ou uma vulnerabilidade conhecida do CMS, e instala um web shell.
2. Persistência / backdoor: Usando o web shell, o ator instala um backdoor e posiciona o código para que seja executado na página de checkout (injetado em um arquivo de tema, um plugin, o banco de dados ou carregado de um host controlado pelo atacante).
3. Entrega do skimmer: O skimmer "sender.js" analisado aqui é entregue aos visitantes do checkout. Ele permanece inativo até detectar o elemento de pagamento WooCommerce/Stripe.
4. Coleta: Clientes reais concluem compras genuínas. O skimmer captura o cartão + e-mail em paralelo com a transação legítima; o pedido ainda é processado.
5. Exfiltração: Registros codificados são enviados para o endpoint de coleta, deduplicados por vítima.
6. Monetização: Cartões novos e validados com contexto de cobrança são vendidos em mercados e fóruns de carding.

Como a etapa 4 nunca interrompe a experiência do cliente, o tempo de permanência é frequentemente medido em meses.

5. Indicadores de Compromisso (IOCs)

Estes indicadores são extraídos diretamente do código analisado. Trate-os como indicadores comportamentais/de host, e não como uma assinatura definitiva, pois os atores rotacionam IDs e endpoints frequentemente.

Elementos DOM suspeitos injetados no checkout

• Campos de cartão/validade/segurança com um sufixo _sb em seus IDs que não parte da marcação genuína do WooCommerce/Stripe.
• Um formulário de pagamento duplicado ou sobreposto que aparece ao lado do wcpay-payment-element / StripeElement real.

‍

Artefatos de armazenamento do navegador

• Chaves de localStorage que imitam a nomenclatura de pixel/análise (por exemplo, um prefixo no estilo fbpixel_) que as ferramentas reais do site não definem.
• Uma chave de marcador de deduplicação de vítimas sem propósito legítimo.

Adulteração de análises

• Uma flag ga-disable-G-XXXXXXXXXX inexplicável sendo definida na página de checkout (o valor observado referia-se a um ID de medição do tipo G-3SDSS99J4N). O comerciante deve confirmar se essa propriedade do GA é realmente dele.

Características do script

• JavaScript fortemente ofuscado carregado no contexto do checkout, contendo um array de strings rotacionado, um decodificador Base64+escape+reverse personalizado e blobs codificados incorporados que decodificam para formar HTML/CSS.
• Reimplementação do lado do cliente da validação de Luhn e detecção de BIN/marca dentro de um script que não é a biblioteca oficial do Stripe/WooCommerce.

Rede

• Requisições de saída da página de checkout para um domínio não relacionado ao Stripe, ao processador de pagamentos ou às próprias análises do comerciante, especialmente aquelas que carregam longas strings de consulta codificadas ou payloads de beacon.

6. Orientação para Detecção

Para comerciantes e operadores de plataforma

• Monitoramento de integridade do lado do cliente / da página: Implemente ferramentas (ou uma Política de Segurança de Conteúdo com relatórios) que alertem sobre qualquer script novo ou alterado na página de checkout. Skimmers da classe Magecart vivem ou morrem passando despercebidos no front-end.
• Política de Segurança de Conteúdo (CSP): Restrinja script-src e connect-src a origens conhecidas e confiáveis para que scripts injetados não possam exfiltrar livremente para domínios arbitrários; use report-uri/report-to para reportar violações.
• Integridade de Sub-recursos (SRI): Fixe os hashes em scripts de terceiros para que arquivos adulterados ou trocados não consigam carregar.
• Monitoramento de Integridade de Arquivos (FIM): Monitore arquivos de tema, diretórios de plugins e arquivos principais em busca de modificações inesperadas, um local principal de persistência para o backdoor que serve o skimmer.
• Revisão do banco de dados: Verifique wp_options, plugins de injeção de widget/cabeçalho-rodapé e conteúdo de postagem em busca de blocos <script> injetados ou blobs base64.
• Verificações de anomalias em análises: Investigue quaisquer flags ga-disable-* definidas no lado do cliente e concilie os IDs de propriedade do GA com os seus próprios.
• Teste de checkout sintético: Execute periodicamente um checkout automatizado em um navegador instrumentado e compare o DOM e as chamadas de rede com uma linha de base conhecida e confiável.

Para consumidores

• Fique atento se um checkout pedir para você reinserir os detalhes completos do cartão em um segundo formulário incomum, ou se os campos de pagamento se comportarem de forma diferente do formulário hospedado normal do processador.
• Prefira métodos de pagamento por carteira/tokenizados (Apple Pay, Google Pay, PayPal) onde o cartão nunca é digitado na página.
• Use números de cartão virtuais ou de uso único para compras online onde seu banco os suporta, e ative os alertas de transação.

Trechos de Detecção e Caça

Os seguintes são defensivos; eles ajudam a localizar esta família de skimmers, não a executá-la. Ajuste as strings ao seu ambiente antes de implantar.

No lado do navegador: escaneie um checkout ativo em busca da sobreposição maliciosa

Execute nas Ferramentas de Desenvolvedor em um checkout suspeito (ou inclua em uma etapa de monitoramento sintético):

‍

Em disco: procurar nos arquivos de tema/plugin/core pela assinatura de ofuscação

Banco de dados: procurar no WordPress/WooCommerce por carregadores injetados

YARA: identificar o skimmer em arquivos/memória

rule ecommerce_skimmer_wcpay_sb_overlay

{

    meta:

        description = "Heurística para skimmer de sobreposição WooCommerce/Stripe (componente remetente)"

        author = "CloudSEK TI"

    strings:

        $field1 = "numberInput_sb" ascii

        $field2 = "expiryInput_sb" ascii

        $field3 = "codeInput_sb"   ascii

        $target = "wcpay-payment-element" ascii

        $ga     = /ga-disable-G-[A-Z0-9]{6,}/ ascii

        $rotator = /\(function\([a-z],[a-z]\)\{[^}]{0,40}while\(--[a-z]\)/ ascii

        $b64helpers = /\['(atob|btoa)'\]/ ascii

    condition:

        // segmentação + pelo menos um campo malicioso + uma característica de ofuscação/furtividade

        $target and any of ($field*) and 2 of ($ga, $rotator, $b64helpers)

}

‍

7. Além do Stripe: Como as Mesmas Técnicas se Adaptam a Outros Gateways

A amostra analisada acima visa o WooCommerce Payments (Stripe), mas seria um erro interpretar isso como um problema específico do Stripe. É uma classe de ameaça. Crucialmente, as duas primeiras etapas da cadeia de ataque — o acesso inicial e o web-shell/backdoor que garante persistência — são completamente agnósticas ao gateway. Uma vez que um ator controla a execução de código na página de checkout (ou sua renderização do lado do servidor), a única coisa que muda de um processador para o outro é como os dados do cartão são capturados na etapa 4. E isso, por sua vez, é ditado pelo modelo de integração legítimo do gateway. Compreender esse modelo indica a um defensor exatamente onde monitorar.

7.1 Dois modelos de integração, duas estratégias de captura

A maioria dos gateways modernos se enquadra em um de dois padrões, e os skimmers se adaptam de acordo:

• Campos hospedados / em sandbox (isolados por iframe): Stripe Elements, Braintree Hosted Fields, Adyen Web Components/Drop-in, Square Web Payments SDK, Authorize.Net Accept.js. Os dados do cartão residem dentro de um iframe controlado pelo processador que a página do comerciante legitimamente não pode ler. Como os dados estão fora de alcance, os skimmers respondem sobrepondo um formulário de primeira parte semelhante (exatamente o que nossa amostra faz) ou interceptando o callback de tokenização que retorna um token/nonce.
• Fluxos de redirecionamento / página hospedada ou postagem direta: alguns fluxos do PayPal, postagem direta estilo Authorize.Net mais antiga e muitos gateways regionais que redirecionam para uma página de pagamento hospedada. Aqui, a superfície do cartão na página pode ser mínima, então os atacantes preferem intercepção no lado do servidor antes do redirecionamento ou injetar uma etapa de captura extra antes da passagem.

O único indicador mais confiável e independente de gateway para um defensor é, portanto: um <input> de primeira parte coletando um PAN/CVV completo onde deveria haver um iframe em sandbox, combinado com uma conexão de saída para um domínio que não é o processador.

‍

7.2 Sinais defensivos por gateway

As notas abaixo são orientadas para a detecção — como é o fluxo legítimo e o que observar. Elas não são, intencionalmente, um guia de implementação.

‍