DorkBot combina persistência em atalhos, injeção em processos e download de módulos

A amostra analisada atua como carregador de componentes adicionais, usa criptografia para ocultar o payload e mantém rotinas de persistência, antianálise e comunicação com infraestrutura de comando e controle.

Componente	Família de malware DorkBot, entregue por um dropper que embute um payload PE criptografado e codificado em Base64.
Vetor	Distribuição associada a links em redes sociais, mensageiros instantâneos e mídia removível infectada; a amostra também altera atalhos .lnk para iniciar o malware antes do destino legítimo.
Impacto	Execução de módulos adicionais, persistência no logon, reinicialização do processo malicioso, download de arquivos a partir de C2 e suporte a componentes voltados a DDoS ou roubo de senhas.
Prioridade	Investigar endpoints Windows com alterações em atalhos, tarefas agendadas ocultas, cópias em %appdata%, processos svchost.exe anômalos e comunicação HTTP ou TCP com padrões compatíveis.
Artefatos	Hashes observados: 153a3104fe52062844fed64c7a033d8378f7977f para o dropper e 0cf0f00b7c78d68365b4c890c76941051e244e6f para o payload desempacotado.
Alcance	Infecções foram observadas em múltiplas redes, com concentração relatada em Sri Lanka, Índia e Rússia.

Resumo técnico

DorkBot é uma família de malware conhecida desde 2012, mas a amostra descrita mostra que sua operação continuava relevante em ambientes comprometidos. O código não se limita a uma única função final: ele atua como carregador e lançador de outros binários, com módulos associados principalmente a ataques de negação de serviço distribuída e roubo de senhas. Essa arquitetura muda a prioridade defensiva, porque a presença do dropper ou do payload principal deve ser tratada como indício de estágio intermediário capaz de trazer novas cargas para o host.

A cadeia começa com um dropper simples, mas suficientemente estruturado para dificultar análise estática direta. O payload fica embutido na seção de recursos do binário como um blob codificado em Base64 e criptografado com RC4. Antes do conteúdo cifrado há 32 bytes de metadados, incluindo a chave RC4 localizada nos bytes 8 a 12. Após decodificar e descriptografar esse conteúdo, o dropper transfere a execução para um shellcode responsável por localizar o binário PE bruto, carregá-lo em memória e chamar seu ponto de entrada. Para defesa, esse detalhe é importante porque a execução maliciosa real não depende apenas do arquivo inicial visível no disco.

A amostra também inclui marcas úteis para triagem. O dropper apresenta um laço incomum que invoca uma caixa de mensagem com handle indefinido 0xFFFFA481 e o texto Will exec. Essa característica não substitui uma detecção robusta, mas pode ajudar na correlação de engenharia reversa, sandboxing controlado e comparação entre amostras. Como a família usa criptografia, injeção e persistência por atalhos, a investigação deve combinar análise de arquivo, telemetria de processo, registro, tarefas agendadas, inventário de atalhos e tráfego de rede.

Fluxo técnico

Depois de carregado, o malware executa uma sequência de rotinas voltadas a identificação do host, evasão, persistência, injeção e comunicação. Há uma verificação antianálise baseada na consulta do nome do dispositivo do disco por meio de SetupDiGetDeviceRegistryPropertyA. Caso a string contenha indicadores de ambiente virtual, como vbox, qemu, vmware ou virtual hd, o processo encerra a execução. Esse comportamento limita a visibilidade em sandboxes comuns e favorece a permanência em máquinas físicas ou ambientes virtualizados menos identificáveis.

O malware calcula identificadores de máquina a partir de informações do sistema, hash MD5, CRC32 do SID do usuário e chaves constantes usadas na geração de GUIDs. Esses GUIDs aparecem em objetos como eventos, mutexes e nomes de arquivos, reduzindo a previsibilidade simples entre hosts e dificultando buscas baseadas apenas em nomes fixos. Quando executado a partir de mídia removível, ele registra uma classe sob Software\Classes\CLSID, usando um nome de classe derivado de GUID calculado com a chave 0xDEADBEEF. Essa lógica reforça a relação da família com propagação ou execução mediada por unidades removíveis.

A persistência usa mais de um mecanismo. A amostra cria uma tarefa agendada oculta com a classe COM ITask, configurada para iniciar no logon do usuário atual. Também cria uma chave de execução automática sob Software\Microsoft\Windows\CurrentVersion\Run, com nome derivado de GUID e apontando para a cópia do malware em %appdata%. Em paralelo, um watchdog monitora a cópia em %appdata%: uma thread calcula continuamente o CRC32 do binário copiado e compara com o arquivo original; se houver alteração, a cópia é removida e regravada com o conteúdo esperado. Essa rotina pode interferir em tentativas parciais de limpeza que removem ou modificam apenas o arquivo persistente.

Outro ponto relevante é a manipulação de atalhos. O malware percorre unidades montadas obtidas por GetLogicalDriveStringsW, enumera arquivos com extensão .lnk e altera o destino usando IPersistFile. O novo fluxo faz o atalho iniciar o malware, que então recebe o caminho original para abrir o destino esperado. Para o usuário, o atalho pode parecer funcional, enquanto a execução maliciosa ocorre antes da aplicação ou documento pretendido. Essa técnica cria persistência operacional e amplia a chance de reexecução a partir de unidades locais ou removíveis.

A execução principal é deslocada para outro processo por injeção. A amostra cria um processo suspenso, mapeia a imagem do malware nele, agenda a função de controle do worker por APC e retoma a thread principal. O contexto esperado para essa execução é svchost.exe; se a injeção falhar, haveria uma tentativa de seguir no processo atual, mas o próprio código possui um erro que fecha handles em ordem problemática e pode causar crash antes de novas ações. Mesmo com esse limite, a intenção operacional é clara: mover o worker para um processo com aparência mais comum no Windows e iniciar threads responsáveis por comunicação, persistência e execução de componentes.

Superfície afetada

A superfície primária são endpoints Windows capazes de executar o dropper e gravar artefatos no perfil do usuário. O uso de %appdata%, tarefas agendadas, chaves de execução automática e atalhos .lnk indica dependência de permissões comuns de usuário para parte relevante da persistência. A amostra também interage com processos em execução, excluindo processos de 64 bits, o próprio processo e imagens com nomes teamviewer.exe e tv_w32.exe durante a seleção de alvos de injeção para watchdog. Os demais processos, além de um notepad.exe criado pelo malware, podem receber código que aguarda um evento e reinicia o malware se o processo original terminar.

A comunicação externa ocorre por dois caminhos descritos. O primeiro é uma requisição HTTP GET para obter arquivo a partir de um C2, usando subdomínio no formato v%d, com o valor numérico definido em tempo de execução; variantes podem usar subdomínios como up%d. Se o servidor retorna um arquivo, o malware grava o conteúdo em %appdata% com nome aleatório de 10 caracteres e inicia o processo. O segundo caminho usa protocolo bruto sobre TCP para obter novos endereços de C2 a partir dos quais arquivos podem ser baixados. O pedido possui 170 bytes e a resposta 517 bytes, o que fornece tamanho de mensagem útil para análise de tráfego, mesmo quando domínios concretos não estão disponíveis no contexto.

• Endpoints Windows com execução de binários a partir de mídia removível, links recebidos por mensageria ou atalhos alterados.
• Perfis de usuário com cópias suspeitas em %appdata%, nomes derivados de GUID e tarefas agendadas ocultas acionadas no logon.
• Atalhos .lnk cujo destino foi modificado para executar um processo intermediário antes do caminho original.
• Processos svchost.exe ou notepad.exe associados a mapeamento de imagem, APC, watchdog ou reinício de processo malicioso.

Hunting e telemetria

A investigação deve começar por uma linha do tempo de execução no endpoint. Eventos de criação de processo devem ser correlacionados com gravações em %appdata%, criação de tarefas agendadas no logon, modificações em chaves de execução automática e alterações em atalhos. O padrão de um atalho que chama um intermediário e, em seguida, abre o destino esperado é um sinal de alto valor, porque conecta persistência e experiência do usuário. Em ambientes com EDR, também vale procurar por processos que criam outros processos suspensos, gravam imagem PE mapeada em memória e usam APC para transferir execução.

No registro, a análise deve focar objetos sob Software\Classes\CLSID associados a mídia removível, entradas em Software\Microsoft\Windows\CurrentVersion\Run com nomes semelhantes a GUID e valores apontando para cópias em %appdata%. Em tarefas agendadas, a prioridade é identificar entradas ocultas acionadas no logon do usuário atual e criadas em proximidade temporal com a primeira execução do binário. Como o malware usa GUIDs calculados, a ausência de nomes fixos não reduz o risco; a correlação deve depender de caminho, horário, processo criador e relação com o arquivo suspeito.

Na rede, a telemetria deve procurar requisições HTTP GET feitas por processos incomuns do perfil do usuário ou por svchost.exe fora do padrão esperado, especialmente quando a resposta resulta em arquivo gravado em %appdata% e executado em seguida. Para o protocolo bruto sobre TCP, tamanhos de mensagem de 170 bytes para solicitação e 517 bytes para resposta podem auxiliar em hunting, desde que combinados com reputação, destino, periodicidade e processo de origem. Como os domínios C2 ficam armazenados no binário em blobs criptografados com AES-256-CBC, a extração estática exige engenharia reversa; em produção, é mais prático priorizar comportamento e fluxo de processo.

• Criação ou alteração de atalhos .lnk em múltiplas unidades, seguida de execução de um binário intermediário antes do destino legítimo.
• Arquivo em %appdata% com nome aleatório ou derivado de GUID sendo regravado após tentativa de alteração ou remoção.
• Tarefa agendada oculta criada para logon do usuário atual e entrada de execução automática apontando para o perfil do usuário.
• Processo suspenso, mapeamento de imagem PE, uso de APC e execução posterior em contexto de svchost.exe.
• Tráfego HTTP GET ou TCP bruto associado a download de novos arquivos e criação de processos filhos a partir de %appdata%.
• Presença dos hashes 153a3104fe52062844fed64c7a033d8378f7977f e 0cf0f00b7c78d68365b4c890c76941051e244e6f em inventário, quarentena ou telemetria histórica.

Mitigação

A resposta deve tratar a detecção como comprometimento de endpoint com possibilidade de cargas adicionais. A primeira ação é isolar o host para interromper downloads e comunicação de C2, preservando evidências de disco e memória quando possível. Em seguida, a equipe deve coletar binários suspeitos, cópias em %appdata%, tarefas agendadas, entradas de execução automática, atalhos modificados e eventos de criação de processo. Remover apenas um arquivo pode ser insuficiente, porque o watchdog pode regravar a cópia e o atalho alterado pode reiniciar o fluxo.

A contenção precisa incluir restauração de atalhos, remoção de tarefas agendadas maliciosas, limpeza das entradas de execução automática e verificação de objetos sob Software\Classes\CLSID relacionados ao comportamento observado. Processos injetados ou usados como watchdog devem ser encerrados dentro de uma sequência controlada, depois que a máquina estiver isolada e as evidências relevantes forem capturadas. Como o malware é carregador de componentes, a análise não deve parar no payload principal: arquivos baixados posteriormente, processos filhos e credenciais usadas no host precisam entrar no escopo da investigação.

No endurecimento, o controle de mídia removível e de atalhos deve receber atenção. Ambientes com alto uso de unidades USB devem monitorar criação massiva de .lnk, execução a partir de caminhos removíveis e mudanças de destino em atalhos existentes. Políticas de bloqueio ou alerta para execução em diretórios de perfil, combinadas com proteção de endpoint capaz de observar injeção, criação de processo suspenso e tarefas agendadas ocultas, reduzem a janela de execução. Também é recomendável revisar autenticações feitas a partir do host durante a janela de infecção, porque a família é associada a módulos de roubo de senhas.

A validação final deve confirmar a ausência de persistências, de tráfego residual e de artefatos regravados. Depois da limpeza, reinicializações controladas e novo logon do usuário ajudam a verificar se tarefas, chaves e atalhos não recriam o processo. Caso os hashes indicados apareçam em múltiplas máquinas, a investigação deve expandir para compartilhamentos, mídia removível usada em comum e canais de entrega por mensageria ou redes sociais. A prioridade é impedir nova execução do carregador e identificar qualquer módulo adicional que tenha sido baixado antes da contenção.

• Isolar endpoints afetados antes da remoção para preservar evidências e bloquear novas comunicações de C2.
• Inventariar e remover cópias suspeitas em %appdata%, tarefas agendadas ocultas e entradas de execução automática relacionadas.
• Restaurar destinos de atalhos .lnk alterados e verificar unidades montadas, inclusive mídia removível.
• Investigar processos injetados, downloads posteriores e binários filhos criados com nomes aleatórios no perfil do usuário.
• Revisar credenciais e autenticações associadas ao host durante a janela de infecção, devido ao papel do malware como lançador de módulos de roubo de senhas.
• Manter detecções comportamentais para Base64 com descriptografia de payload, carregamento PE em memória, APC, watchdog de arquivo e comunicação HTTP ou TCP anômala.