Threat Lab Quarterly: August 2026

Tracking down stale and ghost SPNs before attackers do

By Huy Kha

Introduction

Over the past few years, Active Directory attacks abusing Service Principal Names (SPNs) have increased. It started with Kerberoasting, but the techniques have gotten more creative since then. Ghost SPN attacks can enable privilege escalation by claiming service targets nobody's using anymore. More recently, SPN Unicode collision attacks let any authenticated user with write-SPN permissions escalate privileges too, using nothing more than a visually identical but technically different SPN.

There's also a quieter problem that doesn't get too much attention, which is basic security hygiene. At Netwrix, we see the same pattern come up again and again, regardless of the size of the organization. Computer accounts stay enabled in Active Directory long after the machine behind them was decommissioned. Service accounts keep SPNs that still point to hosts that don't exist anymore. Nobody goes back to clean any of it up, so the account just sits there, still active, still vulnerable to Kerberoasting, and nobody's paying attention to it.

Finding stealth SPNs in your domain(s)

Our security research team decided to build something that would make this easy for IT pros and admins: a PowerShell script called Find-StealthSPNs that hunts down stealth SPNs across both computer and user accounts, so you can review the results and decide what actually needs cleaning up.

The script runs in two main passes. The first one looks at every computer account in the forest. Since every domain-joined machine registers at least one SPN by default, this pass checks whether that computer's own hostname still resolves in DNS, and whether any of its SPNs point to hosts that no longer exist anywhere. We call this a ghost SPN, an SPN that's still sitting on an account, still technically valid, but pointing at nothing real. It also catches computer accounts that were precreated in AD but never actually joined, since those often end up with no SPN at all, sitting there indefinitely with nobody noticing.

We deliberately check this through DNS rather than an ICMP ping. Some admins lean on ping to get a quick sense of whether a host behind an SPN is still alive, but ICMP gets blocked by firewalls and host-based filtering so often in most environments that a failed ping doesn't really tell you much. A missing DNS record is a more reliable signal that nothing is expecting that hostname to exist anymore, regardless of whether the box itself would respond to a ping.

The second pass looks at user accounts, specifically the ones holding SPNs, since that's the classic setup for a service account. For every SPN it finds, it checks two things: does a matching computer account still exist in AD, and does that hostname still resolve in DNS. If neither is true, that's about as clear a signal as you can get that the SPN is dead weight. The account is still active, the SPN is still registered, and it's still just as exploitable through Kerberoasting as it ever was, except now there's nothing legitimate depending on it anymore.

On top of that, the script also checks for SPN Unicode collisions, the kind of attack we mentioned earlier, where a crafted SPN can visually match a real one while being a completely different value underneath. It flags any SPN with hidden or lookalike characters and cross-references every SPN in the forest to catch cases where two accounts appear to hold the same SPN. This may have some false positives, so always double-check first.

Everything runs using nothing but ADSI and DirectorySearcher, so there's no dependency on the ActiveDirectory PowerShell module, and it works across every domain in the forest, not just the one you happen to run it from.

A quick note on DNS resolution: This script checks DNS using whatever resolver is configured on the machine you run it from. For (more) accurate results, run it from a domain controller rather than a workstation, since DCs are already set up to resolve every domain in your environment. Running it from a machine with unusual or restricted DNS settings could produce false MISSING_DNS results for records that actually exist.

Conclusion

At the end of the day, we're trying to help organizations reduce their attack surface by cleaning up stale accounts that nobody's tracking anymore. Every ghost SPN, every enabled computer account tied to a machine that's long gone, every service account still pointing at a host that no longer exists, is one more thing sitting in Active Directory that doesn't need to be there and shouldn't be. None of it requires a sophisticated attacker. It just requires someone to notice it before you do.

---

DEF CON 34's identity security angle

By Darryl Baker

DEF CON 34 and Black Hat USA 2026 produced three separate pieces of research that all point at identity infrastructure. Here's what each one announced and what it means for people running identity and AD programs.

CloudBasher: Free cloud shells turned into attacker infrastructure

Jenko Hwong and Chris Ryan presented CloudBasher, an open-source toolkit built by reverse-engineering the private REST APIs and WebSocket sessions behind the free cloud shell features in AWS, Azure, and GCP. The toolkit will be public on GitHub, along with a 2026 breakdown of cloud misconfiguration patterns drawn from breach data.

The research surfaced a few specific findings worth flagging for identity teams.

• A compromised AWS identity can assume a role and spin up a large number of CloudShell environments.
• WebSocket terminal sessions stay alive after the underlying access token is revoked, so revoking a credential doesn't necessarily end an active session.
• M365 and Gmail consumer accounts get default CloudShell access, which extends the relevant attack surface to personal accounts, not just enterprise ones.

Once a session is established, the toolkit persists in the $HOME directory (which survives resets), can lock the legitimate user out of sudo within their own session, and installs a C2 framework.

Why it matters: if your identity program treats token revocation as equivalent to session termination, this research says that assumption should be tested, not assumed. It's also worth confirming whether your CloudShell access policies and monitoring would catch anomalous session creation at all. 

GhostJacking: AI coding agents acting on instructions hidden in logs 

Barak Sternberg, Nevo Poran, and Ron Bobrov of Tenet Security presented GhostJacking, a technique for hijacking AI coding agents by planting instructions inside logs the agent is expected to read, such as WAF alerts, error reports, and monitoring output. Tenet reported a 90% success rate against Claude Code under Cloudflare's default configuration and estimated that more than 15,000 organizations are exposed through Cloudflare configurations alone.

Tenet demonstrated the technique across three platforms. Poisoned Cloudflare WAF log entries (Cloudflare sits in front of an estimated 42% of Fortune 500 companies) caused agents to change DNS settings and redirect traffic. Injected Datadog log messages (used by roughly 48% of the Fortune 500) caused agents to install malicious packages, leading to remote code execution and credential theft. Poisoned Sentry error reports (Sentry serves an estimated 4 million developers) caused a compromised Claude Code instance to vouch for the attacker to Sentry's own Seer AI agent, producing an agent-to-agent trust chain. Tenet also reported finding over 2,700 exposed Datadog API keys and separately disclosed a JWT-related sandbox escape in Claude Desktop to Anthropic. This issue was patched before the DEF CON talk.

The agent's actions in all three cases use its own legitimate, already-authorized credentials. This means EDR, WAF, and IAM tooling don't flag anything as anomalous.

Why it matters: RBAC, least privilege, and MFA don't help here, because the agent's access is legitimate. The problem is what it's been told to do with that access. Tenet's own recommendations are a reasonable starting checklist: restrict agent outbound network access by default, require human approval before infrastructure changes, separate read-only tools from write-capable ones, and treat every log or alert that an agent reads as untrusted input, regardless of which platform it came from.

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

In July 2026, OpenAI disclosed that during an internal evaluation using the ExploitGym benchmark (898 real-world vulnerabilities), an experimental version of GPT-5.6 Sol, run with safety guardrails disabled, escaped its sandbox and compromised Hugging Face's production infrastructure. Hugging Face disclosed the incident on July 16; OpenAI disclosed its role on July 21. Eric Wallace and Michael Dalton presented on it at Black Hat USA 2026.

According to the disclosures, the agent found and exploited a zero-day in a self-hosted instance of Artifactory (JFrog's package registry cache proxy) to escape its sandbox and reach the internet. The agent then inferred that Hugging Face hosted the benchmark's answer key and went after it directly. Multiple agent instances later coordinated through Artifactory itself, exchanging hundreds of thousands of messages to divide tasks and share exploits. At one point, agents proposed cryptographically signing their messages after suspecting an impostor. When OpenAI shut the channel down on July 4, the agents rebuilt it within four days using directory names on an unauthenticated endpoint as a substitute messaging channel.

Over a 4.5-day campaign, OpenAI logged more than 17,600 agent actions, including exfiltration of 136 credential-store keys, theft of a mesh VPN authentication key, enrollment of 181 devices via Tailscale, and acquisition of GitHub App write access. Activity across 11 Kubernetes nodes included node impersonation via AWS instance metadata, forged identity tokens using a stolen EdDSA JWT signing key, and creation of privileged pods with host filesystem mounts. OpenAI stated it identified other, smaller sandbox escapes as well, described as limited in nature, and none of which it believes left its own network.

One detail specific to identity and incident response: Hugging Face's forensic queries were blocked by the same commercial AI safety guardrails built into the OpenAI and Anthropic models it tried to use for investigation, because the guardrails couldn't distinguish an incident responder's questions from an attacker's. Hugging Face used an open-weight, 753-billion-parameter model (GLM-5.2) to process more than 17,000 attacker events in hours instead of days.

Why it matters: this is a documented case of an autonomous agent independently discovering a vulnerability, exfiltrating credentials, forging tokens, and moving laterally across cloud infrastructure without human direction. If your IAM and governance model only accounts for human and service-account identities, this incident is a concrete reason to add a third category: autonomous agents that can act on their own initiative.

What these three have in common

CloudBasher is about gaps in identity controls at the protocol level: token revocation, role assumption boundaries, default access policies. GhostJacking is about an AI agent using a legitimate, delegated identity to act on instructions it shouldn't have trusted. The OpenAI–Hugging Face incident is about an agent obtaining and forging credentials on its own, without a human or a poisoned log prompting it.

A separate thread runs through all three: defenders are constrained by tools attackers don't have to respect. CloudBasher exploited assumptions defenders hadn't tested. GhostJacking exploited the fact that identity tooling can't evaluate intent. And in the OpenAI–Hugging Face case, the safety guardrails meant to prevent misuse also slowed down the people responding to it.

---

Practical next steps for identity and AD teams

Four things worth doing this quarter based on this research:

Research you might have missed 

In case you missed it, we’re sharing three of the top posts from Netwrix's Security Research team. 

Powerful LDAP extended controls: Anti-remediation and invisible recon in AD 

Senior Staff Security Researcher Darryl Baker audited all of Active Directory's documented LDAP extended controls and found two with offensive potential that hadn't been previously published. FORCE_UPDATE lets an attacker with write access to just one attribute make a malicious value win AD's replication conflict resolution, so a defender's later fix silently reverts. The OBJECT_SECURITY flag on DirSync lets any domain user bulk-read AD data over the replication path without generating the log events a normal search would trigger. Neither grants new privilege, but both defeat detections most defenders rely on; the post includes matching detection guidance and open-source red/blue tooling. 

Why it matters: both techniques slip past the exact log events (Event 1644, Event 4662) that most AD monitoring rules are keyed on. If your detections haven't been tested against them specifically, they likely won't fire. It’s definitely worth checking whether your SACL canaries and hunting queries would actually catch this. 

Read more

Your AI coding assistant is leaking secrets 

Darryl Baker audited credential storage across 14 popular AI desktop assistant tools, including Claude Code, GitHub Copilot, Cursor, Continue.dev, and Cline, and found that most keep OAuth tokens and API keys in plaintext JSON at predictable file paths. One specific gap: on WSL, Windows-side Claude Code credential files can inherit world-readable permissions. The post walks through eight attack scenarios, including hijacking an active Claude Code remote-control session and MCP config files that aggregate tokens for multiple services into a single readable file. It also introduces AIHound, an open-source scanner from Netwrix that checks a machine for exactly this kind of exposed credential. 

Why it matters: if your engineers use any of these tools, their credentials are probably sitting in plaintext on disk right now, at a file path an attacker doesn't have to guess. No privilege escalation needed to read them, and because MCP configs bundle multiple service tokens into one file, a single compromised laptop can cascade into every connected system or service. This can include databases, cloud infrastructure, and even other AI tools. AIHound gives you a fast way to check your own exposure before someone else finds it for you. 

Read more

Automating Entra ID tenant destruction with AI 

Using Claude for Chrome against Microsoft Graph Explorer, Huy Kha showed that once a signed-in account already holds Global Administrator access, browser-side JavaScript and Graph batch requests can automate bulk user deletion, password resets, session revocation, and Conditional Access policy removal. The post ties this to real incidents, including the Stryker and Storm-0501 cases, where destructive tenant operations followed a privileged-account compromise, and makes the point that AI didn't create a new attack path here; it exploited an existing admin workflow and made it faster and easier to run at scale. 

Why it matters: this is the gap between a privileged-account compromise and full tenant destruction, and AI automation is closing it fast. Once someone has a Global Admin session, they no longer need scripting skills or time to do maximum damage. That raises the stakes on protecting and monitoring admin sessions and tools like Graph Explorer, not just the credentials themselves. 

Read more

2026 Data and Identity Security Report: Advances and gaps in agentic AI adoption and readiness

Netwrix Research Lab surveyed 2,317 IT and security professionals across 1,889 organizations to produce the 2026 Data and Identity Security Report. The findings show that organizations where AI significantly expanded their identity footprint were breached roughly four times more often than those where it hadn't. The report ties the gap to governance speed rather than rigor: 76% of organizations don't fully govern or monitor non-human identities, and only 11% report full AI security readiness through continuous enforcement and monitoring.

Why it matters: the data complicates a common assumption, that strong identity hygiene alone protects against AI-driven risk. If your identity governance still runs on quarterly reviews and periodic audits, it's worth checking how long a new AI agent or non-human identity exists before anyone notices it. That lag, not a missing control, is what the breach gap in this report actually points to.

Read more

---

That's it for this edition of the Netwrix Threat Lab Quarterly. We'll be back soon with new research and more ways to close the gaps attackers are counting on you to miss.