Como a Interface de Verificação Antimalware (AMSI) ajuda você a se defender contra malware

Para obter uma introdução à AMSI (Windows Antimalware Scan Interface), consulte AMSI (Antimalware Scan Interface).

Como desenvolvedor de aplicativos, você pode participar ativamente da defesa contra malware. Especificamente, você pode ajudar a proteger seus clientes contra malware dinâmico baseado em script e contra vias não tradicionais de ataque cibernético.

A título de exemplo, digamos que seu aplicativo seja passível de script: ele aceita scripts arbitrários e os executa por meio de um mecanismo de script. No momento em que um script está pronto para ser fornecido ao mecanismo de script, seu aplicativo pode chamar as APIs AMSI do Windows para solicitar uma verificação do conteúdo. Dessa forma, você pode determinar com segurança se o script é ou não malicioso antes de decidir executá-lo.

Isso é verdadeiro mesmo se o script foi gerado em tempo de execução. Script (malicioso ou não), pode passar por várias passagens de desofuscação. Mas, em última análise, você precisa fornecer ao mecanismo de script um código simples e não ofuscado. E esse é o ponto em que você invoca as APIs AMSI.

Aqui está uma ilustração da arquitetura AMSI, onde seu próprio aplicativo é representado por uma das caixas "Outro aplicativo".

A interface AMSI do Windows está aberta. O que significa que qualquer aplicativo pode chamá-lo; e qualquer mecanismo antimalware registrado pode processar o conteúdo enviado a ele.

Também não precisamos limitar a discussão aos mecanismos de script. Talvez seu aplicativo seja um aplicativo de comunicação e ele verifica mensagens instantâneas em busca de vírus antes de mostrá-las aos seus clientes. Ou talvez seu software seja um jogo que valida plugins antes de instalá-los. Há muitas oportunidades e cenários para usar o AMSI.

AMSI em ação

Vamos dar uma olhada na AMSI em ação. Neste exemplo, o Windows Defender é o aplicativo que está chamando APIs AMSI. Mas você pode chamar as mesmas APIs de dentro de seu próprio aplicativo.

Aqui está um exemplo de um script que usa a técnica de codificação XOR para ocultar sua intenção (se essa intenção é benigna ou não). Para esta ilustração, podemos imaginar que este script foi baixado da Internet.

Para tornar as coisas mais interessantes, podemos inserir esse script manualmente na linha de comando para que não haja nenhum arquivo real para monitorar. Isso espelha o que é conhecido como uma "ameaça sem arquivo". Não é tão simples quanto digitalizar arquivos em disco. A ameaça pode ser um backdoor que vive apenas na memória de uma máquina.

Abaixo, vemos o resultado da execução do script no Windows PowerShell. Você verá que o Windows Defender é capaz de detectar o exemplo de teste AMSI nesse cenário complicado, simplesmente usando a assinatura de exemplo de teste AMSI padrão.

Integração AMSI com JavaScript/VBA

O fluxo de trabalho ilustrado abaixo descreve o fluxo de ponta a ponta de outro exemplo, no qual demonstramos a integração do AMSI com a execução de macros no Microsoft Office.

• O usuário recebe um documento contendo uma macro (maliciosa), que evita verificações estáticas de software antivírus empregando técnicas como ofuscação, arquivos protegidos por senha ou outros.
• Em seguida, o usuário abre o documento que contém a macro (maliciosa). Se o documento for aberto no Modo de Exibição Protegido, o usuário clicará em Habilitar Edição para sair do Modo de Exibição Protegido.
• O usuário clica em Habilitar Macros para permitir a execução de macros.
• À medida que a macro é executada, o tempo de execução do VBA usa um buffer circular para registrar [1] dados e parâmetros relacionados a chamadas para APIs Win32, COM e VBA.
• Quando APIs Win32 ou COM específicas que são consideradas de alto risco (também conhecidas como gatilhos) [2] são observadas, a execução de macro é interrompida e o conteúdo do buffer circular é passado para AMSI.
• O provedor de serviços antimalware AMSI registrado responde com um veredicto para indicar se o comportamento da macro é ou não malicioso.
• Se o comportamento não for malicioso, a execução da macro prossegue.
• Caso contrário, se o comportamento for malicioso, o Microsoft Office fechará a sessão em resposta ao alerta [3] e o AV poderá colocar o arquivo em quarentena.

O que isso significa para você?

Para usuários do Windows, qualquer software mal-intencionado que use técnicas de ofuscação e evasão nos hosts de script internos do Windows é inspecionado automaticamente em um nível muito mais profundo do que nunca, fornecendo níveis adicionais de proteção.

Para você, como desenvolvedor de aplicativos, considere fazer com que seu aplicativo chame a interface AMSI do Windows se quiser se beneficiar (e proteger seus clientes com) varredura e análise extras de conteúdo potencialmente mal-intencionado.

Como fornecedor de software antivírus, você pode considerar a implementação de suporte para a interface AMSI. Quando você fizer isso, seu mecanismo terá uma visão muito mais profunda dos dados que os aplicativos (incluindo os hosts de script internos do Windows) consideram potencialmente maliciosos.

Mais informações em segundo plano sobre ameaças sem arquivo

Você pode estar curioso para obter mais informações básicas sobre os tipos de ameaças sem arquivos contra as quais o Windows AMSI foi projetado para ajudá-lo a se defender. Nesta seção, vamos dar uma olhada no tradicional jogo de gato e rato que se desenrola no ecossistema de malware.

Usaremos o PowerShell como exemplo. Mas você pode aproveitar as mesmas técnicas e processos que demonstraremos com qualquer linguagem dinâmica — VBScript, Perl, Python, Ruby e muito mais.

Aqui está um exemplo de um script mal-intencionado do PowerShell.

Enquanto esse script simplesmente escreve uma mensagem na tela, o malware normalmente é mais nefasto. Mas você poderia facilmente escrever uma assinatura para detectar este. Por exemplo, a assinatura pode procurar a cadeia de caracteres "Write-Host 'pwnd!'" em qualquer arquivo que o usuário abre. Ótimo: detectamos nosso primeiro malware!

Depois de serem detectados pela nossa primeira assinatura, no entanto, os autores de malware responderão. Eles respondem criando scripts dinâmicos como este exemplo.

Nesse cenário, os autores de malware criam uma cadeia de caracteres que representa o script do PowerShell a ser executado. Mas eles usam uma técnica simples de concatenação de cordas para quebrar nossa assinatura anterior. Se você visualizar a origem de uma página da Web carregada de anúncios, verá muitas instâncias dessa técnica sendo usadas para evitar o software de bloqueio de anúncios.

Finalmente, o autor do malware passa essa cadeia de caracteres concatenada para o Invoke-Expression cmdlet — o mecanismo do PowerShell para avaliar scripts compostos ou criados em tempo de execução.

Em resposta, o software antimalware começa a fazer emulação de linguagem básica. Por exemplo, se virmos duas cadeias de caracteres sendo concatenadas, emularemos a concatenação dessas duas cadeias de caracteres e, em seguida, executaremos nossas assinaturas no resultado. Infelizmente, essa é uma abordagem bastante frágil, porque as linguagens tendem a ter muitas maneiras de representar e concatenar cadeias de caracteres.

Assim, depois de serem pegos por essa assinatura, os autores de malware passarão para algo mais complicado — por exemplo, codificar conteúdo de script em Base64, como neste próximo exemplo.

Sendo engenhoso, a maioria dos mecanismos antimalware também implementa a emulação de decodificação Base64. Então, como também implementamos a emulação de decodificação Base64, estamos à frente por um tempo.

Em resposta, os autores de malware migram para a ofuscação algorítmica, como um mecanismo simples de codificação XOR nos scripts que executam.

Neste ponto, geralmente já passamos do que os mecanismos antivírus emularão ou detectarão, então não necessariamente detectaremos o que esse script está fazendo. No entanto, podemos começar a escrever assinaturas contra as técnicas de ofuscação e codificação. Na verdade, é isso que explica a grande maioria das assinaturas de malware baseado em script.

Mas e se o ofuscador for tão trivial que pareça muitos roteiros bem comportados? Uma assinatura para isso geraria um número inaceitável de falsos positivos. Aqui está um script de stager de exemplo que é muito benigno para detectar por conta própria.

Nesse exemplo, estamos baixando uma página da Web e invocando algum conteúdo dela. Aqui está o equivalente no script do Visual Basic.

O que piora as coisas em ambos os exemplos é que o mecanismo antivírus inspeciona os arquivos que estão sendo abertos pelo usuário. Se o conteúdo mal-intencionado viver apenas na memória, o ataque pode potencialmente passar despercebido.

Esta seção mostrou as limitações da detecção usando assinaturas tradicionais. Mas, embora um script mal-intencionado possa passar por várias passagens de desofuscação, ele precisa fornecer ao mecanismo de script um código simples e não ofuscado. E nesse ponto, como descrevemos na primeira seção acima, os hosts de script internos do Windows chamam as APIs AMSI para solicitar uma verificação desse conteúdo desprotegido. E seu aplicativo pode fazer a mesma coisa.

Recursos relacionados

• Ameaças sem arquivos
• Office VBA + AMSI: Eliminando o véu sobre macros maliciosas
• Fora de vista, mas não invisível: derrotando malware sem arquivos com monitoramento de comportamento, AMSI e AV de próxima geração