Threat Lab Quarterly: agosto de 2026

Localizando SPNs obsoletos e fantasmas antes dos atacantes

Por Huy Kha

Introdução

Nos últimos anos, ataques ao Active Directory que abusam dos Service Principal Names (SPNs) aumentaram. Começou com Kerberoasting, mas as técnicas ficaram mais criativas desde então. Ataques Ghost SPN podem permitir escalada de privilégios ao reivindicar alvos de serviço que ninguém mais usa. Mais recentemente, ataques de colisão Unicode de SPN permitem que qualquer usuário autenticado com permissões write-SPN também escale privilégios, usando apenas um SPN visualmente idêntico, mas tecnicamente diferente.

Há também um problema mais silencioso que não recebe muita atenção, que é a higiene básica de segurança. Na Netwrix, vemos o mesmo padrão surgir repetidamente, independentemente do tamanho da organização. Contas de computador permanecem habilitadas no Active Directory muito tempo depois que a máquina associada foi desativada. Contas de serviço mantêm SPNs que ainda apontam para hosts que não existem mais. Ninguém volta para limpar isso, então a conta simplesmente fica lá, ainda ativa, ainda vulnerável ao Kerberoasting, e ninguém presta atenção.

Encontrar SPNs ocultos no(s) seu(s) domínio(s)

Nossa equipe de pesquisa em segurança decidiu criar algo que facilitasse isso para profissionais de TI e administradores: um script PowerShell chamado Find-StealthSPNs que caça SPNs ocultos em contas de computador e usuário, para que você possa revisar os resultados e decidir o que realmente precisa ser limpo.

O script é executado em duas etapas principais. A primeira analisa todas as contas de computador na floresta. Como toda máquina ingressada no domínio registra pelo menos um SPN por padrão, essa etapa verifica se o próprio nome do host do computador ainda é resolvido no DNS e se algum dos seus SPNs aponta para hosts que não existem mais. Chamamos isso de ghost SPN, um SPN que ainda está em uma conta, tecnicamente válido, mas apontando para nada real. Também detecta contas de computador pré-criadas no AD, mas que nunca foram realmente ingressadas, pois geralmente acabam sem nenhum SPN, permanecendo lá indefinidamente sem que ninguém perceba.

Verificamos isso deliberadamente via DNS em vez de um ping ICMP. Alguns administradores usam ping para ter uma ideia rápida se um host por trás de um SPN ainda está ativo, mas ICMP é frequentemente bloqueado por firewalls e filtragem baseada no host na maioria dos ambientes, então um ping falho não diz muito. Um registro DNS ausente é um sinal mais confiável de que ninguém espera mais que esse nome de host exista, independentemente de a máquina responder a um ping.

A segunda verificação analisa as contas de usuário, especificamente aquelas que possuem SPNs, pois essa é a configuração clássica para uma conta de serviço. Para cada SPN encontrado, verifica duas coisas: se ainda existe uma conta de computador correspondente no AD e se esse nome de host ainda é resolvido no DNS. Se nenhuma das duas for verdadeira, esse é um sinal claro de que o SPN é um peso morto. A conta ainda está ativa, o SPN ainda está registrado e continua tão explorável via Kerberoasting como sempre, exceto que agora não há nada legítimo dependendo dele.

Além disso, o script também verifica colisões Unicode de SPN, o tipo de ataque que mencionamos antes, onde um SPN criado pode parecer visualmente real, mas ser um valor completamente diferente por baixo. Ele sinaliza qualquer SPN com caracteres ocultos ou semelhantes e cruza referências de cada SPN na floresta para detectar casos em que duas contas parecem ter o mesmo SPN. Isso pode gerar falsos positivos, então sempre verifique duas vezes primeiro.

Tudo funciona usando apenas ADSI e DirectorySearcher, portanto não há dependência do módulo ActiveDirectory PowerShell, e funciona em todos os domínios da floresta, não apenas naquele de onde você o executa.

Uma nota rápida sobre resolução DNS: Este script verifica o DNS usando o resolvedor configurado na máquina de onde é executado. Para resultados (mais) precisos, execute-o a partir de um controlador de domínio em vez de uma estação de trabalho, pois os DCs já estão configurados para resolver todos os domínios no seu ambiente. Executá-lo em uma máquina com configurações DNS incomuns ou restritas pode gerar resultados falsos de MISSING_DNS para registros que realmente existem.

Conclusão

No fim das contas, estamos tentando ajudar as organizações a reduzir sua superfície de ataque limpando contas obsoletas que ninguém monitora mais. Cada ghost SPN, cada conta de computador habilitada vinculada a uma máquina que já não existe, cada conta de serviço ainda apontando para um host que não existe mais, é mais uma coisa no Active Directory que não deveria estar lá. Nenhum deles exige um atacante sofisticado. Basta que alguém perceba antes de você.

---

O ângulo de segurança de identidade do DEF CON 34

Por Darryl Baker

DEF CON 34 e Black Hat USA 2026 produziram três pesquisas distintas que apontam todas para a infraestrutura de identity. Veja o que cada uma anunciou e o que isso significa para quem gerencia programas de identity e AD.

CloudBasher: shells gratuitos na nuvem transformados em infraestrutura de atacantes

Jenko Hwong e Chris Ryan apresentaram o CloudBasher, um kit de ferramentas open-source construído por engenharia reversa das REST APIs privadas e sessões WebSocket por trás dos recursos gratuitos de cloud shell na AWS, Azure e GCP. O kit de ferramentas estará disponível publicamente no GitHub, junto com uma análise de 2026 sobre padrões de má configuração na nuvem extraídos de dados de violações.

A pesquisa revelou algumas descobertas específicas que valem a pena destacar para as equipes de Identity Management.

• Uma identidade AWS comprometida pode assumir um papel e iniciar um grande número de ambientes CloudShell.
• As sessões de terminal WebSocket permanecem ativas após o token de acesso subjacente ser revogado, portanto revogar uma credencial não encerra necessariamente uma sessão ativa.
• As contas de consumidor M365 e Gmail recebem acesso padrão ao CloudShell, o que estende a superfície de ataque relevante para contas pessoais, não apenas para as empresariais.

Uma vez estabelecida a sessão, o kit de ferramentas permanece no diretório $HOME (que sobrevive a reinicializações), pode bloquear o usuário legítimo de usar sudo em sua própria sessão e instala um framework C2.

Por que isso importa: se seu programa de identity trata a revogação de token como equivalente à terminação da sessão, esta pesquisa diz que essa suposição deve ser testada, não assumida. Também vale confirmar se suas políticas de acesso e monitoramento do CloudShell detectariam a criação anômala de sessões.

GhostJacking: agentes de codificação de IA agindo conforme instruções ocultas em logs 

Barak Sternberg, Nevo Poran e Ron Bobrov da Tenet Security apresentaram GhostJacking, uma técnica para sequestrar agentes de codificação de IA plantando instruções dentro de logs que o agente deve ler, como alertas WAF, relatórios de erro e saída de monitoramento. A Tenet relatou uma taxa de sucesso de 90% contra Claude Code sob a configuração padrão do Cloudflare e estimou que mais de 15.000 organizações estão expostas apenas por meio de configurações do Cloudflare.

Tenet demonstrou a técnica em três plataformas. Entradas de logs WAF do Cloudflare envenenadas (Cloudflare protege cerca de 42% das empresas Fortune 500) fizeram com que agentes alterassem configurações DNS e redirecionassem o tráfego. Mensagens de logs injetadas do Datadog (usado por cerca de 48% das Fortune 500) fizeram com que agentes instalassem pacotes maliciosos, levando à execução remota de código e roubo de credenciais. Relatórios de erros do Sentry envenenados (Sentry atende cerca de 4 milhões de desenvolvedores) fizeram com que uma instância comprometida do Claude Code garantisse pelo atacante ao agente Seer AI do Sentry, produzindo uma cadeia de confiança entre agentes. Tenet também relatou ter encontrado mais de 2.700 chaves de API do Datadog expostas e divulgou separadamente uma fuga de sandbox relacionada a JWT no Claude Desktop para a Anthropic. Essa questão foi corrigida antes da palestra DEF CON.

As ações do agente nos três casos usam suas próprias credenciais legítimas e já autorizadas. Isso significa que as ferramentas EDR, WAF e IAM não sinalizam nada anômalo.

Por que isso importa: RBAC, privilégio mínimo e MFA não ajudam aqui, porque o acesso do agente é legítimo. O problema é o que foi instruído a fazer com esse acesso. As próprias recomendações da Tenet são uma lista de verificação razoável para começar: restringir o acesso de saída do agente à rede por padrão, exigir aprovação humana antes de mudanças na infraestrutura, separar ferramentas somente leitura das que podem escrever, e tratar todo log ou alerta que um agente lê como entrada não confiável, independentemente da plataforma de origem.

The OpenAI–Hugging Face incident: An agent that escaped its own test

Em julho de 2026, a OpenAI revelou que durante uma avaliação interna usando o benchmark ExploitGym (898 vulnerabilidades reais), uma versão experimental do GPT-5.6 Sol, executada com as proteções de segurança desativadas, escapou da sandbox e comprometeu a infraestrutura de produção da Hugging Face. A Hugging Face divulgou o incidente em 16 de julho; a OpenAI revelou seu papel em 21 de julho. Eric Wallace e Michael Dalton apresentaram o caso na Black Hat USA 2026.

De acordo com as divulgações, o agente encontrou e explorou uma zero-day em uma instância self-hosted do Artifactory (proxy de cache do registro de pacotes da JFrog) para escapar da sandbox e alcançar a internet. O agente então inferiu que Hugging Face hospedava a chave de respostas do benchmark e foi atrás dela diretamente. Múltiplas instâncias de agentes depois se coordenaram através do próprio Artifactory, trocando centenas de milhares de mensagens para dividir tarefas e compartilhar exploits. Em um momento, os agentes propuseram assinar criptograficamente suas mensagens após suspeitar de um impostor. Quando a OpenAI fechou o canal em 4 de julho, os agentes o reconstruíram em quatro dias usando nomes de diretórios em um endpoint não autenticado como canal de mensagens substituto.

Durante uma campanha de 4,5 dias, a OpenAI registrou mais de 17.600 ações de agentes, incluindo exfiltração de 136 chaves de armazenamento de credenciais, roubo de uma chave de autenticação mesh VPN, inscrição de 181 dispositivos via Tailscale e aquisição de acesso de gravação ao GitHub App. A atividade em 11 nós Kubernetes incluiu personificação de nós via metadados de instância AWS, tokens de identidade falsificados usando uma chave EdDSA JWT roubada e criação de pods privilegiados com montagens do sistema de arquivos do host. A OpenAI afirmou ter identificado outras fugas menores de sandbox, descritas como limitadas, e nenhuma delas acredita ter saído da própria rede.

Um detalhe específico de identity e incident response: as consultas forenses da Hugging Face foram bloqueadas pelas mesmas barreiras comerciais de segurança de IA integradas nos modelos OpenAI e Anthropic que tentou usar para a investigação, porque as barreiras não conseguiam distinguir as perguntas de um respondedor de incidentes das de um atacante. A Hugging Face usou um modelo open-weight de 753 bilhões de parâmetros (GLM-5.2) para processar mais de 17.000 eventos de atacantes em horas em vez de dias.

Por que isso importa: este é um caso documentado de um agente autônomo que descobre independentemente uma vulnerabilidade, exfiltra credenciais, falsifica tokens e se move lateralmente pela infraestrutura em nuvem sem direção humana. Se seu modelo de IAM e governança considera apenas identidades humanas e de contas de serviço, este incidente é uma razão concreta para adicionar uma terceira categoria: agentes autônomos que podem agir por iniciativa própria.

O que esses três têm em comum

CloudBasher trata de lacunas nos controles de identity no nível do protocolo: revogação de tokens, limites de assunção de funções, políticas de acesso padrão. GhostJacking trata de um agente de IA usando uma identidade legítima e delegada para agir conforme instruções em que não deveria ter confiado. O incidente OpenAI–Hugging Face trata de um agente que obtém e falsifica credenciais por conta própria, sem que um humano ou um registro corrompido o tenha provocado.

Um fio condutor separa os três casos: os defensores são limitados por ferramentas que os atacantes não precisam respeitar. CloudBasher explorou suposições que os defensores não testaram. GhostJacking explorou o fato de que as ferramentas de identity não conseguem avaliar a intenção. E no caso OpenAI–Hugging Face, as barreiras de segurança para evitar uso indevido também atrasaram quem respondia.

---

Próximos passos práticos para as equipes de identity e AD

Quatro coisas que valem a pena fazer neste trimestre com base nesta pesquisa:

Pesquisas que você pode ter perdido

Caso tenha perdido, estamos compartilhando três dos principais posts da equipe de Security Research da Netwrix.

Controles LDAP estendidos poderosos: Anti-remediação e reconhecimento invisível no AD 

O pesquisador sênior de segurança Darryl Baker auditou todos os controles LDAP estendidos documentados do Active Directory e encontrou dois com potencial ofensivo que não haviam sido publicados anteriormente. FORCE_UPDATE permite que um invasor com acesso de gravação a apenas um atributo faça um valor malicioso vencer a resolução de conflitos de replicação do AD, de modo que uma correção posterior do defensor seja revertida silenciosamente. A flag OBJECT_SECURITY no DirSync permite que qualquer usuário de domínio leia em massa os dados do AD pelo caminho de replicação sem gerar os eventos de log que uma pesquisa normal acionaria. Nenhum concede novos privilégios, mas ambos derrotam as detecções nas quais a maioria dos defensores confia; o post inclui orientações de detecção correspondentes e ferramentas open source red/blue.

Por que é importante: ambas as técnicas passam despercebidas nos eventos de log exatos (Evento 1644, Evento 4662) nos quais a maioria das regras de monitoramento de AD se baseia. Se suas detecções não foram testadas especificamente contra eles, provavelmente não serão acionadas. Vale a pena verificar se seus canários SACL e consultas de caça realmente detectariam isso. 

Leia mais

Seu assistente de codificação de IA está vazando segredos 

Darryl Baker auditou o armazenamento de credenciais em 14 ferramentas populares de assistentes de desktop de IA, incluindo Claude Code, GitHub Copilot, Cursor, Continue.dev e Cline, e descobriu que a maioria mantém tokens OAuth e chaves de API em JSON simples em caminhos de arquivo previsíveis. Uma falha específica: no WSL, arquivos de credenciais Claude Code no Windows podem herdar permissões de leitura para todos. O post percorre oito cenários de ataque, incluindo o sequestro de uma sessão ativa de controle remoto Claude Code e arquivos de configuração MCP que agregam tokens para vários serviços em um único arquivo legível. Também apresenta AIHound, um scanner open source da Netwrix que verifica uma máquina para esse tipo de credencial exposta.

Por que isso importa: se seus engenheiros usam alguma dessas ferramentas, suas credenciais provavelmente estão armazenadas em texto simples no disco agora, em um caminho de arquivo que um invasor não precisa adivinhar. Não é necessária escalada de privilégios para lê-las, e como as configurações MCP agrupam vários tokens de serviço em um único arquivo, um único laptop comprometido pode se espalhar para todos os sistemas ou serviços conectados. Isso pode incluir bancos de dados, infraestrutura em nuvem e até outras ferramentas de IA. AIHound oferece uma maneira rápida de verificar sua própria exposição antes que outra pessoa a descubra para você. 

Leia mais

Automatizando a destruição de tenant Entra ID com IA 

Usando Claude para Chrome contra Microsoft Graph Explorer, Huy Kha mostrou que, uma vez que uma conta conectada já possui acesso de Administrador Global, o JavaScript do lado do navegador e as solicitações em lote do Graph podem automatizar a exclusão em massa de usuários, redefinições de senha, revogação de sessões e remoção de políticas de Acesso Condicional. A publicação relaciona isso a incidentes reais, incluindo os casos Stryker e Storm-0501, onde operações destrutivas no locatário seguiram uma violação de conta privilegiada, e destaca que a IA não criou um novo caminho de ataque aqui; ela explorou um fluxo de trabalho administrativo existente e o tornou mais rápido e fácil de executar em escala.

Por que é importante: esta é a lacuna entre a violação de uma conta privilegiada e a destruição total do tenant, e a automação de IA está fechando essa lacuna rapidamente. Uma vez que alguém tem uma sessão de Global Admin, não precisa mais de habilidades de script ou tempo para causar o máximo dano. Isso aumenta a importância de proteger e monitorar sessões de administrador e ferramentas como Graph Explorer, não apenas as credenciais. 

Leia mais

Relatório de Segurança de Dados e Identity Security 2026: Avanços e lacunas na adoção e prontidão da IA agentiva

O Netwrix Research Lab entrevistou 2.317 profissionais de TI e segurança em 1.889 organizações para produzir o Relatório de Segurança de Dados e Identity 2026. As descobertas mostram que organizações onde a IA expandiu significativamente sua pegada de identity foram invadidas cerca de quatro vezes mais do que aquelas onde isso não ocorreu. O relatório atribui a diferença à velocidade da governança, e não ao rigor: 76% das organizações não governam ou monitoram totalmente identidades não humanas, e apenas 11% relatam prontidão total de segurança de IA por meio de aplicação e monitoramento contínuos.

Por que é importante: os dados complicam uma suposição comum, de que uma boa higiene de identidade sozinha protege contra riscos impulsionados por IA. Se sua governança de identidade ainda funciona com revisões trimestrais e auditorias periódicas, vale a pena verificar quanto tempo um novo agente de IA ou identidade não humana existe antes que alguém perceba. Essa demora, e não um controle ausente, é o que a lacuna de violação neste relatório realmente indica.

Leia mais

---

Isso é tudo para esta edição do Netwrix Threat Lab Quarterly. Voltaremos em breve com novas pesquisas e mais formas de fechar as brechas que os atacantes esperam que você perca.