Dridex está observando você
Os autores do Dridex frequentemente lançam atualizações, como novas funções de ofuscação e nova codificação de configuração para continuar evitando técnicas de detecção e mitigação de fornecedores de segurança. Eles mudaram o foco do seu malware de instituições financeiras europeias para novas instituições bancárias nos Estados Unidos.
Evidentemente, os desenvolvedores do malware demonstram grande proficiência em paradigmas de cliente e servidor, bem como em ofuscação. A pesquisa a seguir descreve esse conjunto de habilidades. Isso, junto com o comprometimento dos autores do Dridex com as atualizações constantes e frequentes nos recursos do malware, torna o Dridex muito ágil e, consequentemente, difícil de detectar, descriptografar e analisar.
Como o Dridex observa você?
Então, como é que o Dridex está te observando sem sua permissão e você não sabe?
Ele se conecta à máquina do usuário infectado durante transações bancárias com uma sessão remota. Esta sessão é invisível para o usuário porque é realizada em outra instância da área de trabalho que o malware abre usando o protocolo VNC. Esta instância é duplicada, mas não compartilhada, o que significa que o invasor não pode ver o movimento do mouse e do teclado do usuário e vice-versa.
Após o malware ser instalado na máquina da vítima, ele "liga para casa" para o Comando e Controle (C&C) da botnet para obter a lista de alvos e solicitar os seguintes módulos: VNC e MEIAS.
O processo de ativação pode ser acionado de duas maneiras:
- Por um comando recebido do C&C
- Pelo gancho de função do navegador após inspecionar o sinalizador VNC na configuração
Esta pesquisa se concentra na abordagem de módulo injetado. (A maneira como a iniciação do VNC foi acionada dentro da configuração do Dridex foi descrita em um artigo anterior do F5.)
Fluxo de ativação do VNC
O fluxo envolve interação entre o navegador infectado e o processo explorer.exe infectado.
O papel do navegador
O sinalizador VNC na configuração é inspecionado pelo código malicioso no gancho de função de rede que o Dridex injetou no navegador.
- Este gancho permite que o Dridex inspecione cada solicitação antes que ela seja enviada pela rede.
- Se a URL da solicitação corresponder a uma URL na configuração “redirecionamentos”, uma solicitação para o script malicioso será enviada ao c&c a partir da função de rede conectada.
Quando o script é recebido, o sinalizador VNC é inspecionado.
Se o sinalizador VNC estiver ativado, o malware espera receber dados criptografados. Esses dados criptografados contêm informações que o malware usa posteriormente:- IP e PORTA VNC — o endereço remoto para conectar ao iniciar a sessão VNC
- IP e PORTA SOCKS — o endereço remoto para conectar ao iniciar a sessão SOCKS
- Os dados são criptografados usando um XOR (os primeiros 4 bytes são a chave)
Então, uma URL segmentada foi acessada e um script malicioso foi enviado ao usuário. O que vem depois?
Abaixo está um exemplo de uma resposta HTML simples do servidor com IP + Porta anexados (após a rotina descriptografada):
O navegador infectado armazena esses registros de IP criptografados no registro sob a mesma chave da configuração, mas em uma subchave separada.
O navegador infectado usa a API de objetos de eventos do Windows para informar o explorer.exe infectado para iniciar o VNC. A partir deste ponto, o processo do explorer infectado assume o processo de ativação.
Papel do Explorador
- O código malicioso no Explorer é executado em um loop infinito em um thread dedicado que é responsável pela conexão VNC e aguarda o sinal de evento do navegador. Uma vez recebido esse sinal, ele extrai os registros IP + Porta do registro e os decodifica.
- O Explorer carrega o vnc_x32.dll usando uma implementação personalizada da API do Windows “LoadLibrary”.
- Antes deste ponto, o módulo VNC reside na memória do Explorer como dados brutos.
- Após mapear todas as seções PE, ele chama DllEntryPoint do vnc.dll (com o sinalizador DLL_PROCESS_ATTACH)
- Essa técnica ofusca o ponto no tempo em que o módulo VNC é carregado, já que não é possível seguir “LoadLibrary”, tornando muito mais difícil de analisar.
- vnc_x32.dll exporta duas funções para iniciar e parar o servidor.
- O módulo worker do Explorer chama a função VncStartServer com IP e porta como parâmetros para iniciar a conexão VNC.
- Caso um endereço IP VNC externo tenha sido recebido sem o módulo SOCKS envolvido, o módulo VNC inicia uma conexão com o servidor VNC do invasor. A máquina infectada inicia a sessão remota. Esta é uma maneira única de usar o protocolo, já que normalmente o espectador atua como servidor.
- Se um endereço VNC local for recebido, o módulo Dridex escutará a conexão VNC de entrada do invasor.
- Após estabelecer uma conexão TCP com o servidor VNC, o vnc_x32.dll usa a string bot_id – passada como parâmetro para a rotina VncStartServer, para gerar um desafio. Isso é usado para verificar a identidade do servidor antes que o handshake do protocolo VNC ocorra.
Após isso, se todas as etapas forem bem-sucedidas, uma sessão remota VNC é iniciada e o fraudador pode executar ações na máquina da vítima sem que ela saiba.
Esse recurso geralmente é usado como uma ação complementar após o roubo de credenciais para contornar produtos de segurança dentro do banco. Esses produtos visam identificar o usuário usando a impressão digital exclusiva do navegador.
A equipe de pesquisa da F5 está observando o Dridex
A corrida constante entre fornecedores de segurança e criminosos cibernéticos leva os criminosos a criar malwares mais ofuscados e com muitos componentes diferentes e independentes. Esses componentes ajudam os autores de malware a superar os obstáculos e as proteções que as instituições bancárias e os fornecedores de segurança implementam. Esses componentes também adicionam uma camada de complexidade ao processo de análise, pois agora é necessário entender a interação entre os módulos.
Esta corrida também nos impulsiona, como pesquisadores, a monitorar e estar vigilantes em relação às campanhas e à evolução do Dridex.