Skimmers de US$ 25: exploração e exfiltração de IA

A IA está melhorando o retorno sobre o investimento dos atacantes. É preciso mudar o status quo. 

Em um período de cinco dias em setembro, um único atacante executou três sistemas de IA encadeados contra cerca de 100 varejistas online, invadindo a segurança de pelo menos duas dúzias deles a um custo médio de cerca de US$ 25 por empresa — e obtendo os dados de pagamento de centenas de milhares de compradores. 

A cifra de US$ 25 é o ponto crucial. A Gambit Security, empresa de inteligência de ameaças que descobriu a campanha após o servidor de testes do atacante ter sido exposto, afirmou categoricamente: este é “um dos abusos mais graves de IA para exploração já vistos”. A Gambit classificou o ritmo como “impressionante para esse período de tempo”. E a conclusão do relatório é a parte que vale a pena analisar com mais atenção do que o título: a um custo muito baixo, as ferramentas de IA demonstraram um nível de paciência e persistência que a maioria dos atacantes humanos não teria para um ataque como este, e alcançaram resultados muito melhores, muito mais rapidamente do que uma campanha operada por humanos. As equipes de segurança, argumenta o relatório, precisam adotar uma mentalidade que priorize a resiliência e uma infraestrutura que acompanhe a velocidade da IA ​​— e não apenas aprimorar as soluções de segurança já existentes. 

O que realmente aconteceu? 

Desde julho, um atacante vem executando três "armas" de IA de código aberto em sequência: uma para reconhecimento, uma para exploração autônoma e uma para orquestração. No período mais curto observado — de 10 a 15 de setembro — esse conjunto de ferramentas lançou 105 projetos de ataque e comprometeu 27 ou mais organizações (uma reportagem independente da Forbes estima o número em "pelo menos 30"). O servidor do atacante armazenava registros de 618,000 cartões de crédito, cerca de 488,000 deles pertencentes a americanos; uma empresa independente de análise de fraudes, a Overwatch Data, verificou que os dados eram reais e únicos, não preenchidos ou reciclados. Dispositivos de skimming do tipo Magecart foram confirmados em funcionamento em pelo menos 19 páginas de finalização de compra. 

A lista de vítimas abrange toda a gama de preocupações que um CISO deveria ter. Uma empresa de hotelaria e uma companhia aérea com faturamento anual superior a US$ 10 bilhões, uma varejista de moda com faturamento superior a US$ 1 bilhão — mas também uma loja de armas em Minnesota e uma varejista de cosméticos em Illinois. Se sua primeira reação ao ler uma manchete como essa for "isso é problema de uma empresa da Fortune 500", a própria campanha argumenta o contrário. 

As vítimas recebem um dispositivo de clonagem de cartões de pagamento. 

A forma como o invasor entrou variou entre as empresas — injeção de SQL, um painel de administração exposto, uma chave de nuvem vazada, um plugin vulnerável. Essa variedade é justamente o ponto principal: com a velocidade e o custo impulsionados pela IA, o vetor de entrada deixa de ser o diferencial.  

O que a maioria das vítimas tinha em comum era a etapa de monetização. Uma vez dentro do site, o skimmer precisava chegar à página de finalização da compra e os dados roubados precisavam sair do site. Essa é a etapa comum a todos os casos, independentemente de como o invasor conseguiu acesso — e é sobre essa etapa que podemos falar diretamente. 

Não vamos afirmar que o App Hardening for Web: Browser teria impedido a injeção de SQL ou a configuração incorreta na nuvem que permitiu a entrada desses invasores. O que podemos afirmar é sobre a injeção e a exfiltração em si — a parte da cadeia que é idêntica em praticamente todas as campanhas de skimming, incluindo esta. 

Defendendo-se do próximo ataque 

Essa história e outras notícias recentes repetem a mesma mensagem: as IAs exploram diversos truques para invadir sistemas. O que acontece a seguir depende das medidas de proteção implementadas. 

Duas funcionalidades do App Hardening for Web: Browser se relacionam diretamente com isso. A primeira é o monitoramento da integridade do script e do DOM na página de finalização da compra — em nosso produto, o Web App Integrity Guard — que monitora a adição ou alteração de scripts ou URLs em uma página protegida. A segunda é a lista de permissões de requisições de saída — o In-App Firewall Guard — que monitora para onde as requisições em segundo plano de uma página são enviadas e sinaliza ou bloqueia qualquer coisa fora de uma lista aprovada. 

Não queríamos apenas confiar na nossa própria documentação sobre o comportamento desses recursos, então realizamos o teste nós mesmos: uma pequena página protegida com um script estático legítimo já presente, seguida de uma simulação de injeção de skimmer (uma nova tag de script adicionada em tempo de execução) e uma simulação de exfiltração de dados (uma requisição para um domínio que nunca esteve na lista de permissões). O script estático, presente quando a proteção foi aplicada, não acionou nenhum mecanismo. No momento em que a tag de script dinâmica foi adicionada, o Web App Integrity Guard foi acionado. No momento em que a chamada de exfiltração foi enviada, o In-App Firewall Guard foi acionado. Todas as variantes de skimmer nesta campanha, independentemente de como foram implantadas, terminam da mesma forma — uma requisição para a infraestrutura controlada pelo atacante — que é exatamente a etapa que o sistema detecta, independentemente de como o skimmer foi implantado. 

Defesa em profundidade, não em uma única camada. 

Isso aborda um elo da cadeia — a injeção e a exfiltração. É bom, mas não suficiente. Impedir que os atacantes entrem é uma tarefa à parte: as falhas de injeção de SQL, os painéis de administração expostos e as chaves de nuvem vazadas que abriram as portas para várias vítimas. Se uma chave de API ou credencial de nuvem embutida estiver exposta em seu código-fonte ou aplicativo móvel neste momento, trata-se de um controle diferente — veja nosso artigo complementar sobre a campanha de coleta de segredos ShinyHunters. Nenhuma substitui a outra; juntas, elas formam a estrutura de resiliência que o próprio relatório defende, abrangendo diferentes estágios do mesmo ataque. 

O takeaway 

O vetor de entrada em um ambiente de varejo continuará variando — é isso que torna esta campanha uma prévia, e não um caso isolado. A etapa de exfiltração, por outro lado, não. Se a sua página de finalização de compra não consegue diferenciar entre o script que você inseriu e aquele adicionado por um agente de IA cinco minutos atrás, então um ataque de US$ 25 é insignificante comparado ao custo real das fraudes e da remediação. Terei prazer em demonstrar como isso se aplica ao seu próprio fluxo de finalização de compra.