Ghost SPN: The Silent Active Directory Trick Turning Ordinary User Accounts Into Kerberoasting Targets

Listen to this Post

🐢▶️ Listen🚀

Introduction: A Quiet Weakness With a Serious Consequence

Active Directory attacks are becoming less about breaking through the front door and more about quietly abusing the permissions, identities, and configurations that organizations already trust. One of the latest examples is a technique researchers have called Ghost SPN, a stealthier variation of Kerberoasting that demonstrates how a seemingly ordinary domain user can temporarily become a credential-theft target.

The danger is not necessarily a spectacular exploit or a newly discovered software vulnerability. Instead, the technique takes advantage of a fundamental Active Directory capability: Service Principal Names (SPNs). When SPNs are misconfigured or when an attacker has excessive delegated permissions over directory objects, a normal user account can potentially be given a service identity long enough for an attacker to request a Kerberos service ticket—and then have that modification removed.

That temporary change can be particularly difficult to investigate after the fact.

Trellix researchers described this attack pattern in 2026 as a transient manipulation of SPN attributes that can create a temporary Kerberoasting opportunity and then erase much of the obvious directory evidence.

Trellix

+1

The broader lesson is uncomfortable: security teams can no longer assume that only traditional service accounts are relevant to Kerberoasting.

The Core Problem: Active Directory Trust Can Become an Attack Surface

Active Directory remains the identity backbone of countless Windows environments. It controls users, computers, permissions, authentication, applications, and access to critical resources.

That makes every directory configuration decision important.

SPNs are normally legitimate and essential. They identify instances of services so that Kerberos can authenticate users to applications such as SQL Server, HTTP services, LDAP services, and other Kerberos-enabled workloads.

The problem begins when those identifiers appear on accounts that were never intended to function as service identities.

Microsoft has previously warned that accounts with SPNs should be audited and that unnecessary SPNs should be removed because they increase exposure to Kerberoasting.

Microsoft

Ghost SPN takes that risk a step further.

What Is Kerberoasting?

Kerberoasting is a credential-access technique tracked by MITRE ATT&CK as T1558.003.

The basic concept is deceptively simple. An attacker who already possesses valid domain credentials can request Kerberos service tickets for accounts associated with SPNs. Portions of those tickets can contain cryptographic material derived from the target account’s password.

The attacker can then attempt to recover the password offline.

That distinction matters.

Traditional password guessing repeatedly interacts with the victim environment. Failed authentication attempts can create logs, trigger detection rules, and eventually cause account lockouts.

Kerberoasting can move much of the password-cracking activity away from the victim network.

MITRE specifically identifies anomalous TGS requests, RC4 encryption, unusually large numbers of service-ticket requests, and unusual targeting of service accounts as useful detection signals.

MITRE ATT&CK

+1

Why Offline Cracking Changes the Equation

Once a service ticket has been obtained, the attacker does not necessarily need to continue communicating with the domain controller while testing password guesses.

The encrypted material can be analyzed separately.

This creates a dangerous asymmetry.

The

If the target password is weak, predictable, reused, or otherwise susceptible to guessing, the consequences can be severe.

A successfully recovered credential can potentially provide access to additional systems and become a stepping stone toward lateral movement or privilege escalation.

The Ghost SPN Difference: Creating the Target

Traditional Kerberoasting usually focuses on accounts that already have SPNs.

Ghost SPN changes the perspective.

Instead of searching only for existing service accounts, an attacker who has sufficient delegated Active Directory permissions can potentially manipulate an ordinary account’s directory attributes and temporarily attach an SPN to it.

The account does not necessarily need to have been designed as a service identity.

The malicious SPN effectively creates a new Kerberoasting target.

Trellix describes this as a temporary or “out-of-band” SPN modification that can be created outside normal service-deployment workflows.

Trellix

That is what makes the technique particularly interesting from a defensive standpoint.

The Attack Window Can Be Extremely Short

The attacker does not necessarily need to leave the malicious SPN in place for days.

The exposure can be temporary.

A simplified defensive understanding looks like this:

Directory permission abuse → temporary SPN modification → Kerberos TGS request → ticket obtained → SPN removed → offline analysis

The critical point is that removing the SPN does not automatically invalidate the information the attacker already obtained.

The directory may eventually look normal again while the attacker still possesses the captured ticket material.

That is why point-in-time configuration checks are not enough.

The Evidence Problem

Imagine an administrator examines the affected user later.

The account looks normal.

There is no obvious SPN.

There is no persistent service configuration.

The user may not have been a privileged administrator.

Yet a suspicious Kerberos request may have occurred while the account temporarily possessed a service identity.

This creates a forensic challenge.

Security teams must connect directory modifications and Kerberos activity across time, rather than examining either event independently.

That correlation is becoming increasingly important as attackers move toward identity-based techniques that deliberately minimize persistence.

Why RC4 Makes the Situation More Dangerous

Kerberos supports multiple encryption types, but RC4 remains particularly relevant to Kerberoasting because of its weaker security properties.

The relevant Kerberos encryption type is commonly represented as etype 0x17.

MITRE identifies RC4-encrypted service tickets as an important signal for Kerberoasting detection.

MITRE ATT&CK

+1

Microsoft has also been actively moving Windows environments away from RC4 because of its security limitations and its relationship to attacks such as Kerberoasting.

Microsoft Learn

+1

This does not mean that AES magically eliminates Kerberoasting.

A weak password can still be attacked.

The important distinction is that stronger encryption makes the attack substantially less attractive than an equivalent RC4 scenario, while strong randomly generated credentials address the underlying password-cracking problem.

AES Is Not a Magic Shield

One of the easiest mistakes defenders can make is assuming that enabling AES automatically solves Kerberoasting.

It does not.

Microsoft explicitly notes that AES alone is not sufficient when weak passwords remain in use.

Microsoft

Think of the problem as two layers.

The first layer is the encryption algorithm.

The second layer is the entropy of the underlying password.

Strong encryption combined with a weak password is still a dangerous combination.

Strong encryption combined with a long, randomly generated secret is a much stronger defensive position.

Why Ordinary User Accounts Matter Now

For years, many organizations approached Kerberoasting primarily as a service-account problem.

That model is becoming incomplete.

If an ordinary user account can temporarily receive an SPN through unauthorized directory modification, then the account can become interesting to an attacker even if it was never intended to run a service.

This means security teams should ask a different question:

Which accounts currently have SPNs?

But they should also ask:

Which identities have the ability to modify SPN-related attributes on other accounts?

The second question is where Ghost SPN becomes especially important.

Delegated Permissions Are the Hidden Risk

Active Directory delegation is essential in large enterprises.

Help-desk teams need permissions.

Application teams need permissions.

Server administrators need permissions.

Automation systems need permissions.

But permissions that are individually reasonable can become dangerous when combined.

A user who can modify another account object may have capabilities that security teams never considered relevant to Kerberos abuse.

The security problem therefore becomes less about one “bad” permission and more about the complete permission graph.

Identity Security Must Include Permission Relationships

A mature Active Directory security program should not only inventory accounts and groups.

It should understand relationships.

Who can modify whom?

Who can change account attributes?

Who can write sensitive properties?

Who can create or alter SPNs?

Which service accounts have weak or old passwords?

Which accounts still depend on RC4?

Which users can make changes outside normal administrative workflows?

These questions can expose attack paths that traditional vulnerability scanners will never see.

The Most Important Detection Event: Event ID 4769

Windows Security Event 4769 records Kerberos service-ticket activity.

That makes it one of the most valuable data sources for identifying possible Kerberoasting.

MITRE’s current detection guidance specifically recommends looking for unusual TGS requests, RC4 etype 0x17, bursts of requests, and service-ticket requests that do not match established account behavior.

MITRE ATT&CK

But a single Event 4769 should not automatically be considered malicious.

Kerberos is constantly generating legitimate service tickets.

The real power comes from context.

Detection Should Look for the Sequence, Not One Event

A stronger detection model asks whether multiple events form a suspicious chain.

For example:

Account attribute modification → SPN appears → TGS request → RC4 ticket → SPN disappears

That sequence is much more interesting than any individual event.

Even better, correlate it with the identity responsible for the directory change, the source workstation, authentication events, and unusual process activity.

This is exactly the type of cross-domain correlation that modern identity-focused detection needs.

Deep Analysis: Defensive Active Directory Investigation

Enumerate Existing SPNs

Administrators can begin with

setspn -Q /

For a more focused investigation of a specific account:

setspn -L username

These commands are useful for auditing and remediation.

The objective is to identify accounts that have SPNs when they should not.

PowerShell Account Auditing

In environments where the Active Directory PowerShell module is installed, defenders can review user accounts containing SPNs:

Get-ADUser -Filter 'ServicePrincipalName -like ""' `
-Properties ServicePrincipalName |
Select-Object SamAccountName, Enabled, ServicePrincipalName

This can help build an inventory of user accounts functioning as Kerberos service principals.

The important question is not simply whether an SPN exists.

The important question is whether the SPN is expected.

Find Accounts Using RC4

Security teams should also investigate accounts and services that still depend on legacy Kerberos encryption.

A useful starting point is Windows Security Event 4769.

For example, administrators can query recent Security logs for Kerberos service-ticket events:

Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4769
} -MaxEvents 500 |
Select-Object TimeCreated, Id, Message

The resulting events should be analyzed for encryption type, requesting account, service account, source system, and frequency.

Microsoft’s current guidance specifically recommends auditing Event IDs 4768 and 4769 when identifying RC4 usage.

Microsoft Learn

Search for Suspicious Bursts

A normal workstation may generate many Kerberos requests.

That means simple threshold detection can generate noise.

A better approach is behavioral.

Look for an account that suddenly requests tickets for numerous services it has never previously accessed.

Then ask whether the same account was involved in recent directory changes.

That correlation can dramatically improve detection quality.

Monitor Directory Changes

Event ID 4769 alone cannot tell the complete Ghost SPN story.

Security teams should also monitor changes to Active Directory objects and sensitive attributes.

A useful detection pipeline should attempt to correlate:

Directory modification

↓

SPN attribute change

↓

Kerberos TGS request

↓

Unusual encryption type

↓

SPN removal

↓

Suspicious endpoint activity

The shorter the time between these events, the more valuable the correlation becomes.

Investigate LSASS Access Carefully

Kerberoasting does not necessarily require credential dumping from LSASS, so defenders should avoid treating LSASS activity as a prerequisite.

However, when suspicious Kerberos behavior appears alongside abnormal LSASS access, credential-dumping indicators, or unusual PowerShell activity, the combined evidence becomes much more concerning.

MITRE’s Kerberoasting detection strategy explicitly recommends correlating ticket anomalies with suspicious process activity and LSASS access.

MITRE ATT&CK

Check Who Can Modify Account Objects

This is arguably the most important defensive investigation.

Find accounts with delegated permissions over other user objects.

The question is not simply:

Who is a Domain Admin?

It is:

Who has the ability to change identity attributes on accounts they do not own?

An attacker does not always need Domain Admin privileges if delegated permissions create another route to the same outcome.

Remove Unnecessary SPNs

If an ordinary user account does not need an SPN, removing it can reduce the attack surface.

Microsoft specifically recommends auditing user accounts with SPNs and removing unnecessary values.

Microsoft

A useful operational policy is:

Every SPN should have an owner, a business purpose, and a documented reason for existing.

Anything that cannot satisfy those requirements deserves investigation.

Prefer Managed Service Accounts

Where architecture permits, organizations should consider Group Managed Service Accounts (gMSAs) and other managed identity mechanisms.

The fundamental advantage is credential management.

Instead of relying on manually maintained service-account passwords that may survive unchanged for years, managed accounts can use automatically managed credentials.

MITRE also lists gMSAs and strong service-account passwords among relevant Kerberoasting mitigations.

MITRE ATT&CK

Strengthen Service Account Passwords

Legacy service accounts with human-created passwords are particularly concerning.

A password such as:

CompanyName2026!

may satisfy a complexity policy while remaining highly guessable.

A properly generated service credential should instead be long, random, unique, and inaccessible to ordinary administrators wherever practical.

The goal is not merely to satisfy a password checklist.

The goal is to make offline guessing economically impractical.

Reduce RC4 Dependence

Microsoft is actively transitioning Windows environments away from RC4, and its current documentation recommends auditing RC4 use before disabling it.

Microsoft Learn

+1

Organizations should therefore treat RC4 as technical debt.

Before disabling it globally, administrators should identify legacy applications and systems that still depend on it.

A safer migration path is:

Discover → Measure → Remediate → Test → Disable

rather than abruptly disabling a legacy protocol and discovering afterward that a critical application has stopped authenticating.

Reset Passwords When Appropriate

Changing a service account password can be important when transitioning older accounts toward modern Kerberos encryption.

Microsoft notes that resetting an account password can generate the AES keys needed by Windows Kerberos.

Microsoft Learn

But password resets should be carefully coordinated with applications and services.

A service account password change without proper dependency mapping can create an outage.

Security improvements must therefore be implemented with operational awareness.

Why Deleting the SPN Is Not Enough

One of the most dangerous misconceptions is that removing the suspicious SPN immediately restores security.

It restores the directory configuration.

It does not necessarily erase what the attacker already obtained.

If a service ticket was already issued, removing the SPN afterward does not retroactively destroy the attacker’s copy of that ticket material.

This is precisely why Ghost SPN emphasizes the importance of historical telemetry.

Identity Telemetry Becomes More Important Than Ever

Endpoint security remains essential.

But endpoint-only security can miss identity abuse that happens legitimately at the protocol level.

A domain controller may see a valid Kerberos request.

Active Directory may see a technically permitted attribute modification.

The endpoint may show nothing obviously malicious.

Only when these data points are combined does the attack become clear.

This is the larger security lesson behind Ghost SPN.

The Attack Is Not About Breaking Kerberos

Kerberos itself is not the enemy.

The protocol is performing exactly what it was designed to do.

The attacker is manipulating the identity configuration surrounding the protocol.

That distinction is critical.

Security teams should not respond by treating every Kerberos ticket as suspicious.

They should identify when legitimate Kerberos functionality is being invoked in an abnormal identity context.

What Undercode Say:

1. The Most Dangerous Attacks Are Often Quiet

Ghost SPN demonstrates that sophisticated attacks do not always need dramatic malware.

2. Identity Has Become the New Battlefield

Modern attackers increasingly target identity infrastructure because it controls access to everything else.

3. SPNs Deserve More Attention

An SPN is not just configuration metadata; it can determine whether an account becomes a Kerberoasting target.

4. Ordinary Accounts Can Become High-Value Targets

A normal user can potentially become interesting to an attacker if its attributes are manipulated.

1. Temporary Changes Can Be More Dangerous Than Persistent Ones

Persistence creates evidence.

Temporary manipulation can create a smaller forensic footprint.

6. Active Directory Permissions Matter

Excessive delegation can create attack paths that traditional privilege reviews overlook.

1. Domain Admin Is Not the Only Dangerous Identity

An attacker may abuse delegated rights without first becoming a Domain Admin.

8. Event 4769 Is Extremely Valuable

Kerberos service-ticket telemetry remains one of the most important sources for detecting Kerberoasting.

1. But Event 4769 Alone Is Not Enough

Without context, legitimate Kerberos activity can look almost identical to malicious activity.

10. Behavioral Detection Is the Future

Security teams should establish baselines for who requests which services.

11. RC4 Should Be Treated as Legacy

Modern environments should steadily reduce their dependence on RC4.

1. AES Helps, But Password Strength Still Matters

Encryption cannot compensate for a terrible password.

13. Service Accounts Need Special Treatment

They should have unique, long, unpredictable credentials and minimal privileges.

14. gMSAs Can Reduce Operational Risk

Managed credentials eliminate many weaknesses associated with manually maintained service passwords.

15. SPN Inventories Should Be Continuous

A quarterly audit may miss a malicious SPN that exists for only a few minutes.

16. Change Monitoring Must Become Near Real-Time

Short-lived identity modifications require short detection windows.

17. Directory Changes Need Security Context

A legitimate administrator making a change during deployment is different from an unusual workstation modifying an account at midnight.

1. Change Management Can Become a Detection Signal

Unauthorized changes outside approved workflows deserve higher scrutiny.

19. Security Teams Need Identity Graphs

Understanding who can modify which accounts can reveal hidden attack paths.

20. Kerberos Logs Should Be Centralized

Domain-controller telemetry should reach the

21. Correlation Beats Isolation

Directory events, Kerberos events, endpoint telemetry, and authentication logs become much more valuable when analyzed together.

22. Offline Attacks Create a Visibility Gap

Once ticket material leaves the environment, traditional authentication monitoring may no longer reveal password-cracking activity.

23. Password Entropy Is Critical

Long random passwords dramatically increase the cost of offline guessing.

24. Legacy Services Need Special Attention

Old applications are frequently the reason organizations continue supporting weaker authentication options.

25. Compatibility Should Not Become Permanent Insecurity

Legacy requirements should be documented, isolated, and eventually removed.

26. SPNs Should Have Business Owners

Every unusual SPN should have someone responsible for explaining why it exists.

27. Unused SPNs Are Security Debt

If a service no longer exists, its SPN should not remain indefinitely.

28. Removing Old Accounts Is Not Enough

Inactive accounts can still become dangerous if they retain useful directory attributes.

29. Privilege Reduction Matters

A compromised service credential becomes far less valuable when the account has minimal permissions.

30. Identity Hygiene Is Preventive Security

Good Active Directory maintenance can eliminate attack opportunities before an attacker discovers them.

1. Ghost SPN Shows the Value of Defense in Depth

No single control is enough.

32. Endpoint Detection Cannot See Everything

Identity-layer attacks may occur without obvious malicious executables.

33. Network Detection Has a Role

Unusual Kerberos traffic patterns can reveal behavior that endpoint agents miss.

34. SIEM Correlation Rules Should Evolve

Rules built only around malware hashes are insufficient for identity-centric attacks.

1. Security Teams Should Hunt for the Sequence

SPN modification followed by TGS activity is much more suspicious than either event alone.

36. Investigations Should Preserve Historical Data

Short-lived changes are impossible to investigate if logs have already disappeared.

37. Identity Monitoring Should Include Delegation

Permission changes can be as important as login events.

38. The Best Defense Is Often Boring

Strong passwords, minimal privileges, managed accounts, modern encryption, and good logging are not glamorous—but they work.

1. Ghost SPN Is a Warning, Not Just a Technique

It shows how attackers can transform legitimate enterprise functionality into a credential-theft mechanism.

40. Active Directory Security Must Become Continuous

The biggest lesson is simple: identity security cannot be treated as a once-a-year audit.

✅ Ghost SPN Is a Real Research Finding

Trellix published research in March 2026 describing the Ghost SPN attack pattern and its use of transient SPN manipulation for targeted Kerberoasting.

Trellix

The research specifically describes attackers temporarily assigning an SPN, obtaining Kerberos ticket material, and then removing the directory artifact.

✅ Kerberoasting Is MITRE ATT&CK T1558.003

MITRE officially tracks Kerberoasting under T1558.003 within the “Steal or Forge Kerberos Tickets” technique family.

MITRE ATT&CK

MITRE also recommends monitoring anomalous TGS requests, RC4 etype 0x17, unusual request volumes, and abnormal service-account targeting.

✅ Event 4769 Is an Important Detection Source

Windows Event ID 4769 records Kerberos service-ticket activity and is specifically used in MITRE’s Kerberoasting detection strategy.

MITRE ATT&CK

+1

Microsoft likewise recommends using Event IDs 4768 and 4769 when auditing RC4 usage.

✅ RC4 Is Being Phased Out

Microsoft is actively transitioning Windows environments away from RC4 and recommends organizations audit their existing dependencies before disabling it.

Microsoft Learn

+1

This makes RC4 reduction an increasingly important part of modern Active Directory hardening.

⚠️ AES Does Not Completely Prevent Kerberoasting

Using AES is a significant improvement over relying on RC4, but it does not make weak passwords immune to offline guessing.

Microsoft explicitly states that AES needs to be combined with strong passwords and proper account security.

Microsoft

⚠️ Removing an SPN Does Not Erase Previously Obtained Material

Deleting the malicious configuration can remove the obvious directory artifact, but it cannot be assumed to destroy ticket material that was already obtained.

That is why historical event correlation is essential when investigating suspected Ghost SPN activity.

Prediction

(+1) Ghost SPN Will Push Organizations Toward Identity-First Detection

As attackers increasingly manipulate legitimate Active Directory functionality rather than deploying obvious malware, security platforms will place greater emphasis on identity behavior, directory changes, and Kerberos telemetry.

Organizations that combine domain-controller logs, directory auditing, endpoint telemetry, and permission analysis will have a much better chance of detecting temporary SPN abuse.

(+1) RC4 Usage Will Continue to Decline

Microsoft’s ongoing effort to move Windows environments away from RC4 will reduce one of the most attractive conditions for traditional Kerberoasting.

As compatibility problems are resolved, more enterprises are likely to enforce AES-based Kerberos configurations and eliminate legacy encryption dependencies.
Microsoft Learn
+1

(+1) Managed Service Accounts Will Become More Important

Organizations are likely to accelerate adoption of managed service identities because they reduce dependence on manually maintained passwords and shrink the number of credentials attackers can target.

(-1) Temporary Identity Manipulation Will Become Harder to Detect

Attackers are likely to increasingly favor short-lived directory modifications, especially when security teams depend heavily on static configuration scans.

The challenge will shift from “What is configured?” to “What changed, who changed it, and what happened immediately afterward?”

(-1) Legacy Active Directory Environments Will Remain Particularly Exposed

Organizations running old applications, weak service-account passwords, excessive delegation, and legacy Kerberos encryption will continue to provide attackers with attractive opportunities.

Ghost SPN is therefore unlikely to be the last identity attack built around a configuration that was originally created for legitimate administrative purposes.

The Bigger Lesson: Active Directory Is No Longer Just an Authentication System

Ghost SPN is a reminder that modern cyber defense cannot stop at malware detection.

An attacker does not always need to install a malicious executable.

Sometimes the most dangerous action is changing a legitimate directory attribute, requesting a legitimate Kerberos ticket, and then cleaning up the configuration before anyone notices.

That is what makes this technique so uncomfortable.

The attacker is not necessarily forcing Active Directory to do something it was never designed to do. Instead, they are manipulating the conditions under which Active Directory performs a completely legitimate operation.

And that changes the defensive question.

It is no longer enough to ask whether an account is privileged.

It is no longer enough to ask whether an SPN exists.

It is no longer enough to ask whether Kerberos is working normally.

Security teams need to understand identity behavior over time.

Who changed the account?

What changed?

How long did the change exist?

Which Kerberos tickets were requested afterward?

Which encryption type was used?

Did the configuration disappear?

Did the requesting workstation behave unusually?

Did the account suddenly access resources it had never accessed before?

Those questions turn an invisible configuration change into a potentially detectable attack sequence.

The future of Active Directory defense will increasingly depend on this kind of correlation. The organizations that monitor identity infrastructure continuously, eliminate unnecessary SPNs, restrict delegated permissions, strengthen service credentials, migrate away from RC4, and adopt managed service identities will be far better positioned to stop Ghost SPN-style attacks before a temporary configuration mistake becomes a permanent compromise.
MITRE ATT&CK
+2
Microsoft Learn
+2

🕵️‍📝Let’s dive deep and fact‑check.

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

References:

Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.quora.com
Wikipedia
OpenAi & Undercode AI

Image Source:

Unsplash
Undercode AI DI v2

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeNews & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube