Conjunto modular operado em dispositivos Linux de borda inspeciona pacotes, intercepta atualizações e redireciona tráfego para entregar ShadowPad e DarkNimbus.
| Componente | Estrutura DKnife, composta por sete implantes Linux para inspeção profunda de pacotes, manipulação de tráfego, proxy reverso, encaminhamento, atualização e comunicação com C2. |
| Vetor | Execução em roteadores e dispositivos de borda, com interceptação de tráfego, sequestro de DNS, substituição de downloads binários e manipulação de solicitações de atualização de aplicativos Android. |
| Impacto | Monitoramento de atividade do usuário, coleta de credenciais em fluxos POP3/IMAP terminados por proxy TLS, redirecionamentos maliciosos e entrega de ShadowPad e DarkNimbus em cenários AitM. |
| Prioridade | Inventariar dispositivos de borda Linux, revisar alterações de DNS e proxy, inspecionar telemetria de atualizações de aplicativos e validar integridade de downloads entregues por redes sob suspeita. |
| Artefatos | Componentes citados incluem dknife.bin, postapi.bin, sslmm.bin, mmdown.bin, yitiji.bin, remote.bin e dkupdate.bin. |
| Alvo observado | A telemetria descrita aponta foco principal em usuários de língua chinesa, com phishing para serviços de e-mail chineses, módulos ligados a WeChat e referências de código a domínios de mídia chinesa. |
DKnife é uma estrutura adversary-in-the-middle voltada a roteadores e dispositivos de borda baseados em Linux. A atividade é atribuída a atores com nexo chinês e teria operação desde pelo menos 2019. O conjunto não se limita a observar pacotes: ele combina inspeção profunda, manipulação de tráfego em linha, encerramento de conexões TLS em contexto de proxy, redirecionamento por DNS e substituição de downloads para introduzir malware em PCs, dispositivos móveis e equipamentos de Internet das Coisas que dependem da rede comprometida.
A arquitetura descrita é modular e gira em torno de sete componentes Linux. O módulo dknife.bin concentra a inspeção de pacotes, o relato de atividade de usuários, o sequestro de downloads binários e o sequestro de DNS. Outros módulos repassam dados a servidores de comando e controle, mantêm componentes ativos, criam túneis de comunicação, encaminham pacotes por interfaces de rede virtuais e baixam APKs usados na operação. Essa composição indica uma capacidade de ataque posicionada no caminho do tráfego, em vez de uma infecção tradicional limitada a um único endpoint.
O recorte de alvos observado aponta principalmente para usuários de língua chinesa. Essa avaliação decorre de páginas de phishing para serviços chineses de e-mail, módulos voltados à extração de dados de aplicativos móveis populares na China, como WeChat, e referências de código relacionadas a domínios de mídia chinesa. Há, porém, uma limitação importante: a configuração que sustenta essa leitura foi obtida de um único servidor de comando e controle, o que deixa em aberto a possibilidade de outros servidores conterem regras voltadas a regiões ou setores diferentes.
O fluxo de ataque começa pela presença da estrutura em roteadores ou dispositivos de borda Linux, onde o operador ganha uma posição privilegiada para observar e modificar tráfego de múltiplos clientes. Diferentemente de um malware instalado apenas no computador da vítima, uma estrutura AitM nesse ponto da rede consegue interferir em requisições de atualização, downloads de binários, resolução de nomes e sessões de aplicativos sem depender de interação repetida do usuário final. A vantagem operacional está na capacidade de transformar infraestrutura de passagem em mecanismo de entrega, coleta e vigilância.
O módulo sslmm.bin funciona como proxy reverso modificado a partir de HAProxy. No cenário descrito, ele apresenta um certificado TLS próprio aos clientes, termina conexões POP3 e IMAP, descriptografa o fluxo nesse ponto intermediário e inspeciona o conteúdo em texto claro para extrair nomes de usuário e senhas. As credenciais extraídas são marcadas com a cadeia PASSWORD, encaminhadas ao postapi.bin e então transmitidas a servidores remotos de comando e controle. O efeito defensivo a observar é a quebra anômala da confiança esperada entre cliente e serviço de e-mail, especialmente quando certificados, rotas ou pontos de terminação não correspondem ao comportamento normal da organização.
A entrega de malware ocorre por manipulação de downloads e atualizações. Para Android, a estrutura intercepta solicitações de manifestos de atualização associadas a aplicativos de notícias, vídeo, edição de imagem, comércio eletrônico, táxi, jogos e streaming adulto, substituindo o caminho esperado por APKs controlados pelo operador. Para Windows e outros binários, regras pré-configuradas permitem trocar downloads legítimos por cargas maliciosas. O contexto descreve entrega de ShadowPad por carregamento lateral de DLL, seguida de carregamento de DarkNimbus. Também há interação com variantes Android e Windows de DarkNimbus por meio do fornecimento de C2 atualizado.
A estrutura ainda interfere em comunicações de produtos de antivírus e gerenciamento de PC, incluindo serviços associados a 360 Total Security e Tencent. Essa capacidade não deve ser tratada como uma simples tentativa de evasão local; em um ponto de borda, a interferência pode alterar a visibilidade que ferramentas de segurança têm da rede, de atualizações e de canais de comunicação. O operador também monitora atividade em tempo real e agrupa eventos por categorias amplas, como mensagens, chamadas de voz e vídeo, textos enviados, imagens recebidas, leitura de artigos em aplicativos, compras, notícias, mapas, vídeo, jogos, relacionamento, transporte e checagem de e-mail.
A superfície principal é a infraestrutura de borda que processa tráfego de usuários. Roteadores, gateways e dispositivos Linux posicionados entre clientes e serviços externos são pontos críticos porque permitem observação e alteração em escala. Quando esse tipo de equipamento é comprometido, a investigação não pode se limitar ao endpoint que recebeu uma carga maliciosa; é necessário validar o caminho de rede, as respostas DNS, os certificados apresentados aos clientes e a origem real dos arquivos baixados.
Os clientes expostos incluem PCs, dispositivos móveis e IoT que utilizam o roteador ou gateway manipulado. A diversidade de alvos decorre do nível de rede onde DKnife opera. Um telefone Android pode ser impactado por uma atualização adulterada de aplicativo; um sistema Windows pode receber um binário substituído que aciona carregamento lateral de DLL; um usuário de e-mail pode ter credenciais extraídas durante POP3 ou IMAP terminados pelo proxy; e uma aplicação de mensagens ou mídia pode ter atividade categorizada e reportada ao C2.
- Roteadores e dispositivos de borda Linux com tráfego de usuários passando em linha.
- Clientes Android que solicitam manifestos de atualização de aplicativos cobertos pelas regras de interceptação.
- Sistemas Windows e outros ambientes que baixam binários por caminhos monitorados pela estrutura.
- Fluxos POP3 e IMAP suscetíveis à terminação TLS indevida pelo componente
sslmm.bin. - Ambientes nos quais respostas DNS para domínios relacionados a JD.com possam ser alteradas em IPv4 ou IPv6.
A investigação deve começar pela camada de rede, com foco em mudanças de comportamento em roteadores e gateways. Processos Linux desconhecidos com nomes alinhados aos módulos citados, interfaces TAP inesperadas, túneis P2P incomuns, conexões persistentes para C2 não reconhecido e alterações de resolução DNS são sinais compatíveis com uma estrutura em linha. Como o contexto não fornece endereços, domínios ou hashes confiáveis, a abordagem mais útil é comportamental: comparar a configuração atual do equipamento com uma linha de base conhecida e correlacionar anomalias com eventos de endpoint.
Em endpoints, a defesa deve procurar discrepâncias entre o arquivo esperado e o arquivo entregue em downloads de software, principalmente quando houver carregamento lateral de DLL antes de execução de ShadowPad ou DarkNimbus. Para Android, proxies, gateways seguros e telemetria de MDM podem indicar manifestos de atualização divergentes, APKs obtidos de origem não usual ou padrões repetidos de substituição em categorias específicas de aplicativos. Em identidade e e-mail, certificados inesperados em POP3/IMAP, falhas de validação TLS e autenticações subsequentes após sessões mediadas por rede suspeita merecem prioridade.
A telemetria de DNS também é central. O contexto descreve sequestro de DNS em IPv4 e IPv6 para redirecionamentos relacionados a domínios de JD.com. A defesa deve validar se respostas internas ou de borda diferem de resoluções externas confiáveis, se há servidores DNS não autorizados no caminho e se dispositivos de borda alteram respostas sem política explícita. Logs de proxy, firewall e resolução recursiva ajudam a distinguir falhas de configuração de manipulação intencional.
- Processos ou binários em roteadores com nomes
dknife.bin,postapi.bin,sslmm.bin,mmdown.bin,yitiji.bin,remote.binoudkupdate.bin. - Criação de interface TAP ou ponte de tráfego sem mudança operacional aprovada.
- Conexões de roteadores para C2 não reconhecido, inclusive canais P2P persistentes.
- Certificados TLS inesperados em sessões POP3/IMAP e alterações de rota para serviços de e-mail.
- Downloads ou atualizações cujo hash interno diverge do artefato esperado pelo fornecedor legítimo.
- Respostas DNS divergentes em IPv4 ou IPv6 para domínios de comércio eletrônico citados no contexto.
A resposta deve priorizar o controle da infraestrutura de borda. Dispositivos suspeitos precisam ser isolados de forma planejada, com preservação de imagem, configuração, lista de processos, conexões ativas, tabela de rotas, regras de firewall, configuração DNS e artefatos em disco. Reinicializar ou substituir equipamentos sem coleta mínima pode eliminar evidência volátil sobre interfaces virtuais, túneis e processos em execução. Depois da coleta, a organização deve restaurar firmware e configuração a partir de fontes confiáveis, validar integridade do sistema e remover credenciais administrativas que possam ter sido expostas.
No lado dos clientes, é necessário tratar downloads e atualizações ocorridos por trás do roteador comprometido como material não confiável. Endpoints que receberam binários no período de exposição devem passar por verificação de integridade, análise de eventos de carregamento de DLL, busca por ShadowPad e DarkNimbus, e revisão de conexões de saída. Dispositivos Android expostos a atualizações adulteradas devem ser avaliados por inventário de aplicativos, origem de instalação, certificados de assinatura e comunicação de rede posterior. Para contas de e-mail acessadas via POP3 ou IMAP durante o período suspeito, a rotação de senha deve ser acompanhada de revogação de sessões e revisão de regras de encaminhamento ou acesso incomum.
A prevenção passa por endurecimento de dispositivos de borda, segmentação de administração, inventário contínuo e monitoramento de comportamento. Roteadores e gateways devem ter acesso administrativo restrito, atualização controlada, serviços desnecessários desativados e logs encaminhados para armazenamento externo. A validação de TLS nos clientes, o uso de canais de atualização assinados, a verificação de integridade de binários e a comparação de DNS por resolvers confiáveis reduzem a janela de manipulação em linha. Em ambientes de alto risco, a inspeção de tráfego de saída dos próprios roteadores deve receber o mesmo rigor aplicado a servidores críticos.
- Isolar e preservar evidências de roteadores e gateways Linux sob suspeita antes de reconstruir o equipamento.
- Restaurar firmware e configuração a partir de imagens confiáveis, com rotação de credenciais administrativas.
- Revisar downloads, atualizações Android e execuções Windows ocorridas durante o período de exposição.
- Rotacionar credenciais de e-mail usadas em POP3/IMAP quando houver indício de terminação TLS indevida.
- Comparar respostas DNS internas com resolvers confiáveis, incluindo IPv4 e IPv6.
- Adicionar monitoramento para interfaces TAP, túneis P2P, processos desconhecidos e conexões de C2 originadas da borda.
0 Comentários