Listen to this Post
Introduction:
A newly disclosed attack technique, dubbed “Ghost SPN,” has emerged as a significant threat to Active Directory environments. This method allows adversaries to perform Kerberoasting—a common attack that extracts password hashes for service accounts—without generating the standard Windows audit events that security tools like SIEMs and EDRs rely on for detection. For organizations, this means a core identity management system can be compromised without leaving a trace in conventional security logs.
Learning Objectives:
- Understand the technical mechanics of the Ghost SPN attack and how it differs from traditional Kerberoasting.
- Learn to identify the gaps in standard Active Directory monitoring that this attack exploits.
- Acquire actionable detection and mitigation strategies, including specific Event Log IDs, PowerShell commands, and Group Policy configurations.
You Should Know:
1. Dissecting the Ghost SPN Attack Mechanics
Traditional Kerberoasting works by requesting a Kerberos Ticket Granting Service (TGS) ticket for a service account. This request generates Event ID 4769 (A Kerberos service ticket was requested) in the Windows Security log, which is the primary indicator used by SIEMs. Ghost SPN, as revealed by researchers, manipulates this process to request TGS tickets in a way that bypasses the logging mechanism for that event.
To understand the landscape, an attacker with a foothold in a domain (as any authenticated user) would typically use a command like the following from a Windows machine to request tickets:
Traditional Kerberoasting using built-in tools Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "HTTP/webserver.domain.com"
For the Ghost SPN variant, the exploitation is more subtle. While the exact public exploit code is still under analysis, the principle involves altering the service principal name (SPN) request or leveraging specific pre-authentication flags that cause the Domain Controller to skip logging. Security teams must look for anomalies like:
– TGS-REQ packets in network captures with unusual sname (service name) characteristics.
– TGS-REP packets that are not preceded by the expected AS-REQ/AS-REP (Authentication Service exchange) for that service.
A Linux-based attack using `impacket` often leaves different traces. However, for Ghost SPN, defenders should monitor for `Get-NetUser` or `Get-NetUser -SPN` commands used in reconnaissance, as the attack is a specialized follow-up:
On a Kali Linux box using impacket impacket-GetUserSPNs -request domain.com/user
To detect this, focus on the volume and pattern of TGS requests. Using PowerShell to audit for unusual SPN requests can be a starting point:
Enumerate SPNs in the domain for potential targets
Get-ADUser -Filter {ServicePrincipalName -like ""} -Properties ServicePrincipalName | Select-Object Name, ServicePrincipalName
Check for recently created SPNs which could be a setup for the attack
Get-ADObject -Filter 'ObjectClass -eq "serviceConnectionPoint"' -Properties Keywords, ServiceBindingInformation
2. Detection Evasion and Logging Gaps
The core of Ghost SPN lies in its ability to suppress the 4769 event. This is achieved by manipulating the ticket request to be for an account that is configured in a specific, non-default way within the AD schema or by exploiting a race condition in how the Domain Controller logs versus how it processes the request.
To verify if your environment is generating the necessary events, you can use `wevtutil` to query for the specific Event IDs:
Windows Command Line - Query for Kerberos Ticket Events wevtutil qe Security /f:text /c:5 /rd:true /e:Security /q:"[System/EventID=4769]"
If the attack is successful, you will see no or a significantly reduced number of 4769 events for the compromised service account. This creates a “black hole” in your logs. The alternative detection method is to monitor Event ID 4768 (A Kerberos authentication ticket was requested) for anomalies. A successful Ghost SPN attack might still generate a 4768 event for the initial user authentication, but the subsequent 4769 for the service ticket request disappears.
3. Strategic Detection: Network and Behavioral Analysis
Since the primary audit logs fail, defenders must shift to network-level and behavioral analytics. Use network monitoring to capture and inspect Kerberos traffic. This can be done with tools like Wireshark, filtering for Kerberos (port 88) traffic.
A key indicator is an AS-REQ (Ticket Granting Ticket request) followed by an abnormal number of TGS-REQ requests without matching AS-REQ for those target services. An attacker using Ghost SPN will generate a TGS-REQ that does not have a preceding AS-REQ for that specific service principal, which is a strong behavioral anomaly.
On a Linux system, you can use `tcpdump` to capture this traffic and then analyze it:
Capture Kerberos traffic to a file for analysis sudo tcpdump -i eth0 port 88 -w kerberos_traffic.pcap Analyze with tshark to extract unique service names (snames) tshark -r kerberos_traffic.pcap -Y "kerberos.msg_type == TGS-REQ" -T fields -e kerberos.sname
Comparing this output against known service accounts in your environment will reveal if unknown or unregistered SPNs are being targeted.
4. Active Directory Hardening and Mitigation
Prevention remains the best defense. The primary mitigations for Kerberoasting, including Ghost SPN, are robust service account management. Enforce the use of Group Managed Service Accounts (gMSA) or standalone MSA where possible. These accounts have complex, automatically rotated passwords that make the hash obtained via Kerberoasting useless to an attacker.
To implement gMSA, use PowerShell from a Domain Controller:
Create a Key Distribution Service (KDS) Root Key Add-KdsRootKey -EffectiveImmediately Create a gMSA New-ADServiceAccount -Name "Svc_App01" -DNSHostName "svc-app01.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Admins"
If gMSA is not feasible, ensure service accounts have long, complex passwords (25+ characters) that are regularly rotated. Additionally, apply the principle of least privilege by ensuring service accounts have only the necessary permissions.
A critical Group Policy setting to review is “Kerberos: Don’t allow Kerberos to use DES encryption”. Ensure DES is disabled, as it weakens Kerberos security:
Group Policy Path: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options Set "Network security: Configure encryption types allowed for Kerberos" to only allow AES128 and AES256.
5. Enhanced Monitoring with Sysmon and Advanced Logging
To catch the precursors to Ghost SPN, increase your logging fidelity. Install and configure Sysmon with a configuration that logs process creation, network connections, and file creation events. This can help detect the tools used to stage the attack (e.g., mimikatz, Rubeus, or custom PowerShell scripts).
A simple Sysmon config to include can be installed with:
Download Sysmon and a recommended configuration (e.g., from SwiftOnSecurity) Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig.xml" -OutFile sysmonconfig.xml .\Sysmon64.exe -accepteula -i sysmonconfig.xml
With Sysmon, you can then monitor for suspicious process creation events (Event ID 1) that involve tools like `Rubeus.exe` or specific PowerShell command lines. For example, a `Rubeus kerberoast` command will appear in the process command line, providing a clear alert despite the lack of a 4769 event.
6. Implementing Kerberos Armor and Forest Trusts
For high-security environments, consider implementing Kerberos Armor, which encrypts the entire Kerberos exchange, making it harder for an attacker to sniff or modify ticket requests. While this doesn’t prevent the attack, it adds a layer of complexity.
Also, review the Forest Trust configuration. The Ghost SPN technique might leverage trust relationships to request tickets across domains. Use the `Active Directory Domains and Trusts` console to review trust settings and ensure that selective authentication is enabled, preventing unintended ticket requests across forest boundaries.
What Undercode Say:
- Key Takeaway 1: Traditional security monitoring relying solely on Windows Event IDs (especially 4769) is insufficient; attackers now have methods to bypass these foundational logs.
- Key Takeaway 2: Proactive defense hinges on modern identity management—migrating to gMSA, enforcing AES encryption, and adopting behavioral and network-level detection for Kerberos traffic.
Analysis: The Ghost SPN technique highlights a critical evolution in Active Directory attacks. It shifts the detection burden from simple log monitoring to a deeper understanding of Kerberos protocol mechanics and anomaly detection. For defenders, this means integrating network analysis tools (like Zeek or Suricata for Kerberos traffic) and adopting a zero-trust approach to service accounts. The core vulnerability is not a protocol bug but a design limitation in auditing, forcing security teams to rethink their visibility into identity infrastructure. The long-term fix involves Microsoft potentially updating the logging mechanism, but until then, organizations must implement the layered controls outlined here.
Prediction: The Ghost SPN attack will catalyze a shift in how enterprise detection engineering is done. We will see a surge in the adoption of Network Detection and Response (NDR) solutions that analyze Kerberos traffic natively, as well as increased pressure on Microsoft to provide more granular and tamper-proof logging for all Kerberos operations. Additionally, this will accelerate the deprecation of traditional service accounts in favor of automated, managed identities across both on-premises and cloud environments.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersaezcuritaez Engagaeze – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
