Jump to content
  • Por dentro do Ransomware Nephilin

       (1 review)

    Faz algum tempo que ando botando mais a mão na massa na parte prática da análise de malware e nos conceitos que a envolvem. Este fato somado com minha paixão por tomar notas nos meus estudos acaba resultando na criação de alguns relatórios. Com isto em mente, decidi colocar aqui a análise do último sample no qual trabalhei, de um ransomware chamado Nephilin.
     
    Overview
     
    O Nephilin é uma variante do Nefilim, um Ransomware que acabou ficando bem conhecido no mês de fevereiro/março devido ao fato de ser uma variante do conhecido Nemty, que costumava trabalhar com operações de RaaS (Ransomware as a Service - um modelo de negócio utilizado por criminosos que facilita muito a distribuição de Ransomwares. Basicamente o criador do malware recruta pessoas para usarem o Ransomware e recebe uma parte de seus lucros, facilitando assim a distribuição e a entrada de pessoas não experientes no crime). Por mais que as formas de operação sejam diferentes, há similaridades de código entre essas três famílias de malware.
     
    Análise Estática
     
    O sample analisado foi compilado para x86 e não possui nenhuma técnica que possa dificultar nossa análise como por exemplo packers/protectors e o uso de ASLR. No entanto, este binário é assinado com um certificado válido:
     
    image.png.1dfc5082f0eca6128380b68cb9adaf27.png
     
    Olhando os imports podemos notar que a Import Directory Table possui apenas uma entrada, a da kernel32.dll, levantando a suspeita da utilização de runtime linking, ou seja, o loader não resolve o endereço das funções em tempo de carregamento, pois eles são resolvidos em tempo de execução:
     
    image.png.2959f6443e0c8056048aafc57afc8867.png
     
    Podemos suspeitar ainda mais pelo fato do nome algumas DLLs estarem na lista de strings do binário, assim como o nome de algumas funções que não são exportadas pela kernel32.dll:
     
    image.png.ef382850bc0c9acc9331588d36bc770f.png
     
    Não vou me preocupar muito com esta parte estática da análise, tendo em vista que a ideia deste artigo é cair de cabeça em cada funcionalidade do malware, isto é, executá-lo e ir analisando seu comportamento.
     
    Análise Dinâmica
     
    A primeira função que o malware chama é a que vai criar todo o contexto de criptografia para gerar uma chave que será a chave utilizada para descriptografar a Ransom Note:
     
    image.thumb.png.9a30fee98f6d5d77c4fa8b8cbe9acf7c.png
     
    image.thumb.png.37c57edec6f9ef726597f4225555db33.png
     
    Dentro desta função existem várias funções que permitem trabalhar com criptografia no Windows. A primeira função criptográfica chamada é a CryptAcquireContext, responsável por criar um handle para um key container dentro de um Cryptographic Service Provider (CSP). Após pegar o handle, o tamanho de uma string é calculado para posteriormente se criar e retornar um Hash Object dentro do CSP criado anteriormente. Esta string tem 66 bytes de tamanho (0x42 em hexa) e é uma string lotada de "a".
     
     A função CryptCreateHash cria o Hash Object especificando o tipo como SHA1 e, logo depois, a função CryptHashData tira o hash do que está dentro de um buffer de tamanho 66 bytes sendo passado como parâmetro:
     
    image.png.4de23e89f0c64ae5ab96fb80e576c6b5.png
     
    image.thumb.png.17eb9ca0d01a4c5390ce05417bbb0852.png
     
    image.thumb.png.c954886dc820b08509dafa6f33a3d242.png
     
    Por fim, o SHA1 gerado é derivado, para a geração de uma chave RC4. Como podemos ver quase todas as funções estão sendo importadas dinamicamente. ?
     
    O que acontece após a função que gera esta chave RC4 é a criação de um Mutex com o nome "sofos delaet sosos":
     
    image.thumb.png.7ab2876cc9b599339955a885ee833afb.png
     
    Em seguida, uma string em base64 aparece e é decodada com a função CryptStringToBinary, resultando em uma chave pública RSA:
     
    "BgIAAACkAABSU0ExAAgAAAEAAQDNFw18bUF1x32DZaZt4gnQtAnv5XH60d9B6UgIbVfRdHPeyEljZLKlGBKFPTsh+8xsDHe/9vynuOlnuPt91grReMAwcTDVkxBh/PDkf3Jq0bnFgZAWbgMvGX6lApXTDcTArf4US63VI3z8YPyDNJwEvBEWI13ywob8ECLsrD/C6BPkYG0mBU1ccixzOgkgad0iDvwS/C8iyW1Mi0PCoBa+3TCTVwt0Zpy/HceV5U7SevG7RRN5HrErv54Ihg6kTPPhdxkYdO+CUND19aLqh8MAVLRuP5hR6b6r7cjBNAW2+USaaMyT/llNXdPdySbatLlH6Mau4z1eqzYc7hMB2f+6"
     
    image.thumb.png.ee23ab0d63ab3d7ebaef213232cf195e.png
     
    image.png.977558043b3e1e96557242c9eedfa5e6.png
     
    Há depois uma tentativa de pegar um handle para um CSP onde o key container tem o nome  "rsa session" e, sem sucesso, o binário cria um novo chamado "skr skr skr":
     
    image.thumb.png.18639acce79b90ef01fdef41d32e7ca0.png
     
    Agora a chave pública decodada anteriormente será importada para o contexto "skr skr skr":
     
    image.thumb.png.2d6f05b299fcbac43bdc42aec5dd1652.png
     
    image.png.6d20a48043f438755e64cc293574afa6.png
     
    Ações padrão da maioria dos ransomwares incluem desabilitar a checagem de erros durante o boot, desabilitar o modo de recuperação, deletar backups, etc. O Nephlin faz isso através de uma chamada à função ShellExecuteA() passando uma linha com o cmd.exe como parâmetro:
     
    "C:\\asdfgsdgasd\\..\\Windows\\asdgagsahsfahfhasahfsd\\..\\System32\\cmd.exe" "/c bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet & wmic shadowcopy delete"
     
    image.thumb.png.a3c4bbe8379a89f5587f4aa7a8a40b45.png
     
    Aqui foi utilizada uma abordagem um tanto curiosa, tendo em vista que o malware considera diretórios que provavelmente não existirão no sistema de arquivos da vítima ("asdgagsahsfahfhasahfsd", por exemplo) e sobe um nível no filesystem utilizando ".." para acessar de fato o que importa, ou seja, o caminho real seria simplesmente "C:\Windows\System32\cmd.exe" ?
     
    Neste momento acontece uma checagem em relação à como o malware foi executado na linha de comando. Se foi passado algum parâmetro, ele checa pra ver se é um arquivo ou diretório. Se for um arquivo, ele chama direto a função que encripta. Caso seja um diretório, ele chama a função que checa uma lista de exclusão dos tipos de arquivos que ele não quer encriptar e esta função chama então a função que encripta.
     
    É interessante notar que com essas checagens o ransomware pode ser usado em diversos cenários e não simplesmente para encriptar o sistema completamente. Ex: para manualmente testar se ele está funcionando (antes da possível invasão), ser executado manualmente após a invasão visando diretórios/arquivos específicos, etc:
     
    image.png.e082bae4138d24b0c93e567593e458fb.png
     
    Se nenhum parâmetro for passado via linha de comando, o binário começa a mapear os drives que estão no sistema e pegar seus tipos, buscando especificamente por drives fixos, removíveis (pen drives, etc) e mapeamentos de rede:
     
    image.thumb.png.c0752111308978a9c7a4f6f8756e4d3c.png
     
    Após pegar o drive o seu nome é concatenado com a string "NEPHILIN-DECRYPT.txt", à fim de criar a Ransom Note na raiz do Drive em questão:
     
    image.thumb.png.65f0cd0ee48dc92eeb9c252db94f9674.png
     
    Após a chamada à CreateFile, podemos ver a Ransom Note sendo criada, mas vazia por enquanto:
     
    image.png.73accce4a8de8c028e2d28d758b80e0f.png
     
    Antes do conteúdo ser de fato escrito no arquivo, ele precisa ser decodado, tendo em vista que é uma string em base64 (sim, outra string em base64):
     
    image.thumb.png.e5dfa670e60df9c57bf2a664fe012491.png
     
    Abaixo está o buffer que contém o conteúdo da Ransom Note em base64:
     
    image.png.73a2694147492320e96b384a50390061.png
     
    Após decodar o base64 o buffer aparenta estar encriptado, e de fato está:
     
    image.png.09048bc372cf0e706ec8f461b4fed076.png
     
    A função CryptDecrypt utiliza a chave RC4 gerada anteriormente para decriptar o conteúdo do buffer em questão. Podemos ver o conteúdo em clear text após a execução da função:
     
    image.png.b521ca6dff4777a5cf8e49ae94df3893.png
     
    Por fim podemos ver a função WriteFile, que irá escrever o conteúdo no arquivo "NEPHILIN-DECRYPT.txt" criado anteriormente:
     
    image.thumb.png.3fc9d6b2f7345e2d91591f866080c815.png
     
    image.png.398256a0c77f96f4475e5edbc550f885.png
     
    Agora que a Ransom Note foi criada, o processo de criptografia começa. O meio utilizado é através da criação de outra thread, isto é, para cada drive encontrado, uma nova thread é criada. A função CreateThread recebe como parâmetro para indicar seu início o endereço de uma função, que por sua vez chama a função que checa a lista de exclusão e depois começa a criptografia. Além disso, o nome do drive escolhido no momento é passado como parâmetro para esta função.

    Esta lista de exclusão é basicamente um lista que contém nomes de arquivos, diretórios e extensões das quais o malware não irá encriptar. Para cada arquivo encontrado o malware irá comparar com as especificações desta lista e, caso não bata, a função de criptografia será chamada:
     
    image.thumb.png.975e0abc618a1c9a1bc7308b9024b564.png
     
    image.thumb.png.0a5ccb5fe0b4d51415b3813771572964.png
     
    image.png.4d2b3101cc199f3fb44ffd30fac8f3fe.png
     
    image.png.ed4d742be06e85efe7e5185ac0f8f9e0.png
     
    Criptografia
     
    A criptografia pode começar de 3 formas diferentes, como mencionado anteriormente: passando um arquivo como parâmetro pela linha de comando, passando um diretório ou mapeando os drives e criando threads.
     
    Um trecho da função que faz as devidas checagens pode ser observada abaixo:
     
    image.png.3d04f00e99471d64cbe79095454df8db.png
     
    Se o arquivo checado não estiver na lista de exclusão, a função de criptografia é chamada:
     
    image.png.f2cc8e798ae645c5f41b3d33a7edc887.png
     
    O processo de criptografia se inicia com a abertura do arquivo em questão e a obtenção do seu tamanho. Depois disso, há duas chamadas para a função SystemFunction036 para gerar números aleatórios. Basicamente esta função é um alias para a função RtlGenRandom, que recebe como parâmetro um buffer e o tamanho do número aleatório que você quer gerar. O tamanho escolhido são 16 bytes (0x10):
     
    image.thumb.png.15af78e8274b04a590bfaa0cc247e4ed.png
     
    image.png.9cef88d8984ff2f05379a7a59efd4bce.png
     
    Tendo 2 buffers de 10 bytes de tamanho cada, com os devidos números aleatórios gerados anteriormente, há duas chamadas à CryptEncrypt, uma para cada buffer. Aqui a chave pública RSA é utilizada para encriptar o buffer em questão, resultando em outros dois buffers de 256 bytes cada.
     
    image.thumb.png.b15d2c4fa22cdf87c2b46b4a2abc5ff1.png
     
    image.png.76a2606a07c76d5285d7c42afd94ac08.png
     
    O conjunto de funções a seguir faz a mesma operação, mas apontando para lugares diferentes. A função SetFilePointerEx é utilizada para apontar para o fim do arquivo (baseando-se no tamanho obtido anteriormente) e depois a função WriteFile é utilizada para escrever os 256 bytes encriptados lá. A próxima chamada à SetFilePointerEx agora aponta para o fim do arquivo + 256 bytes e então escreve o segundo buffer encriptado onde o ponteiro está apontando.
     
    image.thumb.png.a631f976bc5874628fd4333b6730a6ac.png
     
    image.png.d337bbb77f3d88d077bcace73f79249b.png
     
    Neste momento as checagens de tamanho de arquivo começam, assim como as chamadas de função e loops que envolvem a criptografia.
     
    A primeira checagem feita é se o arquivo é maior que 64MB e, caso seja, as funções que criptografam o arquivo começam a ser chamadas de 125KB em 125KB. Caso o arquivo seja menor há uma outra checagem para ver se ele é menor que 1.2MB e caso ele não seja as funções de criptografia rodam em cima de 600KB apenas e finalizam. Caso o arquivo seja menor que 1.2MB ele é encriptado "de uma vez" e depois finaliza.
     
    image.thumb.png.da864155eaba527f35e134377b2ec08b.png
     
    image.thumb.png.5a5e51e4ff53d2a1c9f04bfc39fa2cb0.png
     
    image.thumb.png.bfa091638ab5ded94b70aeb804a43af0.png
     
    Para cada arquivo é gerada uma chave randômica com a função SystemFunction036 e depois esta é encriptada com a chave RSA pública. Esta abordagem dificulta bastante a criação de um decryptor, tendo em vista que a chave será sempre aleatória. Por outro lado, se tivemos a chave RSA privada em mãos a aleatoriedade não teria efeito nenhum pois para cada arquivo teríamos a chave responsável pela sua criptografia.
     
    Por fim a extensão ".NEPHILIN" é adicionada ao arquivo aberto:
     
    image.png.77dc0934cdc5a542295ee9b2f1095b68.png
     
    image.png.c60e66e2ed752dae92cd95f8bc01ad4d.png
     
    image.png.4c526a40d3dfdab2113935f5025bbea9.png
     
    image.png.40b0a5abfb0d9b989bf3bc908edd0797.png
     
    image.png.7ff54b9fb43188ce4f5a70922f4bab00.png
     
    Uma coisa importante a se notar é que se a criptografia foi executada para um arquivo ou diretório específico tanto a Ransom Note quanto o wallpaper do Ransomware não são criados. Podemos observar que as funções de mapeamento de drives (que contém a criação da Ransom Note) e criação do papel de parede são ignoradas devido ao salto incondicional JMP:
     
    image.thumb.png.6c5cf9929f231477b9c900a2199d8942.png
     
    E por fim...
     
    Considerando ainda que não foram especificados arquivos e diretórios, a função responsável por criar a imagem do papel de parede é chamada. Há várias funções aqui e estas utilizam funções gráficas do Windows para editar a imagem em questão:
     
    image.thumb.png.c026ca270a27e242c688822240928356.png
     
    Uma das funções chamadas nesta função responsável por criar a imagem é justamente a função de decoda o base64 da Ransom Note, pois o que é escrito no papel de parede é a mesma coisa da Ransom Note. Após várias funções gráficas para preparar a imagem o arquivo é finalmente criado em %TEMP%, com nome god.jpg e seu conteúdo é escrito no arquivo:
     
    image.thumb.png.e35d57b33b3f77ec79fa12b7a5f77f25.png
     
    image.png.0f7e2d8004295d93422322c36ef46473.png
     
    image.png.c578e41a88878db70d952c6350772f42.png
     
     
    Após configurar a imagem como papel de parede, o malware chama sua última função, que é responsável por fechar todos os handles e contextos de criptografia ainda pendentes:
     
    image.thumb.png.c207d2c5fbdcd7a5337dc11f0feeb71c.png
     
    Depois disso, o processo simplesmente sai retornando 0.
     
    Lista de exclusão:
     
    NEPHILIN-DECRYPT.txt
    $RECYCLE.BIN
    NTDETECT.COM
    MSDOS.SYS
    IO.SYS
    boot.ini
    AUTOEXEC.BAT
    ntuser.dat
    desktop.ini
    CONFIG.SYS
    BOOTSECT.BAK
    program files
    program files (x86)
    windows
    ntldr
    RECYCLER
    bootmgr
    programdata
    appdata
    .dll
    .NEPHILIM
    .exe
    .log
    .cab
    .cmd
    .com
    .cpl
    .ini
    .url
    .ttf
    .mp3
    .pif
    .mp4
    .msi
    .lnk
     
    Espero que o estudo desta análise seja proveitoso assim como foi para mim e qualquer dúvida/feedback estou à disposição!
     
    Abraços!

    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest


  • Similar Content

    • By Bruna Chieco
      Uma vulnerabilidade que afeta VPNs da Fortinet está sendo explorada por uma nova cepa de ransomware operada por humanos, o Cring, que viola e criptografa redes de empresas do setor industrial. De acordo com o BleepingComputer, o ransomware Cring, também conhecido como Crypt3r, Vjiszy1lo, Ghost e Phantom, foi descoberto em janeiro e detectado pela equipe CSIRT do provedor de telecomunicações suíço Swisscom.
      Relatório da Kaspersky revelou que os invasores têm explorado servidores Fortigate SSL VPN expostos à Internet e não corrigidos contra a vulnerabilidade CVE-2018-13379, permitindo a violação da rede de seus alvos. 
      A partir do dispositivo Fortinet VPN, os operadores Cring movem-se lateralmente na rede corporativa de destino, roubando credenciais de usuário do Windows, usando Mimikatz para obter o controle da conta do administrador de domínio.
      As cargas úteis do ransomware são entregues aos dispositivos nas redes das vítimas usando a estrutura de emulação de ameaças Cobalt Strike implantada por meio de um script PowerShell malicioso.
      O ransomware criptografa apenas arquivos específicos nos dispositivos comprometidos usando algoritmos de criptografia robustos após remover os arquivos de backup e eliminar os processos do Microsoft Office e do Oracle Database. Em seguida, ele envia notas de resgate avisando as vítimas de que sua rede foi criptografada e que elas precisam pagar o resgate.
      As vítimas têm usado o serviço ID-Ransomware para verificar se seus sistemas foram atingidos pelo ransomware Cring desde que a operação apareceu pela primeira vez, em dezembro de 2020. Desde o final de janeiro, 30 amostras de ransomware Cring foram enviadas até o momento, diz o BleepingComputer.
       
    • By Bruna Chieco
      A fabricante taiwanesa de eletrônicos e computadores Acer foi atingida por um ataque do ransomware REvil. Segundo informações obtidas pelo BleepingComputer, os atacantes estão exigindo um resgate de US$ 50 milhões.
      O BleepingComputer teve acesso a informações do site da gangue de ransomware dizendo que a Acer havia sofrido o ataque, compartilhando algumas imagens de arquivos supostamente roubados como prova. Em resposta às perguntas do BleepingComputer, a Acer não declarou se sofreu um ataque do ransomware REvil, dizendo apenas que "relataram situações anormais recentes".
      A Acer disse ainda que monitora rotineiramente seus sistemas de TI e a maioria dos ataques cibernéticos está bem defendida. "Empresas como nós estão constantemente sob ataque e relatamos situações anormais recentes observadas às autoridades policiais e de proteção de dados relevantes em vários países". A Acer complementou dizendo que "há uma investigação em andamento" e que por questões de segurança não poderia comentar os detalhes.
    • By Bruna Chieco
      Mais uma empresa da área de tecnologia foi vítima de um ataque de ransomware. A Stratus Technologies informou que sofreu o incidente no dia 17 de março. "Ao detectar atividades suspeitas, colocamos vários sistemas offline para isolar o problema e iniciamos nosso plano de continuidade de negócios", diz comunicado da companhia. 
      A empresa informa ainda que as autoridades policiais federais foram notificadas sobre o ataque, e especialistas no assunto recrutados para avaliar a natureza e o escopo do incidente. "Como medida de precaução, colocamos offline o Active Service Network (ASN) e o Stratus Service Portal. Com relação ao ASN, entramos em contato com nossos clientes e parceiros para fornecer mais suporte", diz o comunicado assinado por Dave Laurello, Presidente e CEO da Stratus Technologies.
      Os produtos Stratus são comumente usados por bancos, provedores de telecomunicações, call centers de emergência e serviços de saúde. Seu principal foco é a produção de servidores e software de computadores tolerantes a falhas.
    • By Bruna Chieco
      No início de março, foi noticiado que pelo menos 30 mil organizações só nos Estados Unidos foram invadidas por uma unidade de espionagem cibernética agressiva chinesa que se concentra em roubar e-mails das vítimas. A invasão ocorre por meio da exploração de quatro falhas recém-descobertas no software de e-mail Microsoft Exchange Server, que foram corrigidas pela Microsoft. Mas aparentemente as gangues de ransomware também estão começando a explorar os servidores vulneráveis.
      Segundo reportagem da Vice, os cibercriminosos estão entrando em cena para tentar monetizar os servidores de e-mail não corrigidos. A Microsoft relatou ter detectado um novo tipo de ransomware direcionado aos servidores Exchange chamado DoejoCrypt ou DearCry. 
      Um pesquisador de segurança da própria Microsoft diz que os atacantes ainda estão em uma fase preliminar, classificando quais organizações eles invadiram antes de decidir onde vão tentar monetizar.
      A Vice informou também que os cibercriminosos precisam visar e explorar manualmente os servidores Exchange, e não há evidências de que eles possam fazer o ransomware se espalhar de forma automatizada. Ainda assim, atacantes relativamente pouco sofisticados, estão entrando na onda de exploração dos servidores Exchange.
      Isso leva novos desafios às empresas que, muitas vezes, podem nem saber como descobrir se foram comprometidas, diz a reportagem. De acordo com a Palo Alto Networks, ainda existem cerca de 80 mil servidores Exchange vulneráveis.
    • By 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/
×
×
  • Create New...