DIARIO já detecta macros “stomped”, mas o que são exatamente?

Algumas semanas atrás, apresentamos o DIARIO, o detector de malware que respeita a privacidade dos usuários, e continuamos a aprimorá-lo para que ele detecte mais e melhor. Recentemente, adicionamos a capacidade de detectar malware em documentos de escritório cujas macros usam a técnica conhecida como VBA stomping. Do que trata essa técnica e por que ela é tão importante?

Já sabemos que o e-mail com anexos é uma das rotas de entrada mais populares para malware , especificamente anexos do tipo office. Isso é possível, em grande medida, graças à capacidade de programar código nas macros de documentos de escritório. As razões pelas quais esta técnica continua a funcionar duas décadas depois de começar a ser usada são diversas:

• As macros são fáceis de ocultar.
• As macros são legítimas. Mesmo desativado por padrão, é fácil para o usuário ativá-los.
• O sandbox é mais complexo para emulá-los.
• Eles são enviados por e-mail, portanto, geralmente são analisados ​​apenas estaticamente.
• O usuário não acha que um documento ou planilha pode ser perigoso.
• Continua a ser uma via muito lucrativa para os ciber ataques.

E mesmo que tanto tempo tenha se passado, ainda há inovação nessa técnica. A técnica de stomped é um teste. Vamos primeiro ver do que é feita uma macro «recente». Encontraremos um arquivo binário, com extensão .bin dentro do arquivo .zip que hoje são os documentos. Pelo menos nas versões mais recentes do Office.

A primeira coisa a ter em mente é que naquele arquivo .bin não existem «macros» como tais, mas todo um sistema pronto para ser compilado e executado pelo próprio Office . Sim, pode ser comparado a qualquer projeto feito com Visual Studio, onde temos o código-fonte, as definições, o código compilado… O sistema Office atual, como Word ou Excel, possui um motor de compilação e execução para esse código.

Na verdade, dentro desse arquivo .bin, encontramos (se o analisarmos com as ferramentas apropriadas):

• PROJETO: fluxo (arquivo): é como o arquivo de configuração.
• VBA_PROJECT: fluxo com as instruções para o motor VBA. Não documentado.
• Dir: comprimido e tem o layout do projeto.
• Fluxos de módulo do tipo VBA / ThisDocument / NewMacros /… / __ SPR_1 / Module1, que contém o código a ser executado. Cada módulo do código é composto de PerformanceCache e CompressedSourceCode, que é o código-fonte da macro compactada.

Para que serve tudo isso?

Isso atende à obsessiva compatibilidade com versões anteriores da Microsoft. Vamos imaginar que criamos um documento com macros em uma versão recente do Office, por exemplo Word 2016. Criamos a macro e ela é compilada no sistema, mas o código-fonte também é armazenado com ela. Quem recebe o documento pode ter um Office 2016, caso em que para ir mais rápido, a macro compilada será executada diretamente. Mas e se você quiser abrir o documento com o Word 2003? Portanto, para compatibilidade, você precisará pegar o código-fonte VBA da macro, compilá-lo em seu mecanismo e executá-lo. E é por isso que encontramos o código-fonte das macros nos documentos «claros».

Isso tem sido uma vantagem histórica para quem analisa esse tipo de malware : eles podem acessar o código facilmente, analisá-lo com mais facilidade etc. Os antivírus até contam com esse código-fonte para classificar as amostras. Mas ocorreu a alguém que o documento ainda poderia infectar se o código compilado fosse mantido, mas o código-fonte fosse excluído. E assim foi. Essa técnica de apagamento de código-fonte é usada pelo VBA e permite que o malware passe despercebido, com pouco impacto em sua infectividade. Apenas os usuários com versões sem suporte ou muito antigas do mecanismo VBA (afinal, versões do Office) se livrariam da infecção.

Já existe a ferramenta Evil Clippy, capaz de facilitar o stomping do VBA e automatizar todos os processos necessários.

Como você pode ver, o DIARIO já detecta este tipo de documento e mostra o código mesmo que esta técnica tenha sido usada: