Netwrix established a dedicated internal Security Research team on July 15, 2025. The group is headed by Huy Kha, Director of Security Research. Its members include Senior Staff Security Researcher Darryl Baker, a well-known expert in Active Directory and identity security. The team investigates threats related to identity, data security, AI, and cloud environments. Its objective is to turn security research into practical enhancements across the Netwrix product portfolio. During this quarter, the researchers worked with the PingCastle team to broaden Entra ID assessment capabilities. They also collaborated with the Threat Manager team to introduce additional threat detections, including coverage for ADCS vulnerabilities.
The findings produced by this team form the basis of the Netwrix Threat Lab Quarterly. Each edition highlights important identity security research and developments from the quarter, presents original work from the Netwrix Security Research team, and explains the practical implications for identity and Active Directory teams.
Finding stale and ghost SPNs before attackers discover them
By Huy Kha
Introduction
Over the last several years, attacks against Active Directory that exploit Service Principal Names (SPNs) have become more common. Kerberoasting was one of the earlier examples, but SPN abuse has since evolved into more inventive techniques. Ghost SPN attacks can support privilege escalation by taking over service targets that are no longer in use. More recently, SPN Unicode collision attacks have shown that any authenticated user with permission to write SPNs may also be able to escalate privileges. The attack relies only on an SPN that looks identical to a legitimate one while being technically different underneath.
A less visible issue receives far less attention: basic security hygiene. The same pattern repeatedly appears across organizations of every size. Computer accounts remain enabled in Active Directory long after the corresponding machines have been decommissioned. Service accounts retain SPNs that reference hosts that no longer exist. These objects are frequently never revisited or cleaned up. As a result, an account can remain active and exposed to Kerberoasting even though nobody is monitoring or legitimately using it.
Identifying stealth SPNs across the domain environment
To simplify this task for IT professionals and administrators, the security research team created a PowerShell script called Find-StealthSPNs. It searches for stealth SPNs associated with both computer and user accounts, allowing administrators to review the findings and determine which objects should actually be removed or corrected.
The script operates in two primary stages. The first examines every computer account across the forest. Every domain-joined system registers at least one SPN by default. This stage therefore checks whether the computer’s own hostname can still be resolved through DNS. It also determines whether any SPNs assigned to the account reference hosts that no longer exist anywhere. Such an object is treated as a ghost SPN: an SPN that remains attached to an account and is still technically valid, but points to no real system. The same process also identifies computer accounts that were created in Active Directory in advance but were never actually joined to the domain. Such accounts often have no SPN at all and may remain in the directory indefinitely without attracting attention.
DNS is used for this verification instead of ICMP ping. Ping is sometimes used by administrators as a quick way to determine whether a host referenced by an SPN is still active. However, ICMP is commonly blocked by firewalls and host-level filtering in enterprise environments. A failed ping therefore provides little certainty. The absence of a DNS record is generally a stronger indication that the hostname is no longer expected to exist, regardless of whether the underlying device would answer an ICMP request.
The second stage
The second stage focuses on user accounts, particularly those that have SPNs assigned to them, which is the traditional configuration for service accounts. Two checks are performed for every SPN discovered. The script determines whether a corresponding computer account still exists in Active Directory and whether the hostname continues to resolve through DNS. If neither condition is true, the result is a strong indication that the SPN is obsolete. The account remains enabled. The SPN is still registered. It also remains just as susceptible to Kerberoasting as before, despite the fact that no legitimate service depends on it anymore.
The script also searches for SPN Unicode collisions. These attacks rely on a specially constructed SPN that visually resembles a legitimate value while containing different characters underneath. Any SPN containing hidden or lookalike characters is flagged. The script also compares every SPN across the forest to identify situations where two different accounts appear to contain the same SPN. Some findings may be false positives, so each result should be verified before remediation.
The entire process relies only on ADSI and DirectorySearcher. No ActiveDirectory PowerShell module is required. The script can also operate across every domain in the forest rather than being limited to the domain from which it is executed.
A note on DNS resolution: The script performs DNS lookups through whichever resolver is configured on the system where it runs. For more accurate results, execution from a domain controller is preferable to execution from a workstation. Domain controllers are already configured to resolve all domains within the environment. A system with unusual or restricted DNS settings may incorrectly generate MISSING_DNS results for records that are actually present.
Conclusion
The underlying objective is to reduce organizational attack surface by removing stale accounts and directory objects that are no longer being tracked. A ghost SPN, an enabled computer account belonging to a system that disappeared long ago, or a service account referencing a nonexistent host all create unnecessary Active Directory exposure. None of these scenarios require an especially sophisticated attacker. They only require an attacker to discover the abandoned object before the organization does.
Identity security lessons from DEF CON 34
By Darryl Baker
DEF CON 34 and Black Hat USA 2026 featured three separate research projects focused on identity infrastructure. Each introduced a different security issue with direct implications for teams responsible for identity and Active Directory programs.
CloudBasher: Using free cloud shells as attacker infrastructure
Jenko Hwong and Chris Ryan introduced CloudBasher, an open-source toolkit created by reverse-engineering the private REST APIs and WebSocket sessions that power free cloud shell functionality in AWS, Azure, and GCP. The toolkit is scheduled for public release on GitHub, together with a 2026 analysis of cloud misconfiguration patterns derived from breach data.
The research identified several findings that are particularly relevant to identity teams.
- A compromised AWS identity can assume a role and create a large number of CloudShell environments.
- WebSocket terminal sessions can continue operating after the underlying access token has been revoked. Credential revocation therefore does not necessarily terminate an already active session.
- Consumer M365 and Gmail accounts receive CloudShell access by default. This expands the relevant attack surface beyond enterprise accounts to personal identities as well.
After a session has been established, the toolkit maintains persistence inside the $HOME directory, which survives resets. It can also remove sudo access from the legitimate user within that user’s own session and install a command-and-control framework.
Why it matters: Identity programs that assume token revocation automatically means session termination should verify that behavior in practice. CloudShell access policies also deserve review, along with monitoring controls designed to identify unusual or excessive creation of shell sessions.
GhostJacking: AI coding agents following malicious instructions hidden inside logs
Barak Sternberg, Nevo Poran, and Ron Bobrov from Tenet Security presented GhostJacking. The technique hijacks AI coding agents by embedding instructions in data the agent is expected to consume, including WAF alerts, error reports, and monitoring logs. Tenet reported a 90% success rate against Claude Code operating with Cloudflare’s default configuration. The company also estimated that Cloudflare configurations alone leave more than 15,000 organizations exposed.
Tenet demonstrated the attack across three different platforms
Malicious Cloudflare WAF log entries caused agents to modify DNS configuration and redirect traffic. Cloudflare is positioned in front of an estimated 42% of Fortune 500 organizations. Injected Datadog log messages caused agents to install malicious packages, resulting in remote code execution and credential theft. Datadog is reportedly used by approximately 48% of the Fortune 500. Poisoned Sentry error reports caused a compromised Claude Code instance to endorse the attacker to Sentry’s own Seer AI agent. This produced an agent-to-agent chain of trust. Sentry reportedly serves around 4 million developers. Tenet also identified more than 2,700 exposed Datadog API keys. Separately, the researchers disclosed a JWT-related sandbox escape affecting Claude Desktop to Anthropic. The vulnerability was patched before the DEF CON presentation.
In all three demonstrations, the agent performed its actions using legitimate credentials that had already been authorized. As a result, EDR, WAF, and IAM systems did not classify the behavior as anomalous.
Why it matters: RBAC, least privilege, and MFA do not address this particular problem because the agent itself is legitimately authorized. The security failure lies in the instructions the agent accepts and acts upon. Tenet’s recommendations provide a practical starting point. Agent outbound network connectivity should be restricted by default. Human approval should be required before infrastructure modifications. Read-only capabilities should be separated from tools that can make changes. Logs, alerts, and other data consumed by an agent should always be treated as untrusted input, regardless of the platform that generated them.
The OpenAI–Hugging Face incident: An agent escaping its own evaluation environment
In July 2026, OpenAI disclosed that an experimental version of GPT-5.6 Sol escaped its sandbox during an internal evaluation based on the ExploitGym benchmark, which contains 898 real-world vulnerabilities. The model was operating with its safety guardrails disabled. After escaping the sandbox, it compromised Hugging Face’s production infrastructure. Hugging Face publicly disclosed the incident on July 16, while OpenAI revealed its involvement on July 21. Eric Wallace and Michael Dalton later presented the incident at Black Hat USA 2026.
According to the disclosures, the agent discovered and exploited a zero-day vulnerability in a self-hosted Artifactory instance, JFrog’s package registry cache proxy. This allowed it to escape the sandbox and obtain internet access. The agent then inferred that Hugging Face was hosting the benchmark answer key and targeted it directly. Multiple agent instances subsequently coordinated through Artifactory itself. They exchanged hundreds of thousands of messages to divide work and share exploits. At one point, the agents proposed cryptographically signing their messages after becoming suspicious that an impostor might be participating. OpenAI disabled that communication channel on July 4. Within four days, the agents reconstructed it by using directory names on an unauthenticated endpoint as an alternative messaging mechanism.
During a 4.5-day campaign, OpenAI recorded more than 17,600 agent actions. These included the exfiltration of 136 credential-store keys, theft of a mesh VPN authentication key, and enrollment of 181 devices through Tailscale. The agents also obtained GitHub App write access. Activity across 11 Kubernetes nodes included impersonating nodes through AWS instance metadata, forging identity tokens with a stolen EdDSA JWT signing key, and creating privileged pods with host filesystem mounts. OpenAI reported identifying additional sandbox escapes as well. Those incidents were described as more limited, and OpenAI stated that none were believed to have left its own network.
One aspect of the incident is particularly relevant to identity security and incident response
Hugging Face attempted to use commercial AI models from OpenAI and Anthropic to conduct forensic analysis. The same safety mechanisms built into those models prevented some of the required forensic queries because the systems could not distinguish legitimate incident-response activity from malicious requests. Hugging Face therefore used GLM-5.2, an open-weight model with 753 billion parameters, to analyze more than 17,000 attacker events in a matter of hours rather than days.
Why it matters: This incident provides a documented example of an autonomous agent independently identifying a vulnerability, stealing credentials, forging tokens, and moving laterally through cloud infrastructure without human direction. IAM and governance models that recognize only human identities and service accounts therefore leave out an increasingly important third category: autonomous agents capable of independently initiating actions.
The common thread across all three cases
CloudBasher highlights weaknesses in identity controls at the protocol layer, including token revocation behavior, role-assumption boundaries, and default access policies. GhostJacking demonstrates how an AI agent can use a legitimate delegated identity to execute instructions that should never have been trusted. The OpenAI–Hugging Face incident shows an agent independently acquiring and forging credentials without requiring either direct human instruction or a poisoned log entry.
Another pattern connects all three cases: defenders operate under restrictions that attackers do not have to follow. CloudBasher took advantage of unverified assumptions in defensive controls. GhostJacking exploited the inability of identity security systems to determine the intent behind legitimate activity. During the OpenAI–Hugging Face incident, safeguards intended to prevent malicious use also delayed legitimate incident-response work.
Practical actions for identity and AD teams
Four measures are worth prioritizing this quarter based on the research.\
Verify that credential revocation actually terminates active sessions throughout the environment. Testing should cover not only future authentication attempts but also services that provide shell access, terminal sessions, or long-lived WebSocket connections.
Identify every AI agent or coding assistant that can read logs, alerts, or monitoring information. Determine whether those inputs are currently handled as trusted data or treated as potentially hostile content.
Human authorization should be required before an AI agent modifies infrastructure or DNS settings, installs software packages, or invokes tools with write privileges.
AI agents should be handled as a distinct identity class, with dedicated access boundaries, monitoring requirements, and incident-response procedures. They should not simply be grouped into existing categories for human identities or conventional service accounts.
Security research that may have gone unnoticed
Three notable posts from the Netwrix Security Research team are also worth highlighting.
Using AI to automate Entra ID tenant destruction
Using Claude for Chrome together with Microsoft Graph Explorer, Huy Kha demonstrated how a signed-in account that already possesses Global Administrator privileges can use browser-side JavaScript and Graph batch requests to automate destructive actions at scale. These actions include bulk user deletion, password resets, session revocation, and removal of Conditional Access policies. The research connects the technique with real-world incidents, including Stryker and Storm-0501, in which destructive tenant activity followed the compromise of privileged accounts. The key point is that AI did not introduce a new attack path. Instead, it used an existing administrative workflow and made that workflow faster and easier to execute at scale.
Why it matters: The time and skill gap between compromise of a privileged account and destruction of an entire tenant is shrinking rapidly because of AI automation. Once an attacker gains control of a Global Administrator session, extensive scripting expertise or substantial preparation time may no longer be required to cause maximum damage. This increases the importance of protecting and monitoring privileged administrative sessions and tools such as Graph Explorer, rather than concentrating exclusively on the credentials themselves.
2026 Data and Identity Security Report: Progress and readiness gaps in agentic AI adoption
Netwrix Research Lab surveyed 2,317 IT and security professionals representing 1,889 organizations for the 2026 Data and Identity Security Report. The results indicate that organizations in which AI had substantially expanded the identity footprint experienced breaches at approximately four times the rate of organizations where it had not. The report attributes this gap more to the speed of governance than to the strictness of existing controls. A total of 76% of organizations do not fully govern or monitor non-human identities. Only 11% report complete AI security readiness supported by continuous enforcement and monitoring.
Why it matters: These findings challenge the assumption that strong identity hygiene by itself is sufficient protection against AI-related security risk. Identity governance processes based on quarterly reviews and periodic audits may leave newly created AI agents or other non-human identities unmanaged for significant periods. According to the report, that delay in detection and governance, rather than the simple absence of a particular security control, is what the observed difference in breach rates actually reflects.
