A arte da ocultação: uma nova campanha Magecart que está usando páginas 404
Resumo executivo
O grupo de inteligência de segurança da Akamai detectou uma campanha Magecart de web skimming que está visando uma extensa lista de websites, incluindo grandes organizações nos setores de alimentação e varejo.
Essa campanha se destaca devido a três técnicas avançadas de ocultação, uma das quais nunca vimos antes, especificamente, a manipulação da página de erro 404 padrão do website para ocultar código malicioso, o que representa desafios únicos de detecção e mitigação.
As outras duas técnicas de ofuscação mostram as táticas em evolução que os invasores estão usando para evitar a detecção e estender a cadeia de ataque.
À medida que os ataques de web skimming se tornam cada vez mais sofisticados, as organizações devem permanecer vigilantes e explorar abordagens avançadas para se protegerem dessas ameaças em evolução.
Introdução
Uma nova, sofisticada e secreta campanha Magecart de web skimming está visando os websites do Magento e do WooCommerce. Algumas das vítimas dessa campanha estão associadas a grandes organizações nos setores de alimentação e varejo.
De acordo com as evidências, essa campanha está ativa há algumas semanas e, em alguns casos, o tempo é ainda maior. Essa campanha conseguiu nos surpreender com uma técnica de ocultação de alto nível que nunca havíamos encontrado.
A nova campanha
Os ataques Magecart geralmente começam explorando as vulnerabilidades nos websites-alvo ou infectando os serviços de terceiros que esses websites estão usando. Nessa campanha, todos os websites atacados que detectamos foram diretamente explorados, pois o snippet do código malicioso foi injetado em um dos seus recursos próprios.
Em alguns casos, o código malicioso foi inserido nas páginas HTML; em outros casos, ele foi ocultado dentro de um dos scripts próprios que foi carregado como parte do website.
Como em muitas outras campanhas Magecart, a infraestrutura de ataque da campanha consiste em três partes principais: carregador, código de ataque mal-intencionado e exfiltração de dados (Figura 1).
Carregador — Snippets de código JavaScript curtos e obscuros responsáveis pelo carregamento de todo o código malicioso do ataque
Código de ataque mal-intencionado — O código JavaScript principal que executa o ataque; ele detecta entradas confidenciais, lê os dados, interrompe o processo de finalização da compra e injeta formulários falsos
Exfiltração de dados — O método usado para transmitir os dados roubados para o servidor de comando e controle (C2) do invasor
O objetivo de separar o ataque em três partes é esconder o ataque de uma forma que o torne a detecção mais desafiadora. Isso permite a ativação do fluxo total do ataque somente nas páginas especificamente visadas; ou seja, devido às medidas de ofuscação usadas pelo invasor, a ativação do fluxo total do ataque só pode ocorrer onde o invasor pretende que ela seja realizada. Isso torna o ataque mais discreto e mais difícil de detectar por serviços de segurança e ferramentas de verificação externas que podem estar implementados no website visado.
Embora a maioria das campanhas Magecart compartilhe semelhanças em termos de fluxo e estágios, o que diferencia uma campanha da outra são as várias técnicas de ocultação que os invasores empregam. Essas técnicas são usadas para obscurecer a infraestrutura do ataque, esconder vestígios, complicar a detecção e a engenharia reversa e, por fim, prolongar o ataque.
Três variações da campanha
Encontramos três variações diferentes dessa campanha, demonstrando a evolução do ataque e as melhorias que os invasores fizeram ao longo do tempo para evitar a detecção e a mitigação dessa campanha:
As duas primeiras variações são bastante semelhantes, com apenas pequenas diferenças na parte do carregador.
A terceira versão é exclusiva porque os invasores usaram a página de erro 404 padrão do website para ocultar o código malicioso; essa é uma técnica de ocultação criativa que nunca vimos antes.
Vamos nos aprofundar nos detalhes técnicos das três variações dessa nova campanha.
Variação um
Nossa pesquisa começou quando identificados alguns snippets de código suspeitos, detectados por nossas ferramentas de monitoramento de inteligência de ameaças, no site de uma grande empresa. Ao analisar esses snippets, descobrimos que eles eram carregadores JavaScript codificados com códigos maliciosos, que ainda estavam presentes e ativos no website. Essa descoberta nos levou a investigar mais a fundo, o que revelou toda a campanha com suas variações e impactos em vários websites.
O carregador com a variação um: A ponta do iceberg
O skimmer injetou com sucesso uma tag de imagem HTML malformada com um atributo onerror no site explorado (Figura 2). Esse atributo contém um snippet de código de carregador mal-intencionado codificado em Base64 ofuscado. O atributo src intencionalmente vazio da tag de imagem foi projetado para impedir solicitações de rede e acionar a execução de um retorno de chamada onerror em linha contendo o snippet de código JavaScript mal-intencionado ofuscado.
O uso de tags de imagem com a finalidade de executar código JavaScript é uma técnica menos comum e mais sofisticada. Ele pode ajudar o skimmer a burlar medidas de segurança, como scanners externos que normalmente analisam o tráfego da rede, que não são acionados nesse caso específico. O código ofuscado será executado dentro do contexto da página como se fosse um script nativo próprio iniciado pela própria página.
Fig. 2: Carregador com variação um: uma tag de imagem HTML formatada inadequadamente com um atributo onerror contendo código de carregador mal-intencionado
Código do carregador decodificado: tempo de execução
Uma vez que o código codificado em Base64 ofuscado é executado no tempo de execução, ele se transforma em JavaScript simples e se torna responsável por iniciar um canal WebSocket (Figura 3). Esse canal serve como um link de comunicação bidirecional entre o navegador e o servidor C2 do invasor.
O uso de WebSockets em ataques Magecart foi observado em várias campanhas recentes. O WebSocket é considerado um método de comunicação mais silencioso e flexível, que permite que o invasor utilize um único canal de rede para vários fins. Isso inclui o envio de diferentes partes do ataque do servidor C2 para o navegador (e vice-versa), bem como a facilitação de atividades de exfiltração de dados em determinados cenários.
Outro aspecto notável do código é a detecção de bots, que verifica se o agente do usuário está sob controle de automação. Se esse for o caso, o código encerra sua execução. Essa é uma técnica antibot inteligente destinada a evitar scanners de segurança externos e sandboxes que poderiam possivelmente detectar o ataque.
Fig. 3: O código JavaScript decodificado em tempo de execução do carregador com variação um
Fluxo de comunicação do WebSocket
Quando o canal WebSocket é estabelecido, a primeira mensagem é enviada do servidor C2 do invasor para o navegador. Essa mensagem é transmitida como uma string codificada em Base64, contendo um comando JavaScript de uma linha que instrui o navegador a enviar de volta o URL atual da página.
O objetivo dessa etapa é permitir que o servidor C2 determine se a página atual é uma página de finalização de compra (confidencial) ou qualquer outra página que não seja de finalização de compra. Dessa forma, o invasor pode ajustar as próximas etapas adequadamente.
Essa validação direta do lado do servidor permite que o invasor ative o ataque somente nas páginas visadas relevantes, evitando, assim, a possível exposição em páginas não confidenciais. Esse é mais um exemplo que destaca os esforços do skimmer para escapar da detecção por serviços de segurança e scanners externos.
Quando o servidor C2 identifica um URL de página de finalização de compra, o fluxo prossegue para o próximo estágio. Nessa etapa, outra mensagem é enviada ao navegador. Trata-se de uma string longa codificada em Base64, que contém todo o código de ataque. Uma vez decodificado, um código JavaScript longo e ofuscado é revelado (Figura 4).
Esse código é responsável por realizar várias atividades mal-intencionadas na página-alvo confidencial, com os objetivos de ler os dados pessoais confidenciais e do cartão de crédito do usuário e transmiti-los de volta para o servidor C2 do skimmer.
As mensagens de exfiltração de dados ofuscadas subsequentes, contendo os dados confidenciais roubados coletados pelo código malicioso, são enviadas do navegador para o servidor C2. Como mencionado anteriormente, usar o mesmo canal WebSocket para carregar todo o código malicioso e exfiltrar dados roubados torna o processo mais silencioso e envolve menos solicitações de rede do que métodos de comunicação mais tradicionais, como XHR, fetch ou solicitações de recursos HTML.
Fig. 4: Fluxo do WebSocket nas páginas de finalização de compra
Variação dois
O carregador com a variação dois: A mesma coisa, mas com uma nova roupagem
A principal diferença entre a variação um e a variação dois está no componente do carregador. Na variação dois, o skimmer insere um script em linha com um snippet de código que se assemelha ao snippet de código Meta Pixel, um conhecido serviço de rastreamento de atividades de visitantes do Facebook, com algumas linhas adicionais dentro dele (Figura 5).
Essas linhas adicionadas são a parte real do carregador, enquanto o código Meta Pixel ao redor é uma cobertura enganosa para fazer com que ele pareça um snippet de código legítimo que não gera suspeita.
Essa técnica de ocultação, que faz com que os snippets de código mal-intencionados pareçam ser serviços conhecidos, como o Gerenciador de tags do Google ou o Facebook, ganhou popularidade nas campanhas recentes Magecart. Ela permite que os skimmers burlem a análise estática dos pesquisadores e scanners externos.
Fig. 5: Carregador com variação dois: script em linha disfarçado de snippet de código Meta Pixel com um carregador mal-intencionado dentro dele
Solicitação de imagem
Quando inspecionamos cuidadosamente as linhas suspeitas dentro do snippet de código Meta Pixel falso, elas pareciam buscar uma imagem PNG no próprio diretório do website. A solicitação de rede pareceu ser uma solicitação típica de uma imagem inocente hospedada no website. No entanto, quando examinamos o conteúdo real da imagem, ficou claro que não era tão inócuo quanto parecia (Figura 6).
Fig. 6: Solicitação de imagem de rede para uma imagem que foi adulterada pelo invasor e contém código malicioso
Snippet de código JavaScript mal-intencionado dentro de um binário de imagem
Os dados binários da imagem PNG contêm uma string codificada em Base64 anexada ao final do arquivo binário da imagem (Figura 7). Essa string é então extraída, decodificada e executada pelo snippet de código do carregador (Figura 8). A string decodificada representa um snippet de código JavaScript que é idêntico ao encontrado dentro do atributo onerror do carregador na variação um.
As etapas subsequentes do fluxo permanecem inalteradas. Esse snippet de código se transforma em código JavaScript simples em tempo de execução, o código inicia o canal WebSocket no servidor C2 do invasor, e o restante da sequência é como foi descrito anteriormente.
Fig. 7: Os dados binários da imagem que contém o código malicioso oculto
Fig. 8: O código malicioso, que foi inicialmente codificado em Base64 e ocultado na imagem, torna-se aparente após a decodificação
Variação três
Agora, vamos falar sobre a melhor parte. Embora tenhamos visto ataques semelhantes, este é único e realmente nos surpreendeu.
O carregador com a variação três: Parecido, mas totalmente diferente
À primeira vista, este carregador parece semelhante ao carregador na variação dois, mas você verá (como vimos) que este é um cenário totalmente diferente. Em alguns casos, esse carregador se disfarça de snippet de código Meta Pixel, como visto na variação dois (Figura 9). Mas, em outros casos, ele é injetado dentro de scripts em linha aleatórios na página (Figura 10).
O primeiro aspecto notável desse carregador é uma solicitação de busca para um caminho relativo chamado "ícones".
Fig. 9: Carregador com a variação três: um snippet de código mal-intencionado oculto em um snippet de código que imita a aparência do Meta Pixel
Fig. 10: Carregador com a variação três: um snippet de código mal-intencionado oculto dentro de um script em linha arbitrário
Um erro 404? Sério?
Depois que o carregador é executado, o ataque envia uma solicitação de busca para /icons, que é um caminho relativo que, na verdade, não existe. Essa solicitação levou a um erro "404 não encontrado" (Figura 11). Após a análise do HTML retornado na resposta, parecia a página 404 padrão do website (Figura 12). Isso ficou confuso e fez com que nos perguntássemos se o skimmer não estava mais ativo nos websites atacados que encontramos.
Fig. 11: Solicitação iniciada pelo carregador de um caminho inexistente que retorna o erro 404
Fig. 12: Página de erro HTML padrão
Nunca subestime o carregador
Demos um passo para trás e reanalisamos o carregador, e encontramos a peça ausente do quebra-cabeça. O carregador continha uma correspondência regex para a string "COOKIE_ANNOT", que deveria ser realizada na página de erro 404 retornada como parte da solicitação de ícones.
Então, pesquisamos por essa string dentro do HTML 404 retornado, e voilà! Descobrimos um comentário oculto no final da página que continha a string "COOKIE_ANNOT" (Figura 14). Próximo a essa string, uma string longa codificada em Base64 estava concatenada. Essa string codificada representa todo o código de ataque JavaScript ofuscado. O carregador extrai essa string do comentário, a decodifica e executa o ataque, que tem como objetivo roubar as informações pessoais inseridas pelos usuários.
Simulamos outras solicitações de caminhos inexistentes, e todas elas retornaram a mesma página de erro 404 contendo o comentário com o código malicioso codificado. Essas verificações confirmam que o invasor alterou com êxito a página de erro padrão de todo o website e ocultou o código malicioso dentro dela!
Fig. 13: Carregador com a variação três: correspondência regex para a string "COOKIE_ANNOT".
Fig. 14: O comentário com código malicioso que foi ocultado na página de erro HTML
Exfiltração de dados
Formulário falso
Diferentemente das variações um e dois, os invasores empregaram uma técnica de exfiltração de dados comum diferente na variação três: injeção de formulário falso (Figura 15). Essa técnica é normalmente utilizada quando o skimmer não tem acesso a entradas confidenciais.
Isso pode ocorrer quando um website usa um serviço de pagamento de terceiros que implementa o formulário de pagamento em um iframe de terceiros ou em uma página externa. Para burlar esses cenários, o invasor cria um formulário falso que se assemelha muito ao formulário de pagamento original e o sobrepõe. Uma técnica que está ganhando mais popularidade. É exatamente assim que os dados roubados são exfiltrados na variação três.
Fig. 15: O formulário falso injetado pelo código malicioso
Quando o usuário envia dados para o formulário falso do invasor, um erro é apresentado, o formulário falso é ocultado, o formulário de pagamento original é exibido, e o usuário é solicitado a inserir novamente seus detalhes de pagamento (Figura 16).
Fig. 16: O formulário falso é ocultado, e o usuário é solicitado a reinserir suas informações
Solicitação de imagem com dados roubados
Enviar o formulário falso inicia uma solicitação de rede de imagens para o servidor C2 do invasor, transportando todas as informações pessoais e de cartão de crédito roubadas na forma de uma string codificada em Base64 no parâmetro de consulta (Figura 17). Quando decodificada, essa string revela a verdadeira intenção da solicitação, e todo o fluxo do ataque se torna claro.
Fig. 17: Solicitação de rede de imagem com os dados roubados incluídos como um parâmetro de consulta de string codificada em Base64
Lições aprendidas com a variação três: O caso 404
Essa técnica de ocultação é altamente inovadora e algo que não vimos nas campanhas Magecart anteriores. A ideia de manipular a página de erro 404 padrão de um website visado pode oferecer aos agentes de Magecart várias opções criativas de melhor ocultação e evasão.
Em alguns dos casos que identificamos, o carregador mal-intencionado já havia sido removido das páginas dos websites afetados no momento da redação. No entanto, o comentário mal-intencionado na página 404 padrão permaneceu, possivelmente permitindo que o skimmer reativasse facilmente o ataque. Isso destaca a complexidade da detecção e a importância da mitigação dessa abordagem.
A solicitação do caminho próprio que leva à página 404 é outra técnica de evasão que pode contornar os cabeçalhos da Política de Segurança de Conteúdo e outras medidas de segurança que podem estar analisando ativamente as solicitações de rede na página. Isso é, sem dúvida, uma das estratégias mais sofisticadas de Magecart que encontramos recentemente.
Proteção & conformidade no lado do cliente da Akamai x skimmer
Como parte de nossa pesquisa sobre essa campanha, realizamos uma simulação desse skimmer com a Proteção e& conformidade no lado do cliente da Akamai, nossa solução que analisa o comportamento de execução do JavaScript em tempo de execução em favor da proteção contra ameaças de JavaScript e da mitigação de ataques no lado do cliente.
A solução detectou com sucesso o skimmer sofisticado e acionou um evento de alta gravidade para mitigação imediata. Em um cenário real, em que a Proteção & conformidade no lado do cliente é habilitada em uma página da Web específica, a Figura 18 ilustra o alerta que o proprietário do website receberia para que ele pudesse investigar rapidamente a ameaça e responder em tempo real com várias opções de mitigação.
Fig. 18: Alerta de simulação da Proteção e conformidade no lado do cliente detectando o skimmer
Conclusão
Essa campanha reforça o fato de que as técnicas de web skimming estão em constante evolução. Elas estão se tornando mais sofisticadas, o que torna a detecção e a mitigação por análise estática e varredura externa cada vez mais desafiadoras. Os agentes de ameaça neste domínio encontram consistentemente métodos melhores com os quais ocultam seus ataques dentro dos websites visados e burlam várias medidas de segurança que poderiam os expor.
O nível de complexidade destacado nessa pesquisa deve alertar as organizações para que permaneçam vigilantes e atentas aos vetores de ataque de web skimming e busquem ativamente abordagens novas e avançadas para lidar com esses tipos de ataques.
IOCs
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
