optiv/ivyIvy é um framework de criação de payloads para a execução de código-fonte VBA (macro) arbitrário diretamente na memória. O loader do Ivy faz isso utilizando acesso programático no ambiente de objetos VBA para carregar, descriptografar e executar shellcode.
Para ver a versão mais recente do Ivy ou enviar um problema, consulte https://github.com/Tylous/Ivy.
Se você quiser saber mais sobre as técnicas utilizadas neste framework, bem como as medidas defensivas para ajudar a se defender contra ele, dê uma olhada no Artigo.
Ivy é um framework de criação de payload para execução de código-fonte VBA (macro) arbitrário na memória. O loader do Ivy faz isso abusando do acesso programático no ambiente de objetos VBA para carregar, descriptografar e executar shellcode. Essa técnica é o mais próximo possível de ser realmente sem arquivos, já que a maioria dos ataques sem arquivos hoje em dia requerem algum tipo de arquivo sendo gravado no disco, bypassando assim regras padrão baseadas em assinatura para detectar código VBA. Payloads VBA típicos têm as seguintes características:
Ao executar puramente na memória, essas características comportamentais dificultam a detecção por EDRs.
Os loaders do Ivy são criptografados usando criptografia RC4 (a criptografia AES causa muito inchaço e leva uma eternidade para o VBA descriptografar) e depois divididos em strings separadas, impedindo que qualquer sandbox reconheça essas strings como strings criptografadas que devem ser investigadas. Isso também impede que qualquer mecanismo de decodificação reconheça esses payloads como algo além de caracteres inúteis.
O loader do Ivy primeiro realiza uma consulta ao registro para ativar 'Confiar acesso ao modo de objeto do projeto VBA'. Esse valor de chave de registro é armazenado no modo de usuário, o que permite ao usuário modificar o valor sem exigir permissões elevadas. O valor do registro é alterado de zero para 1; se a chave de registro não existir, o Ivy a criará com o valor '1'. Com esse valor ativado, o acesso programático ao ambiente de objetos VBA é permitido a partir de um processo diferente.
Uma vez feito isso, o loader então criará um processo oculto do Excel e carregará as strings criptografadas em uma função VBA. Isso é feito usando ActiveX para simular as ações de GUI da mesma tarefa. Isso ajuda a contornar muitos controles tradicionais em vigor para monitorar a execução. Como resultado, a função de descriptografia e o shellcode são movidos de um buffer de memória para outro, nunca tocando o disco. Finalmente, o loader usa chamadas de comando-GUI e executa a função run, que simula o ato de clicar no botão de executar macro no painel GUI do VBA, iniciando a função de descriptografia, seguida pela execução real do shellcode.
IMPORTANTE
O endpoint alvo deve ter o Microsoft Office instalado e ativado para executar, pois o Ivy depende do abuso do acesso programático ao ambiente VBA do Microsoft Office.
Isso permite que o Ivy use chamadas de sistema de baixo nível para construir sua própria versão da função WriteProcessMemory do Windows, referenciando o endereço de memória direto e valores de registro indiretamente. O Ivy pode sobrescrever seções de memória que não são graváveis sem chamar nenhuma função de API de alteração de memória. Isso é feito devido a uma característica do WriteProcessMemory que altera temporariamente as permissões da região de memória para gravável (se você tiver privilégios suficientes, que temos, já que possuímos o processo). Ela escreve o valor e restaura as permissões originais sem chamar a função VirtualProtect, em vez disso chama automaticamente a syscall associada (NtProtectVirtualMemory).
O Ivy não utiliza sua própria versão do NtWriteVirtualMemory porque esse processo de alteração temporária das permissões de memória não ocorreria, o que significa que a proteção do endereço de memória específico não seria modificada e a execução falharia. Este é um 'recurso' que a Microsoft lançou para tornar os depuradores mais estáveis. Como os depuradores desejam modificar a memória em tempo real, eles podem simplesmente modificar uma seção sem ter que realizar múltiplas tarefas. (Consulte devblogs.microsoft.com para informações)
Vamos dar uma olhada na série de eventos que um EDR veria:
Uma vez que todos os hooks do EDR foram removidos, o loader então realiza sua ação normal para estabelecer uma sessão remota.
O Ivy aborda isso removendo os hooks de DLLs comuns do sistema que o EDR hooka, isso inclui:
Ao usar unhook com um tipo de payload Inject, o loader do Ivy primeiro removerá os hooks do processo do Office, removendo o EDR dele, e então removerá os hooks no processo injetado. Isso garante que ambos os processos estejam livres de hooks, impedindo que qualquer telemetria do processo pai e filho seja enviada ao EDR.
Usando a mesma técnica de unhook, o Ivy pode fazer patch de funções do ETW, impedindo que qualquer evento seja gerado pelo processo. O ETW utiliza Syscalls internas para gerar essa telemetria. Como o ETW é um recurso nativo do Windows, os produtos de segurança não precisam 'hookar' as syscalls do ETW para obter as informações. Como resultado, para prevenir o ETW, o Ivy faz patch de várias syscalls do ETW, limpando os registradores e retornando o fluxo de execução para a próxima instrução. O patch de ETW agora é padrão em todos os loaders; se você não quiser fazer patch do ETW, use a opção de linha de comando -noetw para desabilitá-lo em seu loader.
O Ivy foi desenvolvido com Go.
O primeiro passo, como sempre, é clonar o repositório. Antes de compilar o Ivy, você precisará instalar as dependências. Para instalá-las, execute os seguintes comandos:
go get github.com/fatih/color
go get github.com/KyleBanks/XOREncryption/Go
Então construa-o
go build Ivy.go
$ ./Ivy -h
___ ___ ___ ___ ___
|\ \ |\ \ / /||\ \ / /|
\ \ \\ \ \ / / /\ \ \/ / /
\ \ \\ \ \/ / / \ \ / /
\ \ \\ \ / / \/ / /
\ \__\\ \__/ / __/ / /
\|__| \|__|/ |\___/ /
\|___|/
(@Tyl0us)
The suffering. The pain. Can't you hear them?
Their cries for mercy?