Avanços na entrega: Scripting com Nietzsche

Autores:

• Jozsef Gegeny, pesquisador sênior de segurança
• Norbert Biro, pesquisador sênior de segurança
• Robert Neumann, chefe do Acronis TRU Labs

O papel das cadeias de entrega tornou-se cada vez mais importante na última década. Os agentes de ameaças passaram da simples entrega por meio de um anexo de e-mail malicioso ou download por unidade para a inclusão de múltiplas etapas intermediárias antes de implantar sua carga útil final. Essas etapas adicionais foram todas planejadas para burlar as soluções de segurança implantadas e garantir a entrega ininterrupta da carga; no entanto, devido à sua complexidade muitas vezes desnecessária, elas também representam riscos adicionais. Assim como as cadeias tradicionais, se elas se romperem em algum ponto, a continuidade será perdida para sempre.

Recentemente, nos deparamos com uma cadeia de entrega complexa que utiliza várias linguagens de script com o objetivo final de implantar famílias de malware de alto perfil, como o DCRat de código aberto ou o infostealer Rhadamanthys.

Nossa investigação começou com a chegada de uma mensagem de e-mail com um anexo no formato de um arquivo morto RAR. O arquivo morto — como esperado — não contém nenhum sumário legítimo, mas um arquivo de script do Visual Basic (VBS) chamado "Citación por embargo de cuenta" (Citação por embargo de conta). O nome do arquivo, embora claramente destinado a uma audiência de língua espanhola, traduz-se aproximadamente para o inglês como "Summons for account garnishment" (Intimação para penhora de conta). Refere-se a um aviso legal relacionado à apreensão ou bloqueio de uma conta bancária devido a dívidas ou outras obrigações financeiras. A intenção é clara: quem receber o e-mail não deve hesitar em abrir o anexo imediatamente, e com isso, a execução de uma cadeia de entrega maliciosa será iniciada.

O arquivo VBS malicioso emprega instaladores aninhados, resultando em um processo de entrega em várias etapas. Dividimos nossa análise em quatro estágios distintos, como mostrado na figura abaixo.

O Visual Basic script tem cerca de 200 KB, o que indica que não estamos lidando com um script de automação básico. Quando examinamos mais de perto, também fica imediatamente evidente que estamos lidando com ofuscação. O tamanho bastante incomum é parcialmente devido à ofuscação, como demonstrará a análise posterior — ele também contém um payload codificado, que será extraído somente no terceiro estágio.

Há diferentes maneiras de lidar com a ofuscação: é possível desofuscar manualmente, aproveitar o suporte do AMSI da Microsoft ou simplesmente ignorar a ofuscação com a promessa de ser capaz de capturar o payload final quando a execução atingir esse estágio. Na Acronis, acreditamos firmemente em uma abordagem em várias camadas quando se trata de detecção de ameaças. Por isso, preferimos neutralizar o sumário malicioso antes de sua execução, sempre que possível. Além do nosso próprio suporte AMSI, também utilizamos um emulador de script genérico desenvolvido internamente, baseado no conceito de árvore de sintaxe abstrata (AST), para automatizar a desofuscação em cenários semelhantes.

Após a desofuscação, o script se torna muito mais legível para os olhos humanos. A função principal do script VBS inicial é gerar um arquivo de batch do Windows (BAT) e transferir a execução para ele. O arquivo BAT malicioso será colocado no diretório do perfil do usuário:

O script VBS também cria uma cópia de si mesmo no mesmo diretório:

Não é surpresa que o script de lote do nosso segundo estágio também empregue ofuscação — consistentemente com a camada anterior.

Quando executado, o arquivo de batch construirá uma string codificada em Base64 a partir de inúmeras variáveis de ambiente com a ajuda do comando “set”. Essa string Base64 representa um script compacto do PowerShell, que será executado usando o argumento “-command” como se fosse digitado no prompt de comando do Windows PowerShell:

Essencialmente, ele deixa cair os dados Base64 decodificados que representam um script do PowerShell no diretório do perfil do usuário, como:

e o executa com o comando a seguir:

Curiosamente, parece que os agentes de ameaças não fizeram nenhum esforço significativo para ofuscar essa camada, pois todo o texto é simples e facilmente legível:

No entanto, ele contém alguns orçamentos notáveis, como:

A maioria, senão todas, as citações são de Friedrich Nietzsche, um filósofo alemão. Os orçamentos são adicionados como comentários no script do PowerShell e não têm finalidade funcional. Os autores de malware podem ser filosóficos, afinal.

A função principal deste script é localizar o arquivo aguwDl.bat dos estágios anteriores no diretório do perfil do usuário, ler a última linha (muito longa) dele, remover os bytes de marcação e, finalmente, decodificar e carregar o payload resultante na memória:

O payload que foi carregado na memória é um executável Windows .NET e pertence a uma Family popular de trojans de acesso remoto chamada DCRat.

O payload é compactado usando um compactador .NET personalizado e é fortemente ofuscado. Durante a análise, identificamos que ele contém duas partes de dados criptografados em sua estrutura de contêineres de recursos.

Esses blocos de dados utilizam apenas criptografia básica e podem ser facilmente descriptografados com uma operação XOR byte a byte com a chave 0x78. A decodificação desses recursos revela dois executáveis adicionais:

Um é o executável principal do DCRat e o outro é uma biblioteca que oferece suporte ao módulo de compactação no carregamento e execução da amostra do DCRat diretamente na memória, sem gravá-la no disco. Isso é feito por meio de uma técnica conhecida como RunPE, implementada na biblioteca auxiliar. O binário principal do DCRat está bastante desatualizado, mas uma infecção bem-sucedida ainda é possível com a ajuda de métodos de entrega semelhantes.

As cadeias de entrega usadas em campanhas maliciosas estão em constante evolução e se tornando mais complexas. Os atores de ameaças estão procurando maneiras de ocultar sua carga útil final — mesmo que seja apenas outra variante de uma Family de malware conhecida no setor de segurança há anos. Se tiverem êxito, até mesmo binários de malware antigos poderão ser executados sem intervenção, a menos que a solução de segurança implantada seja capaz de detectar a presença na memória.

Ao mesmo tempo, quanto mais complexas essas cadeias de entrega se tornam, maior é o risco e a oportunidade de quebrá-las a cada etapa que é adicionada, o que acaba impedindo o carregamento do payload que os criadores pretendiam.

Ao analisar essa campanha, encontramos um par de campanhas semelhantes nas quais a cadeia de infecção era uma correspondência exata — conforme descrito acima —, mas o payload final era diferente. Em vez de implantar o DCRat, os atacantes utilizaram o infostealer Rhadamanthys e outro trojan de acesso remoto popular: o Remcos.

O Acronis Advanced Segurança + Extended Detection and Response (XDR) detecta com sucesso os componentes usados na cadeia de ataque.