O grupo por trás do ransomware Warlock continua invadindo organizações por falhas do SharePoint Server instalado em servidor próprio, a mesma tática que o tornou conhecido em 2025. Segundo relatório da equipe de Threat Hunter da Symantec e Carbon Black, nos dois meses anteriores à publicação o grupo atacou pelo menos quatro organizações: uma concessionária de água, uma operadora de telecomunicações, um órgão de governo regional e uma universidade. Todas ficam em países de língua portuguesa e espanhola, na Europa, na África e na América Latina.

Resumo para quem decide

• Quem é afetado: organizações que mantêm o SharePoint Server em servidor próprio (on-premises). O SharePoint Online, do Microsoft 365, não é afetado pelas falhas do conjunto ToolShell, segundo a Microsoft.
• O que acontece: o invasor entra pelo SharePoint, rouba as chaves criptográficas do ambiente (machine keys do ASP.NET), passa a executar código no servidor, desliga antivírus e EDR e distribui o ransomware pelo compartilhamento SYSVOL do Active Directory.
• Quanto tempo leva: no caso descrito pela Symantec, a primeira atividade maliciosa foi em 22 de julho de 2026 e o ransomware foi implantado na madrugada de 31 de julho. Foram nove dias em que a intrusão podia ter sido detectada.
• Qual o alcance: a ferramenta que desliga a proteção rodou em pelo menos 40 máquinas em cerca de duas horas, e o ransomware foi registrado em pelo menos 33.
• O que fazer agora: confirmar que todos os servidores SharePoint estão com as atualizações mais recentes, conferir se a AMSI está ativa, procurar sinais de invasão e só então trocar as machine keys. Aplicar a correção sem trocar as chaves não expulsa quem já as roubou.

Quem é o Warlock e por que o alvo recente importa

O Warlock surgiu em junho de 2025 e ganhou destaque semanas depois, quando seus operadores foram vistos explorando como zero-day as falhas do SharePoint Server conhecidas como ToolShell (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 e CVE-2025-53771). A Symantec atribui o ransomware a um grupo ligado à China que ela chama de Longlegs, também rastreado como Storm-2603 e Gold Salem, e o associa a atividades mais antigas conhecidas como CL-CRI-1040, CamoFei e ChamelGang. No início de 2026 o mesmo grupo foi ligado ao comprometimento da SmarterTools, por meio de uma instância do SmarterMail sem correção.

Mais de um ano depois, o caminho de entrada segue o mesmo. A Symantec avalia que as falhas do ToolShell provavelmente continuam no arsenal do grupo, ao lado de falhas mais novas do SharePoint sobre as quais a CISA, agência de cibersegurança dos Estados Unidos, alertou em julho de 2026. O relatório não aponta qual falha específica foi usada em cada invasão.

O recorte geográfico chama atenção. Campanhas anteriores do Warlock atingiram organizações em um conjunto mais amplo de países, entre eles Estados Unidos, Brasil, Índia, Rússia, Taiwan e Japão. A concentração recente em países lusófonos e hispânicos, segundo os pesquisadores, sugere ou um padrão oportunista, guiado por servidores SharePoint expostos e vulneráveis, ou um direcionamento deliberado. Em qualquer das duas hipóteses, uma organização brasileira com SharePoint próprio exposto à internet está no perfil das vítimas.

Como o ataque começa: falhas do SharePoint e roubo das machine keys

O grupo obtém o acesso inicial explorando múltiplas vulnerabilidades em instalações próprias do SharePoint Server. Uma vez dentro, grava um web shell no diretório LAYOUTS de várias versões do SharePoint de uma só vez, para que ele funcione qualquer que seja a versão instalada. No caso analisado, o arquivo se chamava layout2sp.aspx.

A função desse web shell é coletar as machine keys do ASP.NET usadas pelo farm do SharePoint. Com elas, os invasores forjam uma carga __VIEWSTATE com assinatura válida e conseguem execução remota de código dentro do application pool do SharePoint. É por isso que a troca das chaves é parte obrigatória da resposta: quem tem as chaves antigas continua conseguindo assinar cargas válidas mesmo depois de a falha original ser corrigida.

A linha do tempo do incidente contra um operador de infraestrutura crítica mostra o ritmo da operação:

• 22 de julho: instalação do web shell em um servidor SharePoint, via PowerShell.
• 24 de julho: comandos de reconhecimento (net user /domain, whoami, nltest /domain_trusts) em um segundo servidor SharePoint, remoção de arquivos usados na fase inicial e implantação de pares de executável e DLL para carregamento lateral (DLL sideloading).
• 27 de julho: requisição de saída para um subdomínio de oastify.com, domínio do serviço Burp Collaborator, com o nome de domínio da vítima embutido. Para os pesquisadores, é o comportamento de uma ferramenta de varredura confirmando que aquele servidor executou o código injetado.
• 28 de julho: novo teste do web shell pela manhã e, à tarde, início da cadeia de exploração propriamente dita. O servidor carrega o assembly System.Workflow.ComponentModel, que fornece o mecanismo de desserialização usado para transformar a carga forjada em execução de código. Em seguida, o msiexec baixa três pacotes de dois serviços públicos de hospedagem, catbox.moe e wasabisys.com, em um intervalo de noventa minutos.
• 28 e 29 de julho: a intrusão sai dos servidores SharePoint e alcança o restante do domínio.
• 31 de julho, madrugada: desligamento da proteção e implantação do ransomware.

Movimento pela rede: ferramentas legítimas e túnel do VS Code

Para se espalhar, o grupo evita malware próprio sempre que pode. Uma conta de domínio chamada SPSEPRDSetup foi adicionada repetidamente ao grupo local de Administradores em três outras máquinas. O nome provavelmente é um disfarce, já que o SharePoint costuma criar contas de serviço com prefixos parecidos.

Em uma das máquinas, os invasores instalaram como serviço o recurso de túnel do Visual Studio Code, a partir do binário code-insiders.exe colocado na pasta debug do Windows. Como o binário é assinado pela Microsoft e o túnel trafega pela infraestrutura da própria Microsoft, o acesso remoto se confunde com o tráfego esperado de estações de desenvolvedores e administradores.

Na mesma noite, um dos servidores SharePoint executou o NetExec (nxc.exe), sucessor de código aberto do CrackMapExec, usado para enumerar o Active Directory, testar credenciais em massa e executar comandos remotamente. Credenciais válidas são o que sustenta essa fase, tema que tratamos em Infostealers: como credenciais corporativas vazam e alimentam ataques cibernéticos.

Proteção desligada e ransomware distribuído pelo SYSVOL

Na fase final, os invasores distribuíram uma ferramenta para encerrar antivírus e EDR (a.exe) usando um comando de uma linha que mapeava um compartilhamento de rede em um IP interno, copiava as ferramentas e as executava. A execução foi registrada em pelo menos 40 máquinas em cerca de duas horas, o que indica distribuição por quase todo o ambiente.

A técnica é a de trazer um driver vulnerável (BYOVD, de bring your own vulnerable driver): um driver legítimo e assinado, mas com falha, é usado para encerrar processos protegidos de segurança no nível do kernel. Neste incidente específico a Symantec não identificou qual driver foi usado. Em outros ataques recentes, o grupo usou o K7RKScan (CVE-2025-1055), o mesmo já explorado por operadores do ransomware DragonForce. Desligar a detecção antes de criptografar é prática antiga, que já aparecia em casos como o do DeepBlueMagic.

O ransomware apareceu quase imediatamente depois que a proteção caiu em cada máquina. Dois binários, run.exe e rune.exe, e uma nota de resgate chamada “how to restore your files.txt” foram registrados em pelo menos 33 máquinas.

O ponto mais relevante para quem administra Active Directory é o meio de distribuição. Os binários foram colocados em uma pasta de scripts dentro do SYSVOL, o diretório presente em todo controlador de domínio que guarda modelos de política de grupo e scripts, é replicado automaticamente entre os controladores e pode ser lido por todo o domínio. A partir dali, cada máquina copiava e executava os arquivos. Em três máquinas, a Symantec registrou o serviço de replicação DFSR (dfsrs.exe) entregando os binários, confirmação de que a replicação normal do domínio fez o trabalho de distribuição. O invasor não precisou montar um mecanismo próprio: usou o que o Active Directory já oferece.

O que fazer: correção, troca de chaves e detecção

1. Corrigir. Para o ToolShell, a Microsoft publicou em julho de 2025 as atualizações KB5002768 (Subscription Edition), KB5002754 (SharePoint Server 2019) e KB5002760 (SharePoint Server 2016), e informa que a falha pode ser explorada sem autenticação. Para as falhas mais recentes, o alerta da CISA de 14 de julho de 2026, atualizado pela última vez em 26 de agosto, lista seis CVEs com exploração ativa: CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644, CVE-2026-50522 e CVE-2026-55040. A orientação é aplicar as atualizações mais recentes da Microsoft e conferir se a instalação terminou com sucesso.

2. Reduzir a exposição. A CISA recomenda não expor servidores SharePoint diretamente à internet. Quando a exposição for inevitável, exigir um proxy reverso de camada 7, ou controle equivalente, que imponha autenticação e inspecione as requisições. Também recomenda bloquear o acesso externo à Administração Central do SharePoint.

3. Ativar a AMSI. Tanto a Microsoft quanto a CISA pedem que a integração com a Antimalware Scan Interface esteja ativa em cada aplicação web do SharePoint, com antivírus compatível no servidor.

4. Caçar antes de trocar as chaves. A Microsoft considera crítico trocar as machine keys do ASP.NET e reiniciar o IIS em todos os servidores SharePoint depois de aplicar as atualizações. A CISA acrescenta a ordem certa: antes da troca, procurar e remover artefatos da invasão, incluindo coletores de chaves, para que as chaves novas não sejam roubadas de novo.

5. Monitorar os sinais deste caso:

• Arquivos .aspx criados ou alterados no diretório LAYOUTS fora de janelas de manutenção.
• O processo do SharePoint no IIS iniciando cmd.exe, powershell.exe ou msiexec, em especial com download de pacotes de serviços públicos de hospedagem.
• net user /domain, whoami e nltest /domain_trusts partindo de servidores SharePoint.
• Contas com nome parecido com o de contas de serviço do SharePoint sendo adicionadas ao grupo local de Administradores.
• code-insiders.exe instalado como serviço, sobretudo fora de estações de desenvolvimento.
• Execução de nxc.exe e carregamento de drivers de kernel não aprovados, como o K7RKScan.
• Executáveis gravados no SYSVOL fora do processo normal de gestão de políticas de grupo.

Como o desfecho é a criptografia de dezenas de máquinas em poucas horas, cópias de segurança isoladas da rede de produção continuam sendo a última linha de defesa, assunto de Segurança de backups e sua importância na mitigação de ataques ransomware.

Perguntas frequentes

O Warlock usa falhas novas ou antigas do SharePoint?
Provavelmente as duas. A Symantec avalia que as falhas do ToolShell, de 2025, continuam no arsenal do grupo, junto com falhas mais novas cobertas pelo alerta da CISA de julho de 2026. O relatório não diz qual delas foi usada em cada caso.

O SharePoint Online é afetado?
Não pelas falhas do ToolShell. A Microsoft informa que elas atingem apenas o SharePoint Server instalado em servidor próprio. O alerta da CISA de 2026 também trata de instâncias on-premises.

Aplicar a atualização resolve?
Não sozinha. Se as machine keys já foram roubadas, o invasor continua conseguindo executar código. É preciso procurar sinais de invasão, trocar as chaves e reiniciar o IIS.

Onde encontrar os indicadores de comprometimento?
O relatório da Symantec e Carbon Black traz os hashes do ransomware, das DLLs maliciosas, da ferramenta que desliga a proteção e do driver vulnerável. As orientações de correção estão no guia da Microsoft para o ToolShell e no alerta da CISA. A cobertura original é do The Hacker News.