UNC6201 explorou falha de dia zero no Dell RecoverPoint para comprometer ambientes VMware

A vulnerabilidade CVE-2026-22769 permite autenticação no Tomcat Manager com credenciais padrão embutidas, envio de arquivo WAR malicioso e execução de comandos como root no appliance.

Componente	Dell RecoverPoint for Virtual Machines com Apache Tomcat Manager exposto no appliance.
Vetor	Uso de credenciais padrão embutidas para o usuário admin em /home/kos/tomcat9/tomcat-users.xml, autenticação no Tomcat Manager e envio de WAR malicioso por /manager/text/deploy.
Impacto	Execução de comandos como root, implantação de web shell SLAYSTYLE, persistência com BRICKSTORM ou GRIMBOLT e movimentação lateral para infraestrutura VMware.
Prioridade	Aplicar a correção da Dell, investigar acessos a /manager, revisar artefatos Tomcat e validar integridade de scripts executados na inicialização.
Artefatos	/home/kos/auditlog/fapi_cl_audit_log.log, /var/lib/tomcat9, /var/cache/tomcat9/Catalina, /var/log/tomcat9/, /home/kos/kbox/src/installation/distribution/convert_hosts.sh.
IoCs	149.248.11.71, wss://149.248.11.71/rest/apisession, hashes SHA256 associados a GRIMBOLT, SLAYSTYLE e BRICKSTORM.
Atribuição	Atividade vinculada ao cluster UNC6201, descrito como suspeito de nexo com a China, com sobreposições técnicas com UNC5221, sem equivalência formal entre os grupos.

Resumo técnico

A vulnerabilidade CVE-2026-22769, avaliada com CVSSv3.1 10.0, afeta o Dell RecoverPoint for Virtual Machines por permitir que um invasor use credenciais padrão embutidas para o usuário admin no Apache Tomcat Manager instalado no appliance. A condição crítica é a presença dessas credenciais em /home/kos/tomcat9/tomcat-users.xml, combinada com acesso ao serviço de gerenciamento usado para implantar componentes do próprio RecoverPoint. Após autenticação, o operador malicioso consegue acionar o endpoint /manager/text/deploy, carregar um arquivo WAR preparado e obter execução de comandos com privilégio de root no sistema do appliance.

A exploração observada começou pelo menos em meados de 2024 e foi usada pelo cluster UNC6201 em operações de intrusão que envolveram persistência, movimentação lateral e implantação de malware. O vetor inicial de entrada nos ambientes comprometidos não foi confirmado; ainda assim, o padrão operacional do cluster inclui interesse por appliances de borda, como concentradores VPN, para abrir o primeiro ponto de presença. A vulnerabilidade no RecoverPoint aparece como etapa de consolidação e expansão dentro da rede, não apenas como falha isolada de um serviço web.

O conjunto de ferramentas identificado inclui a web shell SLAYSTYLE, o backdoor BRICKSTORM e um backdoor mais recente chamado GRIMBOLT. Em setembro de 2025, binários antigos de BRICKSTORM foram substituídos por GRIMBOLT em appliances comprometidos. GRIMBOLT foi escrito em C#, compilado com native ahead-of-time e empacotado com UPX, uma combinação que reduz dependências externas em equipamentos com recursos limitados e dificulta a análise estática por remover metadados típicos de amostras .NET baseadas em CIL.

Fluxo técnico

O fluxo de comprometimento do RecoverPoint começa com requisições ao Tomcat Manager usando o usuário admin. A falha não depende de exploração de corrupção de memória ou de cadeia complexa de bypass; o ponto central é a existência de credenciais padrão codificadas em arquivo de configuração. Com a autenticação aceita pelo Tomcat Manager, o invasor envia um arquivo WAR malicioso por PUT /manager/text/deploy?path=/&update=true. Esse tipo de envio é suficiente para criar ou atualizar uma aplicação web no contêiner Tomcat e, quando a carga contém uma web shell, passa a fornecer um caminho remoto de execução de comandos.

A web shell SLAYSTYLE opera como estágio de execução dentro do Tomcat. A partir dela, o operador consegue implantar payloads adicionais, executar comandos com privilégio elevado e preparar persistência fora do contexto puramente web. Nos appliances analisados, a persistência de BRICKSTORM e GRIMBOLT foi estabelecida por modificação do script legítimo /home/kos/kbox/src/installation/distribution/convert_hosts.sh, incluindo nele o caminho para o backdoor. Esse script é chamado na inicialização por rc.local, o que permite que o malware retorne após reinicialização do appliance sem depender de uma sessão web ativa.

GRIMBOLT fornece capacidade de shell remoto e usa o mesmo comando e controle associado a cargas anteriores de BRICKSTORM. A escolha por compilação native ahead-of-time muda a superfície de análise: em vez de entregar um artefato .NET com metadados CIL facilmente enumeráveis, o binário é transformado em código nativo no momento da compilação. Para defesa, isso reduz a utilidade de regras simples baseadas em estrutura .NET e aumenta a importância de análise de comportamento, hashing conhecido, busca por strings específicas e correlação com alterações de persistência no sistema de arquivos.

A atividade também se estendeu à infraestrutura VMware. Foram observadas portas de rede temporárias em máquinas virtuais existentes em hosts ESXi, descritas como Ghost NICs, usadas para pivoteamento discreto para redes internas e serviços SaaS das organizações afetadas. Em appliances vCenter comprometidos, comandos recuperados do Systemd Journal indicaram uso de iptables para Single Packet Authorization: tráfego inicial na porta 443 contendo uma sequência hexadecimal específica adicionava o IP de origem a uma lista, conexões subsequentes à porta 10443 eram aceitas e, por 300 segundos, o tráfego da porta 443 daquele IP era redirecionado silenciosamente para 10443.

Superfície afetada

A exposição principal está em implantações de Dell RecoverPoint for Virtual Machines que mantêm o Tomcat Manager acessível e ainda contêm as credenciais padrão embutidas para admin. O risco é maior quando o plano de gerenciamento do appliance pode ser alcançado por segmentos com baixa restrição, por redes de administração amplas ou por hosts já comprometidos dentro do ambiente. Como a execução resultante ocorre como root, a exploração bem-sucedida transforma o appliance de recuperação e replicação em ponto de persistência privilegiado, com potencial de observação e pivoteamento em infraestrutura crítica.

Ambientes VMware entram na superfície prática do ataque quando o appliance comprometido tem rotas, credenciais, integrações ou conectividade operacional com vCenter, ESXi e redes usadas por máquinas virtuais. A criação de portas de rede temporárias em VMs existentes dificulta a leitura visual do incidente porque a mudança pode parecer uma alteração administrativa comum se não houver trilha de aprovação, inventário de configuração e monitoramento de eventos no vCenter. O uso de iptables em vCenter ou appliances Linux também amplia o risco: a regra SPA cria uma janela temporária de acesso que não se comporta como um serviço exposto convencional.

A presença de SLAYSTYLE, BRICKSTORM ou GRIMBOLT em um RecoverPoint não deve ser tratada apenas como infecção de endpoint. O appliance participa de fluxos de disponibilidade e recuperação, pode ter visibilidade sobre topologias sensíveis e costuma ser administrado por equipes com permissões elevadas. A resposta precisa considerar credenciais administrativas usadas no appliance, caminhos de rede permitidos a partir dele, integrações com VMware, acesso a SaaS corporativo por pivoteamento e possibilidade de que o ponto inicial de entrada tenha sido outro appliance de borda.

• Dell RecoverPoint for Virtual Machines com Tomcat Manager e credenciais admin embutidas em /home/kos/tomcat9/tomcat-users.xml.
• Appliances com requisições a /manager ou envio de WAR por /manager/text/deploy antes de atividade de C2.
• Infraestrutura VMware com vCenter, ESXi e máquinas virtuais que receberam portas de rede temporárias sem mudança autorizada.
• Sistemas Linux de gerenciamento com regras iptables envolvendo portas 443 e 10443, listas recent e redirecionamento por nat.

Hunting e telemetria

A investigação deve começar pelos logs do Tomcat Manager no RecoverPoint. O arquivo /home/kos/auditlog/fapi_cl_audit_log.log deve ser revisado para qualquer acesso a /manager, especialmente operações PUT contra /manager/text/deploy?path=/&update=true. Em um appliance de produção, esse endpoint não deve aparecer fora de janelas administrativas muito bem explicadas. Quando houver caminho de upload indicado por MAL_PATH, ele deve ser correlacionado com o conteúdo em /var/lib/tomcat9, artefatos compilados em /var/cache/tomcat9/Catalina e registros do Tomcat em /var/log/tomcat9/.

Nos logs de aplicação, eventos org.apache.catalina.startup.HostConfig.deployWAR e mensagens relacionadas a exceções geradas por aplicações recém-implantadas são sinais de alta prioridade. A presença de um WAR desconhecido, arquivos .jsp fora do padrão do produto ou conteúdo compilado sem correspondência com um pacote legítimo do RecoverPoint deve acionar coleta forense. A revisão do script /home/kos/kbox/src/installation/distribution/convert_hosts.sh é essencial porque a persistência observada depende de inserir o caminho do backdoor nesse script, executado na inicialização por rc.local.

Para detecção de malware, os indicadores disponíveis incluem os SHA256 24a11a26a2586f4fba7bfe89df2e21a0809ad85069e442da98c37c4add369a0c e dfb37247d12351ef9708cb6631ce2d7017897503657c6b882a711c0da8a9a591 para GRIMBOLT, 92fb4ad6dee9362d0596fda7bbcfe1ba353f812ea801d1870e37bfc6376e624a para SLAYSTYLE, e hashes associados a BRICKSTORM, incluindo 2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df. Em rede, conexões para 149.248.11.71 e wss://149.248.11.71/rest/apisession devem ser tratadas como indicadores de possível C2, com atenção ao contexto temporal e ao host de origem.

No VMware, a caça deve correlacionar mudanças de configuração em VMs, criação de interfaces ou portas temporárias, eventos de vCenter e alterações que não tenham chamado de mudança. Em appliances vCenter, revisar o Systemd Journal por comandos iptables contendo --dport 443, --dport 10443, -m recent, --seconds 300, REDIRECT --to-ports 10443 e criação de cadeia IPT ajuda a localizar o mecanismo de SPA. Esse padrão é importante porque reduz ruído de rede visível: o acesso só é liberado após o pacote inicial com conteúdo específico, e a janela de redirecionamento expira rapidamente.

• Requisições a /manager em /home/kos/auditlog/fapi_cl_audit_log.log, principalmente PUT /manager/text/deploy?path=/&update=true.
• Arquivos WAR inesperados em /var/lib/tomcat9 e artefatos compilados em /var/cache/tomcat9/Catalina.
• Eventos org.apache.catalina.startup.HostConfig.deployWAR em logs Catalina e exceções de aplicações desconhecidas em logs localhost.
• Alteração em /home/kos/kbox/src/installation/distribution/convert_hosts.sh com inclusão de caminho para binário não reconhecido.
• Conexões para 149.248.11.71 ou endpoint wss://149.248.11.71/rest/apisession a partir de appliances ou hosts de gerenciamento.
• Comandos iptables com -m string, -m recent, portas 443 e 10443, cadeia IPT e redirecionamento temporário por nat.
• Criação de interfaces ou portas de rede temporárias em VMs executadas em ESXi sem vínculo com mudança aprovada.

Mitigação

A primeira ação defensiva é aplicar a remediação disponibilizada pela Dell para CVE-2026-22769 em todos os appliances Dell RecoverPoint for Virtual Machines afetados. A correção deve ser acompanhada por restrição de acesso ao Tomcat Manager e ao plano de gerenciamento do appliance, permitindo conexões apenas a partir de estáções administrativas controladas ou redes de administração fortemente segmentadas. Como houve exploração desde pelo menos meados de 2024, corrigir sem investigar não é suficiente: appliances expostos devem ser tratados como potencialmente comprometidos até que logs, sistema de arquivos e persistência sejam validados.

A contenção deve incluir isolamento temporário do appliance suspeito, preservação de imagem de disco quando viável, coleta de logs do Tomcat e revisão de todos os arquivos implantados recentemente. Arquivos WAR desconhecidos devem ser removidos somente após coleta de evidência, hashing e registro da linha do tempo. Scripts chamados na inicialização, especialmente /home/kos/kbox/src/installation/distribution/convert_hosts.sh, devem ser comparados com uma versão íntegra conhecida. Qualquer referência a binários fora do padrão do produto precisa ser investigada como persistência, e a limpeza deve considerar rc.local e demais pontos de execução no boot.

Em ambientes VMware, as equipes devem revisar inventário de redes virtuais, portas recentes, NICs de VMs e eventos administrativos para localizar pivoteamento. Regras iptables em appliances vCenter e sistemas Linux de gerenciamento devem ser exportadas e comparadas com baseline; comandos que criam redirecionamento condicional entre 443 e 10443 exigem resposta imediata, pois podem mascarar acesso remoto controlado por SPA. Também é necessário revisar credenciais que o appliance RecoverPoint poderia acessar, incluindo contas administrativas, integrações de vCenter e credenciais armazenadas em automações.

Após erradicação, a validação deve combinar testes de integridade, varredura por IoCs, regras YARA para GRIMBOLT e SLAYSTYLE, inspeção de conexões históricas e rotação de credenciais usadas em RecoverPoint, vCenter, ESXi e redes administrativas. A segmentação deve impedir que um appliance de recuperação tenha caminho amplo para SaaS corporativo ou redes internas sem necessidade operacional clara. Onde houver telemetria de proxy, DNS, EDR, NDR e logs de identidade, a linha do tempo deve cobrir o período anterior à primeira requisição a /manager, pois o vetor inicial nos incidentes observados não foi confirmado.

• Aplicar a correção da Dell para CVE-2026-22769 e verificar que o Tomcat Manager não está acessível fora da rede administrativa necessária.
• Coletar e preservar logs de /home/kos/auditlog/fapi_cl_audit_log.log, /var/log/tomcat9/, artefatos em /var/lib/tomcat9 e cache em /var/cache/tomcat9/Catalina.
• Comparar /home/kos/kbox/src/installation/distribution/convert_hosts.sh com baseline íntegro e remover referências não autorizadas a backdoors após coleta forense.
• Caçar GRIMBOLT, BRICKSTORM e SLAYSTYLE por SHA256, regras YARA e comportamento de shell remoto em appliances Linux.
• Revisar vCenter e ESXi para portas de rede temporárias, NICs não aprovadas, comandos iptables suspeitos e redirecionamentos de 443 para 10443.
• Rotacionar credenciais administrativas e tokens usados pelo RecoverPoint, vCenter, ESXi e automações conectadas ao plano de gerenciamento.
• Reconstruir appliances comprometidos quando a integridade do sistema não puder ser demonstrada por evidência confiável.