Warlock: a defesa precisa enxergar o caminho entre SharePoint, identidade e endpoint

A BleepingComputer relata ataques associados ao ransomware Warlock contra uma companhia de água, uma operadora de telecomunicações, um órgão regional de governo e uma universidade, com acesso inicial principalmente por SharePoint instalado localmente.[3] A notícia descreve uma cadeia de intrusão, não apenas um executável que cifra arquivos.

O que muda para quem desenvolve

Nos ataques analisados, um driver assinado e vulnerável, K7RKScan, associado à CVE-2025-1055, foi utilizado para desativar antivírus e EDR, numa técnica conhecida como BYOVD.[3] Em uma das intrusões, a ferramenta de desativação alcançou pelo menos 40 máquinas em cerca de duas horas, e o ransomware foi executado em pelo menos 33.[3]

A carga foi preparada no SYSVOL, e os pesquisadores observaram a execução do ransomware quase imediatamente após a proteção ser desligada em cada host.[3] Minha leitura é que monitorar só o último estágio deixa pouco espaço para reagir. Alterações na proteção, distribuição de arquivos e mudanças no acesso remoto precisam formar uma mesma investigação.

O invasor também instalou Visual Studio Code Insiders como serviço para usar sua capacidade de túnel, enquanto NetExec apareceu em reconhecimento, tentativas de credenciais e execução remota.[3] Isso recomenda avaliar comportamento e contexto de implantação, não apenas o nome conhecido de uma ferramenta.

Como aplicar

Desenhe o caminho entre o serviço exposto, as identidades que ele utiliza e os ativos que essas identidades podem modificar. Priorize os pontos em que um comprometimento local ganha alcance sobre outras máquinas.

Faça um exercício defensivo com eventos sintéticos, sem ransomware e sem desativar proteção real. Injete no ambiente de teste três sinais separados: uma alteração simulada de configuração do endpoint, um arquivo benigno numa área de distribuição e a criação autorizada de um serviço remoto de demonstração. O objetivo é verificar se a operação relaciona os sinais e identifica o responsável pela resposta.

Defina evidências de aceite: tempo até o alerta, contexto disponível para investigação e procedimento para conter a identidade envolvida. Revise também quem pode alterar áreas de distribuição e quais túneis são autorizados. Um inventário sem responsáveis não resolve a ambiguidade durante um incidente.

Cuidados e limites

A matéria aponta concentração recente em países de língua portuguesa e espanhola, mas não identifica todos os países e organizações atingidos.[3] Não é base para afirmar que uma empresa brasileira específica foi comprometida.

A atribuição do grupo à China é apresentada pelos pesquisadores, não como uma observação independente desta análise.[3] Tampouco se deve bloquear toda ferramenta de desenvolvimento como resposta automática. O trade-off é distinguir usos autorizados de persistência inesperada, com políticas, exceções documentadas e telemetria suficiente para revisar a decisão.

Fonte

[3] Fonte: BleepingComputer