O trojan evoluiu de malware bancário para ecossistema modular com comunicação cifrada, atualização por hash, coleta de credenciais, propagação por spam e movimentação via compartilhamentos SMB.
| Componente | Emotet, incluindo dropper, módulos DLL, protocolo de comunicação baseado em Protocol Buffers, bibliotecas Libevent e OpenSSL e componentes de propagação por e-mail e SMB. |
| Vetor | Distribuição por spam, uso de compartilhamentos de rede, Rig Exploit Kit e atualização a partir de servidores C2 com endereços IP e portas embutidos no executável. |
| Impacto | Coleta de informações do host, roubo de credenciais armazenadas em navegador e e-mail, colheita de endereços do Outlook para spam, expansão para máquinas na LAN por SMB e manutenção de uma botnet atualizável. |
| Prioridade | Priorizar contenção de hosts infectados, bloqueio de comunicação C2, revisão de credenciais expostas, endurecimento de SMB e detecção comportamental de módulos, atualização frequente e abuso de ferramentas de coleta. |
| Artefatos | Dropper empacotado, módulos DLL moderadamente ofuscados, strings cifradas por XOR rotativo, resolução de importações por hash de função e mensagens serializadas com Protocol Buffers. |
| Comunicação | Uso de chave AES gerada no cliente e cifrada com chave pública RSA do servidor, além de compressão LZMA e identificação da versão do malware por hash do arquivo atual. |
Emotet começou em 2014 como um trojan bancário, mas a atividade descrita em 2018 mostra uma família que já havia ultrapassado a função inicial de roubo bancário. A característica mais relevante não é apenas a persistência temporal da ameaça, e sim a maturidade do ecossistema: o malware mantém dropper, atualização, módulos independentes, protocolo próprio, rotação de infraestrutura e componentes de propagação. O módulo bancário, que antes era a função central, foi removido em algum momento de 2017, deslocando o papel do Emotet para uma plataforma modular capaz de entregar e operar funcionalidades variadas conforme a campanha ou o objetivo do operador.
O desenho técnico combina engenharia defensiva de software aplicada a fins maliciosos. A comunicação usa Protocol Buffers, compressão LZMA, criptografia assimétrica e chaves simétricas por sessão. O executável traz endereços potenciais de C2 em formato de IP com porta, além da chave pública RSA do servidor. Após coletar informações básicas do sistema, o cliente informa ao C2 o hash do arquivo do malware em execução; o servidor usa esse dado para decidir se deve entregar uma versão mais recente ou seguir com a execução dos módulos. Essa lógica reduz a utilidade de assinaturas estáticas e torna a resposta defensiva dependente de telemetria comportamental, inspeção de memória, correlação de rede e controle rigoroso de endpoints.
O dropper empacotado inicia a cadeia reunindo dados do computador infectado, incluindo nome do host, nome do usuário, versão do sistema operacional e lista de processos em execução. Essas informações formam o contexto de registro do bot e acompanham a primeira comunicação com a infraestrutura de comando. A requisição é serializada com Protocol Buffers, comprimida e protegida por uma chave AES gerada localmente. Essa chave é cifrada com a chave pública RSA embutida no binário e anexada à mensagem, o que impede a recuperação simples do conteúdo apenas com a amostra do malware e uma captura de tráfego, caso o processo que gerou a chave já não esteja disponível para análise.
Depois do registro, o servidor compara a versão informada pelo hash do arquivo do cliente. Se o binário estiver antigo, o C2 pode responder com uma nova versão do Emotet; se a versão já for considerada atual, o fluxo segue para obtenção e execução dos módulos. Esse mecanismo cria uma superfície dinâmica: o mesmo host infectado pode receber módulos diferentes ao longo do tempo, e pesquisadores podem obter resultados distintos dependendo da versão, do protocolo usado e do estado da infraestrutura. A rotação frequente de dropper, módulos e servidores C2 pressiona controles baseados em hash, porque os artefatos mudam antes que assinaturas estáticas consigam cobrir a campanha com confiabilidade.
A estrutura modular se divide em duas categorias amplas. Os módulos do tipo wrapper encapsulam executáveis de coleta de dados já existentes, com cópias incorporadas e cifradas dentro do malware. Foram observados wrappers para coleta de credenciais de navegadores e de clientes de e-mail, usando ferramentas conhecidas para extrair senhas armazenadas localmente. Os módulos originais são implementados pelos autores do Emotet e tendem a ampliar a infecção, em vez de monetizar imediatamente a máquina comprometida. Um deles usa a interface Simple MAPI, já obsoleta, para coletar endereços locais do Microsoft Outlook e alimentar novas campanhas de spam. Outro atua como worm, tentando autenticação em compartilhamentos SMB acessíveis com uma tabela interna de senhas comuns, com o objetivo de infectar estáções adicionais na LAN.
A engenharia de ofuscação também é parte importante do fluxo. Os módulos são DLLs não empacotadas, mas com ofuscação moderada. Antes de chegar à funcionalidade principal, eles constroem uma tabela de importações própria, resolvendo nomes de funções por valores de hash calculados por rotina interna. Nomes de DLLs, funções e strings sensíveis são cifrados com XOR rotativo, e o código de decriptação também recebe camadas de ofuscação. O controle principal do malware usa uma máquina de estados, técnica que dificulta a leitura linear por desmontadores e aumenta o custo de análise manual.
A superfície de risco envolve estáções Windows que recebem spam malicioso, hosts expostos a kits de exploração citados na campanha e redes internas com compartilhamentos SMB acessíveis por credenciais fracas ou reutilizadas. A ameaça também alcança contas locais de usuários que armazenam senhas em navegadores e clientes de e-mail, porque os módulos de coleta operam diretamente sobre credenciais já presentes no endpoint. A colheita de endereços do Outlook amplia a superfície para contatos da vítima, transformando caixas postais locais em fonte de alvos para novas mensagens de spam.
Ambientes corporativos com controles centrados apenas em antivírus por assinatura ficam especialmente pressionados. O dropper muda com frequência, os módulos variam, os C2 rotacionam e a comunicação não depende de formatos HTTP triviais. Mesmo quando a infraestrutura é bloqueada, hosts já infectados ainda exigem erradicação, revisão de credenciais e verificação de propagação lateral por SMB. A presença de bibliotecas como Libevent, OpenSSL e Protocol Buffers não torna a atividade legítima; ela indica que o malware incorpora componentes de engenharia comuns em software convencional para aumentar estabilidade, interoperabilidade e resiliência operacional.
- Estáções de trabalho Windows que receberam anexos ou links de spam associados à cadeia do Emotet.
- Máquinas com credenciais armazenadas em navegadores ou clientes de e-mail locais.
- Redes com compartilhamentos SMB acessíveis e senhas fracas, comuns ou reutilizadas.
- Hosts que conseguem iniciar comunicação de saída para IPs e portas de C2 embutidos no malware.
- Caixas do Outlook com listas locais de endereços que podem alimentar novas ondas de spam.
A detecção deve combinar rede, endpoint, identidade e e-mail. Em rede, o ponto de atenção é a comunicação de saída de hosts de usuário para endereços IP diretos acompanhados de portas específicas, sem dependência de domínios, com payloads serializados e cifrados. A criptografia descrita impede inspeção direta do conteúdo, mas não elimina metadados úteis: periodicidade, destino, volume, processo de origem, ausência de navegação humana associada e proximidade temporal com criação de arquivos ou carregamento de DLLs ajudam a separar tráfego legítimo de beaconing malicioso.
No endpoint, a defesa deve procurar criação ou execução de DLLs ligadas a processos recém-iniciados pelo dropper, resolução anômala de importações, decriptação de strings em memória e comportamento de coleta de credenciais. A execução de ferramentas incorporadas para extrair senhas de navegadores e e-mail tende a gerar acesso incomum a repositórios locais de credenciais, arquivos de perfil, áreas de configuração de clientes e APIs de armazenamento. A coleta de endereços via Simple MAPI deixa sinais de interação com componentes antigos do Outlook que não costumam aparecer em processos sem relação com e-mail.
A propagação por SMB deve ser investigada por eventos de autenticação repetidos, falhas em sequência contra compartilhamentos, uso de contas locais em múltiplos hosts e criação de arquivos executáveis em caminhos de rede. A atividade de spam alimentada por listas do Outlook pode aparecer como aumento repentino de mensagens enviadas, destinatários externos incomuns e envio por contas que também apresentaram sinais de execução do dropper. Como a rotação de artefatos reduz a vida útil de hashes, a correlação de comportamento é mais valiosa do que listas estáticas extensas.
- Conexões de saída para IPs diretos com portas não usuais a partir de estáções de usuário logo após execução de arquivo suspeito.
- Processos coletando nome do computador, usuário, versão do sistema e lista de processos antes de tráfego cifrado para C2.
- Carregamento de DLLs com strings ofuscadas e resolução de funções por hash, seguido de acesso a perfis de navegador ou cliente de e-mail.
- Uso anormal de Simple MAPI por processo sem função legítima de e-mail.
- Tentativas repetidas de autenticação SMB contra múltiplos compartilhamentos internos.
- Padrões de envio de spam a partir de contatos extraídos localmente do Outlook.
A resposta deve começar pela contenção dos endpoints com sinais de infecção, porque a comunicação cifrada e o mecanismo de atualização permitem mudança rápida de artefatos. O host afetado deve ser isolado da rede, preservando memória e artefatos necessários para análise quando houver capacidade de DFIR. Em seguida, é necessário bloquear destinos C2 conhecidos de forma defangada nos controles internos, revisar conexões recentes por IP e porta, remover tarefas, arquivos e módulos associados ao dropper e validar que não houve expansão para outros sistemas por SMB.
A recuperação precisa incluir rotação de credenciais expostas. Como os módulos observados coletam senhas armazenadas em navegadores e clientes de e-mail, trocar apenas a senha do usuário interativo pode ser insuficiente se outras credenciais corporativas estiverem salvas localmente. Contas usadas em compartilhamentos, e-mail, VPN, aplicações internas e serviços acessados pelo navegador devem ser avaliadas conforme a telemetria do host. O endurecimento de SMB também é obrigatório: senhas comuns ou reutilizadas, permissões amplas de gravação e compartilhamentos acessíveis sem necessidade operacional ampliam a capacidade do worm de se mover pela LAN.
No controle preventivo, filtros de e-mail devem reduzir anexos e links maliciosos associados a spam, mas a proteção não pode depender exclusivamente da camada de mensagem. EDR, allowlisting, bloqueio de execução em diretórios de usuário, limitação de credenciais armazenadas e restrição de tráfego de saída ajudam a quebrar estágios diferentes da cadeia. Para análise contínua, regras de detecção devem priorizar comportamento: registro do host seguido de beaconing cifrado, atualização frequente de binários, módulos DLL com importação resolvida por hash, acesso a credenciais locais, uso de Simple MAPI e autenticação SMB repetitiva.
- Isolar hosts suspeitos antes de iniciar limpeza, preservando evidências de memória quando a investigação exigir.
- Bloquear comunicação de saída para IPs e portas C2 conhecidos, mantendo indicadores defangados em documentação interna.
- Rotacionar credenciais armazenadas no endpoint, incluindo e-mail, navegador, contas locais e acessos a compartilhamentos.
- Revisar permissões e autenticação de SMB, removendo senhas fracas, contas compartilhadas e gravação desnecessária.
- Aplicar detecções comportamentais para coleta de credenciais, uso anômalo de Simple MAPI e varredura de compartilhamentos.
- Reprocessar logs de e-mail e endpoint para identificar contatos usados em spam e máquinas que receberam o dropper em ondas anteriores.
0 Comentários