Hackers Exploit ‘Ghost SPN’ in Active Directory for Stealth Kerberoasting

Active Directory environments are under a growing threat from a technique dubbed “Ghost SPN,” which allows attackers to sneakily carry out Kerberoasting without the usual red flags. The approach works by exploiting misconfigurations in Service Principal Names (SPNs) and active directory permissions, turning regular user accounts into juicy targets without involving traditional service identities tied to privileged accounts.

How Ghost SPN Works

At the heart of the Ghost SPN attack is an adversary with delegated, not full, admin rights—often permissions to modify account objects. With this limited access, they attach a plausible SPN to a standard user account that normally wouldn’t have one. Once that SPN is in place, the attacker requests a Kerberos service ticket (TGS) for it, which can be encrypted using RC4-HMAC, an older cipher type that’s much easier to crack offline.

The problem gets worse because attackers can then erase signs of their action—removing the SPN attribute—after getting the ticket. This limits audit trails and makes detection far more difficult. Since this technique doesn’t require elevated service accounts, it flies under defenders’ radar—especially when organizations assume only those service accounts are at risk.

Risks and Detection Blind Spots

Kerberoasting (MITRE ATT&CK T1558.003) already gives attackers a pathway to attack domain accounts by extracting TGS tickets tied to SPNs. What’s new here is the temporary exposure: Ghost SPN makes it possible to expand the attack surface to accounts never intended to be targets. Since RC4 encryption is vulnerable to offline cracking, the attacker’s ticket data can be exhaustively tested without triggering alerts or lockouts.

Detection strategies often break down because steps such as SPN assignment and removal can happen outside normal workflows. The networking and identity telemetry logs typically don’t flag these brief, low-noise windows. A TGS request using Event ID 4769 with RC4, or bursts of service ticket requests from non-service accounts, are better indicators—but only when correlated with suspicious activity elsewhere, like attempts to dump credentials or access LSASS.

Mitigation and Best Defenses

Organizations need to shrink the pool of accounts that can issue weakly encrypted service tickets. Moving services into group Managed Service Accounts (gMSAs) or delegated Managed Service Accounts helps because these types are managed centrally and reduce reliance on static, often weak, passwords. When service accounts must remain manual, they should use long, random passwords. Also, migrating encryption to stronger ciphers like AES—and resetting passwords after such changes—ensures new keys are generated correctly.

Further, RC4 should be disabled wherever possible, particularly for service accounts. Audits should not just focus on privileged identities, but also on any user accounts with SPNs, especially when permissions allow modification of account objects. Alerts should be configured for unexpected SPN changes and RC4-encrypted TGS request events.

Microsoft has pointed out that many Active Directory setups still use RC4 by default even though it’s weaker, making it a favored target for Kerberoasting. Teams should also assess delegated permissions across the directory: who has the power to modify accounts, how often SPNs are added or removed, and whether accounts unexpectedly take on SPNs that increase their exposure.

By investigating these gaps and adjusting permissions and encryption practices, organizations can significantly reduce the chance of Kerberoasting attacks through Ghost SPNs—a risk that until now flew under most monitoring radars.

Why This Matters: With attackers moving toward stealth over noise, Ghost SPN represents a shift in how Active Directory is abused. It underscores that even accounts without elevated roles can become strategic leverage points. Going forward, incidents will hinge less on what accounts are powerful, and more on which accounts are exposed through misconfiguration—making strict SPN hygiene, delegated privilege oversight, and aggressive monitoring essential.