Lembre-se Magecart?
Em novembro do ano passado, pesquisadores de segurança descobriram que o malware infame, conhecido por colheita detalhes do cartão de crédito de formas de verificação geral, [wplinkpreview url =”https://sensorstechforum.com/sites-magecart-malware-reinfected/”]poderia re-infectar mesmo após clean-up.
Agora, O Magecart está ativo novamente em campanhas notórias nas quais 277 sites de comércio eletrônico foram infectados em ataques à cadeia de suprimentos. O que isto significa?
Novas campanhas de Magecart detectadas
Pesquisadores de segurança da RiskIQ e Trend Micro encontraram um novo subgrupo conhecido como Magecart Group 12 que está infectando sites segmentados através da inserção de código de desnatação em uma biblioteca JavaScript de terceiros. Esta técnica carrega o código malicioso em todos os sites que utilizam a biblioteca.
Pesquisas adicionais sobre essas atividades revelaram que o código de escumação não foi injetado diretamente nos sites de comércio eletrônico, mas para uma biblioteca JavaScript de terceiros da Adverline, uma empresa francesa de publicidade on-line, que contatamos prontamente. A Adverline lidou com o incidente e imediatamente executou as operações de correção necessárias em relação ao CERT La Poste, disseram pesquisadores da Trend Micro em seu relatório.
Os pesquisadores do RiskIQ também monitoram de perto o grupo Magecart. Pelo visto, Grupo 12 criou sua infraestrutura em setembro do ano passado, domínios foram registrados, Os certificados SSL foram configurados por meio do LetsEncrypt, e o back-end de skimming foi instalado. Os hackers também utilizam um pequeno trecho com um URL codificado em base64 para o recurso que é decodificado em tempo de execução e injetado na página, Destaques do relatório RiskIQ.
O grupo conseguiu compromisso alvo sites através Adverline no final de 2018.
Deve-se notar que o código desnatação Grupo Magecart 12 de é ligeiramente diferente, com “uma torção interessante”- ele se protege da deobfuscation e análise através da realização de uma verificação de integridade em si.
Quanto ao script de injeção real, chega em duas etapas, ambos projetados para executar uma verificação de auto-integridade. Veja como as duas etapas ocorrem, Como explicado por RiskIQ:
– Todo o primeiro estágio é executado como uma função, que é definido globalmente (Isso é importante)
– O segundo estágio é codificado e preenchido com dados indesejados, que é gravado em um novo objeto div
– Esses dados do segundo estágio são então não preenchidos, decodificado, e eventualmente executado
– O código executado pega uma referência a si mesmo (que foi definido globalmente) e é submetido a uma função de hash, que é a implementação em JavaScript do hashCode de Java.
– Se a verificação valida, o próximo estágio é executado.
Felizmente, O Adverline já corrigiu o problema removendo o código malicioso da biblioteca JavaScript afetada.
Milena Dimitrova
Um escritor inspirado e gerente de conteúdo que está com SensorsTechForum desde o início do projeto. Um profissional com 10+ anos de experiência na criação de conteúdo envolvente. Focada na privacidade do usuário e desenvolvimento de malware, ela acredita fortemente em um mundo onde a segurança cibernética desempenha um papel central. Se o senso comum não faz sentido, ela vai estar lá para tomar notas. Essas notas podem mais tarde se transformar em artigos! Siga Milena @Milenyim
Me siga: