Zero-days no SolarWinds viram porta de entrada para DCSync e comprometimento total de domínio
Vulnerabilidades graves no SolarWinds Web Help Desk (WHD) vêm sendo apontadas por especialistas como possível vetor de acesso inicial em ataques observados em dezembro de 2025, segundo análise da Microsoft. Evidências indicam que criminosos exploraram falhas como zero-day para invadir instâncias expostas da solução e, a partir delas, construir uma cadeia de ataque que terminou em um poderoso DCSync contra controladores de domínio.
Em vez de focar em malware sofisticado, os atacantes se apoiaram em uma combinação perigosa: uma aplicação exposta à internet, falhas não corrigidas e ferramentas administrativas legítimas. A partir do WHD comprometido, foi possível executar PowerShell remotamente e baixar novas cargas maliciosas, abrindo espaço para persistência, movimento lateral e, por fim, o roubo de credenciais de alto privilégio.
Cadeia de vulnerabilidades no SolarWinds WHD
Os ambientes afetados estavam vulneráveis simultaneamente a três falhas distintas:
– CVE-2025-40551
– CVE-2025-40536 – ambas corrigidas em janeiro de 2026
– CVE-2025-26399 – corrigida anteriormente, em setembro de 2025
A Microsoft destaca que não foi possível determinar qual vulnerabilidade específica foi usada como ponto inicial, justamente porque os sistemas analisados estavam expostos a todo o conjunto no mesmo período. Esse cenário ilustra um problema recorrente: quando várias falhas críticas coexistem em um único serviço voltado para a internet, o esforço para atribuir com precisão qual CVE foi explorado se torna secundário diante da conclusão mais importante — a superfície de ataque estava aberta por completo.
Ajax Proxy no centro do problema
As vulnerabilidades mais recentes têm origem na funcionalidade Ajax Proxy do SolarWinds WHD. Entre elas, ganha destaque o CVE-2025-40551, que permite execução remota de código (RCE) sem autenticação por meio de um problema de desserialização. Essa falha já foi classificada como crítica e incluída na lista de vulnerabilidades exploradas ativamente (KEV) mantida por autoridades de cibersegurança.
Na prática, o Ajax Proxy acabou funcionando como um túnel não intencional para o ambiente interno: ao explorar o bug, o invasor conseguia enviar comandos que eram processados pelo servidor como se fossem legítimos. É essa capacidade de executar código de forma remota e sem credenciais que transforma o WHD em uma porta de entrada extremamente valiosa para agentes maliciosos.
Do acesso inicial à persistência: uso de ferramentas legítimas
Uma vez obtido o acesso inicial, os operadores da campanha não se limitaram a instalar backdoors óbvios. Em vez disso, adotaram uma abordagem “discreta” e altamente eficaz, baseada em ferramentas legítimas já amplamente usadas em ambientes corporativos:
– Implantação da solução de gerenciamento remoto ManageEngine
– Configuração de acesso reverso via SSH e RDP
– Automação de mecanismos de persistência por meio de tarefas agendadas
Ao utilizar um software de gerenciamento remoto reconhecido no mercado, os atacantes conseguem se misturar ao tráfego e aos processos esperados pela equipe de TI. Em muitos casos, o uso de RMM (Remote Monitoring and Management) não autorizado é confundido com administração de rotina, atrasando a detecção e facilitando o controle persistente sobre os servidores.
QEMU como técnica de evasão e encaminhamento de portas
Um dos pontos mais inusitados dessa campanha foi o uso de uma máquina virtual QEMU para garantir persistência e evasão. Os invasores configuraram uma tarefa agendada para iniciar a VM QEMU com privilégios de Sistema assim que o host fosse ligado ou reiniciado.
Esse ambiente virtualizado servia como:
– Camada adicional de ocultação de atividades maliciosas
– Plataforma isolada para encaminhamento de portas
– Mecanismo para manter o controle mesmo diante de eventuais tentativas parciais de limpeza do sistema hospedeiro
Ao rodar ferramentas e túneis de rede dentro da VM, os criminosos reduzem a chance de que soluções de segurança focadas no host principal identifiquem comportamentos suspeitos, já que parte do tráfego e dos processos passa a ocorrer dentro desse “sistema dentro do sistema”.
Sideloading de DLL e acesso ao LSASS
Em alguns dos incidentes analisados, os atacantes recorreram ao DLL sideloading para atingir um objetivo delicado: acessar a memória do LSASS (Local Security Authority Subsystem Service) e extrair credenciais.
O sideloading de DLL consiste em colocar uma biblioteca maliciosa em um caminho em que um executável legítimo espera encontrar uma DLL de confiança. O sistema carrega a DLL equivocada, permitindo que código malicioso seja executado com o mesmo nível de privilégio do processo confiável. Uma vez dentro do contexto adequado, o invasor pode:
– Ler a memória do LSASS
– Extrair hashes e credenciais em texto claro, quando disponíveis
– Elevar privilégios e movimentar-se lateralmente com contas de maior valor
Esse passo é crucial para a fase seguinte do ataque, em que credenciais de alto privilégio são usadas para interagir com o controlador de domínio de maneira abusiva.
DCSync: o golpe final contra o Active Directory
Com credenciais privilegiadas em mãos — por exemplo, de uma conta com permissões equivalentes a Domain Admin ou com direito de replicação — os invasores executaram um ataque DCSync.
O DCSync é uma técnica que abusa dos próprios mecanismos de replicação do Active Directory. Em vez de quebrar senhas à força ou explorar contas isoladas, o atacante se faz passar por um controlador de domínio e solicita ao serviço de diretório:
– Hashes de senha de contas específicas
– Dados sensíveis associados a identidades privilegiadas
– Informações suficientes para assumir o controle de todo o domínio
Em outras palavras, o DCSync converte o próprio controlador de domínio em uma fonte de dados para o invasor. Ao obter esses hashes, torna-se possível:
– Elevar permanentemente o nível de acesso
– Criar backdoors duradouros no ambiente
– Tomar o controle total da infraestrutura de autenticação da organização
Esse é o ponto em que um incidente passa de “comprometimento de servidor” para comprometimento completo de domínio, com impacto potencial em todas as contas, sistemas e serviços que dependem do AD.
Padrão de ataque: uma aplicação exposta, um domínio inteiro em risco
A Microsoft ressalta que esse caso não é isolado, mas reflete um padrão de ameaça cada vez mais comum: uma única aplicação exposta e desatualizada pode se tornar o gatilho para a quebra de todo o ambiente corporativo.
Alguns elementos-chave desse padrão:
– Exploração de falhas críticas em serviços voltados para a internet
– Uso intensivo de técnicas “living-off-the-land” (ferramentas nativas e administrativas)
– Adoção de softwares legítimos, como RMM e utilitários de gerenciamento, para se manter discreto
– Elevação escalonada de privilégios até atingir o Active Directory e executar DCSync
Esse modelo reduz a necessidade de malware sofisticado e, ao mesmo tempo, torna a detecção mais difícil, já que grande parte das ações ocorre com ferramentas e protocolos comuns na rotina de TI.
Recomendações imediatas para quem usa SolarWinds WHD
Diante da criticidade do cenário, as recomendações são diretas e urgentes para organizações que utilizam o SolarWinds Web Help Desk:
1. Aplicar imediatamente todos os patches fornecidos pela SolarWinds
– Em especial os relacionados aos CVEs 2025-40551, 2025-40536 e 2025-26399
– Verificar se a instância do WHD está exposta à internet e, se possível, restringir acesso apenas via VPN ou redes confiáveis
2. Remover ou auditar aplicativos de gerenciamento remoto (RMM)
– Identificar soluções como ManageEngine e outras ferramentas similares
– Confirmar se a instalação foi autorizada e documentada pela área de TI
– Eliminar qualquer RMM não autorizado e revisar logs de acesso associados
3. Rotacionar credenciais críticas
– Trocar senhas de contas administrativas locais e de domínio
– Revogar chaves, tokens e credenciais possivelmente expostos
– Revisar grupos privilegiados no AD, como Domain Admins e Enterprise Admins
4. Isolar hosts potencialmente comprometidos
– Retirar servidores suspeitos da rede para análise forense
– Evitar simplesmente “formatar e reinstalar” sem antes entender o alcance do ataque
– Verificar se houve uso de QEMU, tarefas agendadas suspeitas e túneis SSH/RDP atípicos
5. Monitorar indícios de DCSync e acessos ao LSASS
– Ativar auditoria detalhada em controladores de domínio
– Buscar por eventos relacionados a replicação indevida
– Revisar alertas de ferramentas de EDR ou SIEM que apontem acesso ao LSASS ou uso fora do padrão de utilitários de diretório
Fortalecendo o AD contra DCSync
Embora o caso em questão tenha se iniciado no SolarWinds WHD, a etapa de DCSync expõe uma fragilidade recorrente: configurações permissivas em controllers de domínio. Algumas ações estruturais ajudam a reduzir esse risco:
– Restringir quem pode realizar operações de replicação no AD
– Minimizar o número de contas com privilégios de Domain Admin ou similares
– Implementar o princípio de menor privilégio e separar contas de administração de rotina das contas de alto privilégio
– Utilizar estações de trabalho administrativas dedicadas para tarefas sensíveis, reduzindo o risco de comprometimento dessas credenciais
Ao tratar o AD como um ativo crítico de segurança — e não apenas como “mais um serviço de infraestrutura” — a organização reduz drasticamente o impacto potencial de campanhas que miram o DCSync como objetivo final.
Vigilância contínua e revisão de superfície de ataque
O episódio envolvendo o SolarWinds WHD reforça uma mensagem importante para CISOs e equipes de segurança: não basta ter ferramentas; é preciso reduzir a superfície exposta e manter um ciclo disciplinado de correção de vulnerabilidades.
Medidas práticas incluem:
– Mapeamento regular de todos os serviços publicados na internet
– Classificação de risco baseada na criticidade dos sistemas e no tipo de dados que eles tocam
– Priorização de patches para aplicações que têm acesso a redes internas ou integrações sensíveis
– Testes de intrusão e simulações de ataque para avaliar se uma falha explorável em um único ponto é capaz de levar a um comprometimento de domínio
Quando uma aplicação de suporte ou help desk vira a porta de entrada para um DCSync, fica claro que fronteira e núcleo da rede estão, na prática, mais próximos do que se imaginava.
Conclusão: de zero-day a domínio comprometido
A campanha que explorou vulnerabilidades no SolarWinds Web Help Desk mostra como um zero-day em uma única aplicação pode ser suficiente para desencadear um ataque de alto impacto, culminando em controle quase absoluto sobre o ambiente corporativo.
O encadeamento é claro:
1. Exploração de falhas no Ajax Proxy do WHD
2. Execução remota de código e uso de PowerShell para baixar cargas adicionais
3. Implantação de ferramentas de gerenciamento remoto e infraestrutura de persistência (incluindo QEMU)
4. roubo de credenciais via LSASS, com técnicas como DLL sideloading
5. Execução de DCSync para obter dados de senha do controlador de domínio
Para reduzir a probabilidade de repetir esse roteiro, organizações precisam combinar correção rápida de vulnerabilidades, endurecimento do Active Directory, restrição de ferramentas de administração remota e monitoramento contínuo de atividades anômalas. Em um cenário em que uma única aplicação exposta pode derrubar todo o castelo, a disciplina operacional e a visão integrada de risco tornam-se elementos indispensáveis da estratégia de segurança.