sfigueiredobr

91% dos crimes virtuais tem como vetor de ataque inicial o e-mail. Os anos vão passando e os atacantes aprimoram suas técnicas, fazendo o máximo possível para que um e-mail com conteúdo malicioso chegue à caixa de entrada de sua vítima. No final do ano passado, recebi uma mensagem suspeita para análise e compartilho com vocês através deste artigo o desfecho dessa história. Introdução A análise foi iniciada após o recebimento de um e-mail que foi reportado por um grupo de usuários como suspeito. A mensagem, em português, tem conteúdo que faz referência a uma suposta nota fiscal que estaria acessível através de um anexo. No campo From, observo uma tentativa clara de simular uma troca interna de mensagens já que onde deveria ser exibida o nome do remetente está um endereço de e-mail, com o mesmo domínio do destinatário, e ao lado podemos visualizar o e-mail que de fato foi utilizado para o envio da mensagem. Neste momento, já existiam evidências suficientes para contestar a veracidade da mensagem. Segui com a análise pois notei algo que me chamou atenção. Submeti os hashes dos arquivos, tanto o compactado quanto o que foi extraído, para uma consulta no VirusTotal (VT) e fiquei surpreso ao perceber que não existiam registros de análises anteriores. Pois bem, isso foi o suficiente para estimular a minha curiosidade e tentar entender se neste caso tratava-se de um ataque direcionado ou se eram apenas arquivos circulando por aí. Análise Estática Segui então com a análise do e-mail e capturei para consulta o IP e domínio do servidor de e-mail que foi utilizado como relay para o envio da mensagem e também o suposto IP de origem da mensagem: Fiz uma breve pesquisa sobre estes indicadores e notei que o domínio inepaca[.]net é bem antigo e com ótima reputação, já o IP de origem é de um serviço de internet doméstica na Itália o que levanta a suspeita de que esta mensagem veio de uma máquina previamente comprometida e parte da botnet: Esses fatores contribuem para que a mensagem passe pelos filtros de segurança e chegue até a caixa de entrada do usuário, cenário que fortalece a importância de um processo de conscientização em segurança da informação. Após descompactar o arquivo anexo, tive acesso a outro arquivo com a extensão .docx que quando executado com o Microsoft Word automaticamente já era exibido em Modo Protegido. É comum a utilização de documentos do Microsoft Office como mecanismo para download da ameaça principal já que estes apoiam a estratégia de engenharia social utilizada pelos atacantes, simulando arquivos legítimos que normalmente circulam nas empresas, e possibilitam a execução de códigos VBA (Visual Basic for Applications). Analisando o documento observei a presença de macros AutoOpen. Esse tipo de macro visa a execução de diversas instruções em background quando o documento for aberto. Por padrão, as versões mais recentes do Microsoft Word já desabilita a execução de macros junto a inicialização dos documentos, solicitando ao usuário que habilite a execução deste tipo de conteúdo alertando sobre o risco em potencial. Para tentar contornar esta proteção, os atacantes geralmente incluem uma imagem no corpo documento solicitando a habilitação do conteúdo e neste caso não foi diferente: Ao abrir os recursos de desenvolvedor, que deve ser habilitado customizando a guia de opções dentro do Microsoft Word, tive acesso ao editor de Visual Basic e localizei dois módulos e um deles era bem extenso e com várias funções e nomes que mais pareciam palavras geradas aleatoriamente. Neste momento fiquei na dúvida se aquele código era válido ou se estava ali somente para gerar confusão, dificultando a análise. Passei alguns dias analisando o código e ainda não havia chegado a um entendimento completo sobre o resultado de sua execução. Neste momento o leitor pode se perguntar por que o binário não foi submetido para análise em uma sandbox. Naquele momento eu ainda não tinha indícios suficientes de que não se tratava de um ataque direcionado. Olhando as propriedades do arquivo notei que o arquivo estava protegido para edição, uma restrição simples, sem senha, que após um clique o arquivo estava liberado. O que poderia ter no conteúdo do arquivo ou na imagem que eu não pude notar? Luz! Pressionei CTRL + T para selecionar o conteúdo do arquivo e notei que a seleção destacou algumas linhas de texto logo abaixo da imagem: Como as letras estavam brancas, coloquei a cor preta e aumentei a fonte. Pronto! O “segredo” foi revelado: Naveguei até o final do conteúdo e desconfiei de que provavelmente o texto, na verdade, era uma string base64 ofuscada com conteúdo irrelevante inserido de forma intencional: As coisas começaram a fazer sentido. Nas imagens é possível perceber que os caracteres qq)(s2) se repetem por todo o texto. Apenas removendo os caracteres que se repetem já percebemos que se trata de um script em Powershell: Continuei o tratamento da string utilizando a ferramenta Cyberchef, extraindo algumas URLs do código. A string foi ofuscada em pelo menos três camadas e ao final codificada em base64: Fiz uma pesquisa em cima das URL’s e, com base nas informações obtidas, pude ter uma noção melhor da infraestrutura utilizada. Nesse momento percebi que poderia iniciar uma análise dinâmica, já que a probabilidade de um ataque direcionado foi bastante reduzida. Análise dinâmica O binário foi submetido à plataforma Any.Run e de cara já percebemos que a ferramenta detecta a presença da ameaça EMOTET: Com a execução do binário pude complementar a análise estática do arquivo, verificando que a macro executa o código em PowerShell de forma indireta, através do Windows Management Instrumentation (WMI). Utilizar recursos nativos do sistema para execução de código é uma técnica que tem sido bastante explorada pelos atacantes na tentativa de evadir mecanismos de detecção que estejam em execução no sistema da vítima. Continuando a análise, fechei o quebra-cabeça analisando o arquivo PCAP gerado e localizando a URL utilizada para a comunicação e download de um arquivo malicioso: O arquivo baixado é da extensão .DLL, submeti o hash deste binário à uma pesquisa e diferente dos arquivos anteriores, encontrei uma análise no VT com um índice de detecção considerável. O termo Emotet se refere a um trojan bancário que foi utilizado por uma quantidade significativa de mecanismos durante o processo de classificação. Conclusão Até o início deste ano podíamos considerar o Emotet como uma das ameaças mais complexas em atividade. No final de janeiro, toda a sua infraestrutura foi desmantelada em uma ação conjunta de empresas privadas e forças policiais de diversos países. Através de um processo automatizado, o Emotet se propagava em campanhas de phishing ( como a analisada neste artigo) que de várias maneiras tentam induzir as vítimas a executarem os anexos maliciosos. Após surgir como um banking trojan em meados de 2014 e expandir suas atividades ao longo dos anos, acabou se tornando uma das principais portas de entrada para outras ameaças e ataques de escala global. No ano passado, as campanhas ganharam atenção novamente já que além da própria botnet o malware passou a ser mecanismo de distribuição de outras ameaças. As técnicas utilizadas pelo atacante e apresentadas neste artigo são observadas em uma série de campanhas que ainda estão em curso. Sendo assim, considerar uma campanha de conscientização para complementar os controles tecnológicos continua sendo uma ótima estratégia, afinal, 91% dos crimes virtuais se iniciam com um e-mail. Você já conhece o curso de Análise de Malware Online (AMO)? Se não conhece, cola lá no canal do Mente Binária no Youtube e aproveite a oportunidade de aprender gratuitamente como fazer análises semelhantes às realizadas neste artigo. Outras referências https://threats.kaspersky.com/br/threat/Trojan-Banker.Win32.Emotet/ https://www.malwarebytes.com/emotet/