Zero-days no SolarWinds Web Help Desk abrem caminho para ataques DCSync e comprometimento total de domínios
Vulnerabilidades recentemente descobertas no SolarWinds Web Help Desk (WHD) podem ter sido exploradas como zero-days para garantir acesso inicial a ambientes corporativos desde dezembro de 2025, segundo análise técnica da Microsoft. A partir desse ponto de entrada, operadores de ameaça conseguiram escalar privilégios, se manter no ambiente por longos períodos e, em casos específicos, chegar a ataques do tipo DCSync – um dos cenários mais críticos para domínio Windows.
Em vez de explorarem múltiplas superfícies, os atacantes focaram em instâncias do WHD expostas à internet. Uma vez comprometidos esses servidores, eles passaram a executar comandos PowerShell remotamente e a baixar cargas adicionais, abrindo a porta para toda a cadeia de ataque subsequente.
Cadeia de vulnerabilidades no SolarWinds WHD
Os sistemas atacados estavam vulneráveis simultaneamente a três falhas graves:
– CVE-2025-40551 – corrigida em janeiro de 2026, relacionada à funcionalidade de Ajax Proxy e permitindo execução remota de código (RCE) não autenticada por meio de desserialização insegura.
– CVE-2025-40536 – também corrigida em janeiro de 2026, afetando o mesmo produto.
– CVE-2025-26399 – falha corrigida anteriormente, em setembro de 2025.
Como todos os ambientes analisados estavam expostos ao conjunto completo de falhas, a Microsoft não conseguiu determinar com precisão qual CVE foi usado como vetor inicial. Ainda assim, o destaque vai para o CVE-2025-40551, já incluído na lista de vulnerabilidades exploradas ativamente (KEV) de agências de segurança, por permitir que um invasor remoto execute código arbitrário sem qualquer autenticação prévia.
A raiz do problema está no Ajax Proxy do SolarWinds WHD, que deveria apenas intermediar requisições, mas acabou se tornando um canal para execução de código. Em mãos maliciosas, esse componente é capaz de transformar uma simples aplicação de help desk em um ponto de entrada completo para o ambiente de TI.
Persistência: uso de ferramentas legítimas para fins maliciosos
Após a obtenção do acesso inicial, os atacantes não se limitaram a explorar scripts ou malwares tradicionais. Em vez disso, adotaram um padrão cada vez mais comum em operações avançadas: o uso de ferramentas legítimas de administração para permanecerem “misturados” ao tráfego normal da rede.
Entre as principais técnicas observadas:
– Implantação do ManageEngine, uma ferramenta legítima de gerenciamento remoto, usada aqui como canal de acesso persistente.
– Configuração de acesso reverso via SSH e RDP, garantindo que os atacantes pudessem voltar ao ambiente mesmo após mudanças superficiais.
– Criação de uma tarefa agendada para iniciar, durante o boot do sistema, uma máquina virtual QEMU com privilégios de SYSTEM.
Esse uso de uma VM QEMU é particularmente sofisticado: ao executar atividades maliciosas dentro de um ambiente virtualizado, os atacantes conseguem:
– Evasão de algumas soluções de segurança que monitoram mais intensamente o sistema host.
– Criação de canais de encaminhamento de portas (port forwarding) a partir da VM, ocultando movimentos laterais e conexões suspeitas.
– Manutenção de um “ambiente de operação” relativamente isolado, reduzindo rastros diretos no sistema principal.
Movimento lateral e roubo de credenciais
Em determinados casos, os operadores de ameaça foram além da persistência e passaram a buscar credenciais com privilégios elevados. Uma das técnicas empregadas foi o sideloading de DLL, na qual uma biblioteca maliciosa é carregada por um executável legítimo, explorando a forma como o Windows resolve dependências.
Com isso, eles conseguiram acessar a memória do processo LSASS (Local Security Authority Subsystem Service) – componente do Windows responsável pelo armazenamento temporário de credenciais e hashes de senha em uso. Ao despejar e analisar o conteúdo dessa memória, os invasores obtiveram:
– Senhas em texto claro (quando disponíveis).
– Hashes de senhas de contas de usuário e de serviço.
– Tokens e artefatos de autenticação reaproveitáveis.
Na sequência, essas credenciais de alto privilégio permitiram que os atacantes executassem um ataque do tipo DCSync.
O que é o DCSync e por que ele é tão perigoso
O DCSync é uma técnica que imita o comportamento de um controlador de domínio legítimo em um ambiente Active Directory. Em resumo, o invasor se “passa” por um controlador de domínio e solicita ao controlador verdadeiro a replicação de dados sensíveis – incluindo hashes de senha de todas as contas do domínio, até mesmo da conta de administrador de domínio (Domain Admin) e da conta KRBTGT.
Com o DCSync bem-sucedido, o atacante pode:
– Obter material suficiente para forjar tickets Kerberos.
– Escalar privilégios para controle completo sobre o domínio.
– Criar backdoors persistentes e quase invisíveis.
– Comprometer, de forma sistêmica, todos os usuários, grupos e políticas de segurança do ambiente Windows.
É o tipo de ataque que, uma vez concluído, transforma um incidente pontual (uma aplicação vulnerável exposta) em um comprometimento total de identidade e infraestrutura.
Padrão de ataque: uma única aplicação exposta, impacto em todo o ambiente
A análise da Microsoft reforça um padrão preocupante: basta um único sistema exposto e desatualizado ― neste caso, o SolarWinds WHD ― para que, combinando:
– vulnerabilidades zero-day ou recentemente divulgadas,
– técnicas de “living-off-the-land” (uso de ferramentas nativas do sistema, como PowerShell, WMI, RDP),
– e ferramentas administrativas legítimas (ManageEngine, RMM, SSH, QEMU),
os invasores consigam penetrar profundamente no ambiente corporativo. Em outras palavras, um erro de gestão de patch ou de exposição de serviço pode abrir caminho para o comprometimento completo do domínio Active Directory, sem que necessariamente sejam usados malwares ruidosos e facilmente detectáveis.
Recomendações imediatas para organizações que utilizam SolarWinds WHD
Diante desse cenário, as recomendações ganham caráter de urgência:
1. Aplicar todos os patches do SolarWinds WHD
– Atualizar para as versões que corrigem os CVEs 2025-40551, 2025-40536 e 2025-26399.
– Verificar se não existem instâncias “esquecidas” expostas à internet ou em DMZ sem monitoramento adequado.
2. Remover ou revisar ferramentas RMM não autorizadas
– Inventariar todas as soluções de gerenciamento remoto presentes no ambiente.
– Desinstalar aplicações desconhecidas ou não aprovadas.
– Adotar controle rigoroso de quem pode instalar e operar essas ferramentas.
3. Rotacionar credenciais críticas
– Alterar senhas de contas de domínio privilegiadas (Domain Admins, Enterprise Admins).
– Redefinir senhas de contas de serviço associadas a aplicações em servidores comprometidos.
– Avaliar o uso de autenticação multifator e redução de privilégios permanentes.
4. Isolar imediatamente hosts suspeitos ou comprometidos
– Remover do ambiente de produção máquinas que apresentem indicadores de comprometimento.
– Realizar análise forense para identificar ações do atacante, movimento lateral e eventual DCSync.
– Validar a integridade de controladores de domínio, GPOs e contas administrativas.
Fortalecendo o Active Directory contra DCSync
Mesmo após a correção das vulnerabilidades iniciais, é fundamental revisar a postura de segurança do Active Directory para mitigar o risco de DCSync:
– Restringir contas com permissão de replicação
Verificar quais contas têm direito de executar operações de replicação de diretório e reduzir esse conjunto ao mínimo estritamente necessário.
– Monitorar eventos relacionados à replicação
Implementar alertas para operações suspeitas de replicação ou para acessos incomuns a funções do controlador de domínio.
– Segmentar e limitar privilégios
Evitar o uso cotidiano de contas de administrador de domínio; preferir modelos de administração just-in-time e just-enough-admin, limitando janelas de privilégio elevado.
– Endurecer a proteção do LSASS
Habilitar recursos como Credential Guard, quando possível, e monitorar acesso a LSASS para detectar tentativas de dumping de credenciais.
Living-off-the-land: o inimigo escondido nas ferramentas do dia a dia
Um aspecto central desse caso é o uso de técnicas de living-off-the-land, isto é, explorar ferramentas já presentes no sistema em vez de introduzir binários maliciosos óbvios. PowerShell, WMI, RDP, SSH, agendadores de tarefas e até ambientes de virtualização como QEMU passam a fazer parte do arsenal do atacante.
Isso reforça a necessidade de:
– Monitorar comportamento, não apenas assinaturas de malware.
– Estabelecer políticas de uso restrito e registrado para ferramentas de administração.
– Implementar logs detalhados e correlação de eventos para identificar atividades suspeitas que, isoladamente, poderiam parecer legítimas.
Exposição de aplicações e gestão de superfície de ataque
Aplicações como um Web Help Desk frequentemente são vistas como “menos críticas” do que um sistema financeiro ou um core de negócios. Porém, quando expostas à internet, passam a ser portas de entrada valiosas. Boas práticas incluem:
– Colocar aplicações administrativas atrás de VPN ou bastion hosts, em vez de expô-las diretamente.
– Utilizar WAF e controles adicionais de acesso para sistemas web sensíveis.
– Manter um inventário contínuo da superfície de ataque externa: quais portas, serviços e aplicações estão acessíveis de fora da organização.
Cloud e SaaS: o mito do backup automático
Outro ponto que se conecta diretamente à gravidade de incidentes como esse é a falsa sensação de segurança em relação a Cloud e SaaS. Muitas organizações acreditam que, por estarem utilizando serviços em nuvem, seus dados estão automaticamente protegidos e recuperáveis em qualquer situação.
Na prática:
– Provedores de SaaS normalmente garantem disponibilidade do serviço, não necessariamente um backup completo e granular dos dados para todos os cenários (exclusão acidental, ataque de ransomware, mau uso interno).
– Em um incidente envolvendo comprometimento de identidade ou DCSync, um invasor com privilégios elevados pode afetar tanto recursos on-premises quanto integrações com serviços em nuvem, apagando ou corrompendo dados em massa.
Por isso, é fundamental:
– Adotar estratégias de backup independentes também para dados em SaaS (e-mail, colaboração, CRM, etc.).
– Definir janelas de retenção que façam sentido para o negócio.
– Validar periodicamente processos de restauração – backup que nunca é testado não pode ser considerado confiável.
Construindo resiliência: prevenção, detecção e resposta
O caso do SolarWinds WHD mostra que segurança não se resume a “instalar um patch” ou “comprar uma ferramenta”. É um ciclo contínuo que envolve:
– Prevenção
– Gestão rigorosa de vulnerabilidades e atualizações.
– Revisão periódica da superfície exposta e dos perfis de acesso.
– Detecção
– Monitoramento avançado de logs.
– Uso de soluções de detecção e resposta (EDR/XDR) com foco em comportamento.
– Alertas para ações típicas de DCSync, dumping de credenciais e uso anômalo de ferramentas de administração.
– Resposta
– Planos de incident response bem definidos, com responsabilidades claras.
– Procedimentos de isolamento de máquinas, rotação de credenciais e comunicação interna.
– Pós-incidente: lições aprendidas, melhoria de controles e atualização de políticas.
Ao final, a principal mensagem é direta: uma vulnerabilidade ignorada em uma aplicação aparentemente secundária pode se transformar em um incidente de domínio completo. Corrigir rapidamente, monitorar com profundidade e tratar identidade como o novo perímetro são passos indispensáveis para reduzir o impacto de ataques cada vez mais sofisticados como os que exploraram os zero-days do SolarWinds Web Help Desk.