DanaBot passa a entregar ransomware em campanhas europeias

Bots associados ao DanaBot começaram a baixar um módulo Delphi chamado crypt, capaz de cifrar arquivos locais com extensão .non, criar persistência por tarefa agendada e enviar dados do host para infraestrutura de comando e controle.

Componente	DanaBot, trojan bancário distribuído por phishing, com downloader DLL de 32 ou 64 bits e módulo adicional de ransomware Delphi chamado crypt.
Vetor	E-mails de phishing com documentos ou links para droppers JavaScript, PowerShell ou VBS; em campanha australiana, o link levava a um arquivo hospedado no Google Docs que instalava o downloader no %TEMP% e o registrava como serviço.
Impacto	Em campanhas europeias, o módulo de ransomware enumera unidades locais, ignora o diretório Windows, cifra arquivos com AES128, adiciona a extensão .non e grava a nota HowToBackFiles.txt nos diretórios afetados.
Prioridade	Detectar hosts com downloader DanaBot, tráfego TCP customizado pela porta 443, criação anômala de serviço e tarefa agendada recorrente, além de conter endpoints antes da execução do módulo de cifragem.
Artefatos	Módulo D932613F6447F0C56744B1AD53230C62, nome operacional crypt, tarefa com string danificada relacionada a SysUtils, arquivos .non e nota HowToBackFiles.txt.
IoCs	Infraestrutura observada inclui o endereço defangado 95.179[.]186[.]57 e comunicação do ransomware com encrypter[.]webfoxsecurity[.]com.

Resumo técnico

DanaBot, conhecido inicialmente como trojan bancário distribuído por campanhas de phishing, foi observado ampliando seu papel dentro de cadeias de comprometimento. Além de sua atividade voltada a roubo bancário e entrega de outros componentes maliciosos, alguns bots associados a campanhas europeias passaram a receber um executável Delphi identificado como módulo de ransomware. Esse componente foi disponibilizado pelo servidor de comando e controle como um módulo chamado crypt e representa uma mudança operacional relevante: a infecção deixa de se limitar ao carregamento de plugins, configurações e módulos de apoio, passando a incluir cifragem direta de arquivos no endpoint comprometido.

A atividade mostra um ecossistema modular em evolução. O downloader do DanaBot comunica-se com servidores de comando e controle por protocolo TCP customizado sobre a porta 443, baixa plugins e arquivos de configuração, atualiza a si mesmo e executa o módulo principal. Após uma atualização de janeiro de 2019, o downloader absorveu funções antes associadas ao módulo principal, incluindo bypass de UAC, simulação de um serviço do Windows System Event Notification Service e comunicação protegida por AES256 no protocolo mais recente. Em abril de 2019, esse mecanismo modular também passou a entregar o ransomware em uma campanha europeia identificada pelo ID 7.

Fluxo técnico

A cadeia inicial segue o padrão já atribuído ao DanaBot: mensagens de phishing encaminham a vítima para documentos ou links que levam a droppers. Em uma campanha australiana identificada pelo ID 6, o link apontava para um arquivo hospedado no Google Docs que, ao ser baixado, revelou-se um script VBS. Esse dropper desempacotava a DLL do downloader no diretório %TEMP% e a registrava como serviço. A partir desse ponto, o downloader iniciava sua rotina, estabelecia comunicação com a infraestrutura de comando e controle, solicitava módulos e configurações e executava componentes adicionais conforme a campanha e os parâmetros codificados.

O ransomware entregue em campanhas europeias é uma variante associada ao nome NonRansomware. Após ser executado, ele cria um arquivo batch temporário e usa esse estágio para alterar configurações locais relacionadas a visibilidade de arquivos, limpeza de página de memória no desligamento, Windows Defender e WDigest. Os comandos específicos foram omitidos por segurança operacional; o efeito defensivamente relevante é a tentativa de reduzir proteção, ajustar exposição de arquivos ocultos e modificar comportamento de credenciais. Em seguida, o malware cria uma tarefa agendada para reexecutar o componente a cada 14 minutos. O nome da tarefa aparece corrompido por uma rotina simples de decodificação de strings com a chave Hello World!, aplicada de modo inadequado a uma string em texto claro.

A rotina de cifragem enumera unidades lógicas, percorre diretórios e exclui apenas a pasta Windows. Os demais arquivos encontrados são cifrados com AES128 e recebem a extensão .non. A senha usada no processo deriva da representação textual do número de série do volume do sistema, enquanto o identificador da vítima exibido na nota de resgate é gerado a partir dessa senha e de uma chave fixa. Esse desenho enfraquece o modelo de extorsão: como o identificador preserva relação matemática com o segredo usado para cifrar, a recuperação pode ser viável por força bruta do valor derivado do número de série, sem depender necessariamente do operador criminoso. A função de cifragem também guarda semelhança com código de teste da biblioteca DelphiEncryptionCompendium, com alteração no uso de hash Panama em vez de SHA1.

Superfície afetada

A superfície primária é composta por estáções Windows alcançadas por phishing e capazes de executar droppers JavaScript, PowerShell ou VBS. O contexto descreve campanhas em vários países e regiões, incluindo Europa, Austrália, Nova Zelândia, Estados Unidos e Canadá, com campanhas separadas por valores codificados no malware. A campanha australiana observada em abril de 2019 usou link para Google Docs como estágio de entrega, enquanto a entrega do ransomware foi associada a bots de campanha europeia. A exposição, portanto, não depende de exploração de vulnerabilidade de rede descrita no contexto, mas de execução de dropper e instalação bem-sucedida do downloader no host.

A superfície técnica inclui o diretório %TEMP%, o registro de serviço para o downloader, comunicação de saída por TCP na porta 443 com protocolo próprio, chamadas para obter módulos e configuração, criação de tarefa agendada recorrente e alterações de registro com impacto em proteção e visibilidade do sistema. A fase de ransomware afeta arquivos em unidades locais que não estejam dentro do diretório Windows, gravando uma nota de resgate em cada pasta onde há arquivos cifrados. O componente também coleta informações do host, incluindo versão do Windows, identificador de hardware, nome de usuário e indicador de privilégio administrativo, antes de enviar esses dados codificados em Base64 por requisição GET para um domínio de controle defangado.

• Endpoints Windows que receberam droppers por phishing e executaram scripts VBS, JavaScript ou PowerShell associados ao DanaBot.
• Hosts com DLL de downloader DanaBot em %TEMP%, registrada como serviço e comunicando-se por protocolo TCP customizado na porta 443.
• Sistemas com arquivos renomeados para extensão .non e presença recorrente da nota HowToBackFiles.txt em diretórios de usuário ou dados.
• Ambientes com saída para 95.179[.]186[.]57 ou encrypter[.]webfoxsecurity[.]com, ambos citados aqui em formato defangado.

Hunting e telemetria

A busca deve começar por sinais de execução inicial e persistência, não apenas por arquivos cifrados. Em endpoints, vale correlacionar chegada de e-mails com links externos, execução de scripts a partir de diretórios temporários, criação de DLLs no %TEMP%, registro de novos serviços com nomes que imitam componentes do Windows e processos que iniciam comunicação TCP na porta 443 sem usar padrões TLS esperados. Como o DanaBot usa protocolo próprio nessa porta, a presença de tráfego 443 não deve ser tratada automaticamente como navegação HTTPS legítima; diferenças de handshake, payload e destino podem separar a atividade de tráfego web comum.

Na etapa de ransomware, a telemetria deve procurar picos de enumeração de diretórios e escrita concorrente de arquivos com extensão .non, criação repetida de HowToBackFiles.txt e agendamento de tarefa com execução a cada 14 minutos. Alterações de registro voltadas a Windows Defender, WDigest, arquivos ocultos e comportamento de página de memória no desligamento também são sinais de preparação do ambiente. Em rede, o envio de uma string JSON codificada em Base64 por GET para domínio de controle defangado deve ser tratado como indicador de confirmação de execução do ransomware, especialmente quando combinado com coleta de versão do Windows, nome de usuário, identificador de hardware e flag de privilégio administrativo.

• Criação de serviço apontando para DLL recém-gravada em %TEMP% após execução de script vindo de link de phishing.
• Conexões TCP pela porta 443 para infraestrutura incomum, sem características normais de sessão HTTPS, em processos relacionados ao downloader.
• Criação de tarefa agendada recorrente a cada 14 minutos com nome corrompido ou relacionado a SysUtils.
• Sequência de escrita massiva de arquivos .non acompanhada de notas HowToBackFiles.txt em múltiplos diretórios.
• Alterações de registro relacionadas a Windows Defender, WDigest e exibição de arquivos ocultos feitas por processo não administrativo esperado.

Mitigação

A resposta deve priorizar contenção rápida do endpoint antes da conclusão da cifragem. Ao identificar sinais de DanaBot, isole a máquina da rede, preserve memória e artefatos de disco para análise, colete eventos de criação de serviço, execução de scripts, tarefas agendadas e conexões de saída e, em seguida, remova persistências associadas ao downloader e ao ransomware. Como a cadeia depende de phishing e execução de dropper, controles de e-mail, bloqueio de scripts de origem não confiável, política de execução restrita e inspeção de links externos reduzem a probabilidade de instalação inicial. A revisão de permissões locais também é importante, porque o componente tenta alterar áreas sensíveis do sistema e pode se beneficiar de privilégios elevados.

Para recuperação, a prioridade deve ser restauração por backups íntegros e validação de que o downloader não continua ativo antes de recolocar o host em produção. A lógica de cifragem descrita tem fragilidades porque usa informação derivada do número de série do volume e um identificador de vítima calculado a partir desse valor; ainda assim, qualquer tentativa de decodificação deve ocorrer em cópias forenses, nunca diretamente no único conjunto de arquivos afetados. O pagamento de resgate não é uma medida técnica confiável, especialmente em um caso no qual o desenho criptográfico pode permitir recuperação defensiva por análise do identificador e dos arquivos cifrados. Após a contenção, bloqueie os indicadores defangados conhecidos, procure outros hosts com a mesma comunicação e revise credenciais de usuários afetados quando houver evidência de coleta ou alteração de WDigest.

• Isolar endpoints com sinais de DanaBot, preservar artefatos e interromper comunicação de saída antes de ações de limpeza.
• Bloquear ou monitorar comunicação com 95.179[.]186[.]57 e encrypter[.]webfoxsecurity[.]com, mantendo os indicadores em formato defangado nas ferramentas de documentação.
• Remover serviços, tarefas agendadas e arquivos temporários associados ao downloader e ao módulo crypt somente após coleta de evidências.
• Restaurar arquivos a partir de backups verificados ou trabalhar em cópias forenses quando houver tentativa autorizada de decodificação.
• Endurecer controles contra phishing, execução de scripts, criação de serviços por usuários comuns e alterações não autorizadas em Windows Defender e WDigest.