Framework modular foi observado em hosts já comprometidos para operar C2, proxy SOCKS, reconhecimento interno e plugins voltados a Linux, nuvem e evasão.
| Componente | VoidLink, framework modular usado como ferramenta pós-comprometimento, com implante em Zig, plugins em C e backend em Go. |
| Vetor | Instalação em hosts previamente comprometidos para disponibilizar C2, proxy SOCKS e capacidade de reconhecimento interno e externo. |
| Impacto | Acesso furtivo de longa duração, coleta de informações, movimentação lateral condicionada ao ambiente, anti-forense e adaptação contra EDR. |
| Prioridade | Investigar servidores Linux e ambientes de nuvem com sinais de C2, proxy SOCKS, varredura interna, módulos de núcleo anômalos e execução de plugins sob demanda. |
| Artefatos | Implante em ZigLang, plugins em C, backend em GoLang, módulos de núcleo, RBAC com papéis SuperAdmin, Operator e Viewer, e possível implante principal compilado para Windows com carregamento via DLL side-loading. |
UAT-9921 foi associado ao uso do VoidLink em campanhas direcionadas aos setores de tecnologia e serviços financeiros. O conjunto é descrito como uma estrutura modular de malware empregada depois que o adversário já obteve presença inicial no ambiente. A função central não é abrir a primeira porta de entrada, mas transformar sistemas comprometidos em pontos de comando, controle, varredura e operação persistente. Essa característica muda a prioridade defensiva: a investigação deve partir de sinais de pós-exploração, tráfego de C2, serviços proxy inesperados e execução de componentes especializados, e não apenas de vetores de entrega inicial.
O VoidLink combina um implante escrito em Zig, plugins escritos em C e um backend escrito em Go. Essa separação indica uma arquitetura desenhada para adaptação operacional, com plugins compilados sob demanda para diferentes distribuições Linux. As capacidades descritas incluem coleta de informações, movimentação lateral, mecanismos anti-forenses, detecção de soluções EDR e escolha dinâmica de estratégia de evasão. O conjunto também foi relacionado a ambientes Linux em nuvem, onde a persistência furtiva e a visibilidade incompleta sobre hosts, módulos de núcleo e tráfego leste-oeste podem ampliar o tempo de permanência do operador.
A atividade começa em uma fase posterior ao comprometimento inicial. Depois de obter acesso a servidores, o operador instala componentes do VoidLink para montar infraestrutura de C2 e operar a partir desses hosts. O mesmo ambiente comprometido pode servir como ponto de apoio para varreduras internas e externas, inclusive com uso de proxy SOCKS. Esse arranjo permite que a origem das conexões de reconhecimento pareça pertencer a um ativo legítimo da própria organização ou de uma infraestrutura já abusada, dificultando a separação entre administração normal, tráfego de aplicação e atividade de intrusão.
O uso de ferramentas abertas de varredura, como Fscan, aparece associado ao reconhecimento interno e à preparação de movimentação lateral. A presença dessas ferramentas em servidores que não exercem função de auditoria, inventário, pentest autorizado ou monitoramento de rede deve ser tratada como sinal relevante. O ponto crítico não é apenas a existência de uma varredura, mas o encadeamento entre host comprometido, proxy, C2 e execução de módulos específicos para explorar oportunidades no ambiente. A defesa deve correlacionar criação de processos, conexões incomuns, enumeração de serviços e autenticações laterais no mesmo intervalo temporal.
A compilação sob demanda de plugins é uma capacidade importante porque reduz a necessidade de manter todos os módulos prontos no servidor de C2. O operador pode receber um componente ajustado para a distribuição Linux encontrada, para uma base de dados específica ou para uma vulnerabilidade conhecida presente em um servidor interno. O contexto não confirma exploração de uma falha específica, portanto não há base para atribuir CVE, versão afetada ou zero-day. O impacto confirmado é a flexibilidade do framework para adaptar componentes ao ambiente já acessado, mantendo a operação em andamento enquanto novas ferramentas são preparadas.
O conjunto também apresenta RBAC com três níveis de função: SuperAdmin, Operator e Viewer. Esse desenho sugere controle operacional e auditoria interna do uso da plataforma, algo mais comum em ferramentas maduras ou em estruturas que separam desenvolvimento, supervisão e operação. O contexto também aponta sinais de acesso dos operadores a código-fonte de alguns módulos de núcleo e a ferramentas capazes de interagir com implantes sem depender sempre do C2, o que indica conhecimento interno dos protocolos de comunicação do VoidLink.
A superfície mais relevante envolve servidores Linux e ambientes de nuvem que já sofreram acesso não autorizado. O VoidLink foi descrito como voltado a acesso furtivo e prolongado nesses ambientes, com componentes capazes de interagir em nível de núcleo e com plugins adaptáveis ao sistema de destino. Organizações de tecnologia e serviços financeiros aparecem como alvos observados, o que aumenta a relevância para ambientes com grande quantidade de servidores expostos, workloads efêmeros, pipelines de implantação, bases de dados internas e tráfego leste-oeste intenso.
Há também menção a um implante principal compilado para Windows, com capacidade de carregar plugins por DLL side-loading. O contexto não confirma uma campanha ampla em Windows nem detalha versões, caminhos de arquivo ou nomes de DLL. Ainda assim, essa possibilidade amplia a triagem para ambientes híbridos: servidores Linux podem concentrar o C2 e os plugins de nuvem, enquanto hosts Windows exigem atenção a carregamento de bibliotecas fora do padrão e execução de binários que abusem da ordem de busca de DLLs.
- Servidores Linux comprometidos que passam a operar como ponto de C2, proxy SOCKS ou origem de varredura.
- Ambientes de nuvem com baixa visibilidade sobre módulos de núcleo, processos persistentes e tráfego interno entre workloads.
- Ativos de tecnologia e serviços financeiros onde servidores internos, bancos de dados e aplicações web podem ser enumerados após o acesso inicial.
- Estáções ou servidores Windows somente quando houver evidência local de carregamento suspeito de DLL e relação com a cadeia investigada.
A caça deve começar pela correlação de comportamento, não por um único indicador estático. O VoidLink é apresentado como modular e furtivo, com evasão adaptativa e possível uso de módulos de núcleo. Em servidores Linux, os times devem revisar processos persistentes sem dono operacional claro, conexões de saída para destinos raros, serviços de proxy não documentados, artefatos de compilação incomuns e mudanças recentes em módulos carregados. A investigação também deve procurar varreduras internas partindo de servidores que normalmente não executam descoberta de rede.
Em telemetria de rede, o foco deve estar em padrões compatíveis com C2 e proxy: conexões persistentes, túneis, picos de varredura, tentativa de conexão contra muitas portas internas e mudanças no perfil de tráfego de servidores que antes tinham função previsível. Em endpoint, a prioridade é identificar processos que enumeram rede, bancos de dados, arquivos sensíveis ou configurações de nuvem, além de tentativas de ocultação, remoção de logs ou interferência em agentes de segurança. Em nuvem, trilhas de auditoria devem ser analisadas junto com alterações em instâncias, grupos de segurança, identidades e acessos a segredos.
Como há divergência entre análises sobre a linha do tempo mais antiga da atividade e sobre vítimas associadas a setembro de 2025, a defesa não deve depender de uma data única para delimitar a busca. A abordagem mais robusta é consultar histórico disponível de eventos de rede, endpoint e identidade, priorizando mudanças de comportamento em servidores críticos. Quando a retenção for limitada, a triagem deve concentrar hosts expostos, servidores com autenticações laterais recentes e sistemas que tenham iniciado tráfego de varredura sem justificativa operacional.
- Conexões persistentes ou recorrentes de servidores Linux para destinos raros, especialmente quando acompanhadas de execução de processos desconhecidos.
- Serviços SOCKS, túneis ou proxies não aprovados executando em hosts que não têm função de intermediação de tráfego.
- Varredura interna ou externa originada de servidores de aplicação, banco de dados, build, automação ou nuvem sem janela de teste autorizada.
- Módulos de núcleo carregados recentemente, inconsistentes com a imagem base ou sem relação com drivers e agentes corporativos.
- Sinais de enumeração de EDR, encerramento de agentes, manipulação de logs ou comportamento anti-forense em hosts Linux.
- Eventos de DLL side-loading em Windows somente quando vinculados a binários suspeitos, diretórios incomuns ou execução fora do fluxo de software aprovado.
A resposta deve tratar o VoidLink como uma ameaça de pós-comprometimento com potencial de persistência, e não como um simples executável isolado. O primeiro passo é isolar hosts com sinais de C2, proxy SOCKS, varredura ou módulos de núcleo suspeitos, preservando memória, disco e logs antes de qualquer limpeza que destrua evidências. Em seguida, a equipe deve mapear quais credenciais, chaves de API, tokens de nuvem, contas de serviço e acessos laterais estiveram disponíveis no host afetado, porque o framework é descrito como capaz de apoiar coleta de informações e movimentação dentro do ambiente.
A contenção deve incluir bloqueio de tráfego de saída não essencial, revisão de rotas internas acessíveis a partir do host comprometido e remoção controlada de serviços de proxy ou C2 após coleta forense. Em nuvem, é necessário revisar permissões de identidades associadas a instâncias, workloads e pipelines, além de rotacionar segredos potencialmente expostos. Para Linux, a validação de integridade deve considerar módulos de núcleo, unidades de persistência, alterações em binários, tarefas agendadas e bibliotecas carregadas por processos críticos.
Depois da erradicação, a validação precisa demonstrar que não há mais varredura interna, conexões persistentes anômalas, plugins ativos ou contas usadas fora do padrão. Como o framework pode compilar componentes sob demanda, bloquear apenas um hash ou um nome de arquivo não é suficiente. Controles de egress, segmentação, inventário de serviços, baseline de módulos carregados, detecção de proxy não autorizado e alertas para ferramentas de varredura em servidores de produção oferecem cobertura mais estável contra variações do mesmo conjunto.
- Isolar hosts suspeitos e preservar evidências de memória, disco, processos, conexões e módulos antes da remoção.
- Rotacionar credenciais, tokens e chaves acessíveis a partir de servidores comprometidos, incluindo identidades de nuvem e contas de serviço.
- Bloquear e revisar tráfego de saída não documentado, túneis e proxies SOCKS fora da arquitetura aprovada.
- Comparar módulos de núcleo e serviços persistentes com imagens base confiáveis e inventário de configuração.
- Investigar varreduras internas a partir de servidores de produção e relacioná-las a autenticações laterais, acessos a banco de dados e mudanças de permissão.
- Reforçar segmentação, retenção de logs e alertas de comportamento para detectar novas compilações ou plugins que não compartilhem indicadores estáticos.
0 Comentários