Hello,
It was my first time running RelayKing in a live environment today and it found some goodies! Thanks for making such a cool tool! I got excited it found a potential ghost SPN, and then after stepping through the attack path slowly, it turned out to be a false positive.
Some of the technical bits make my head spin, so forgive me but I had AI help write the following issue - please let me know if you have any questions and/or want me to try anything else in this client environment (I have through next week):
AI WROTE THIS...PLEASE DON'T BEAT ME UP:
The Ghost SPN module reports a false positive for the DRS (directory replication) SPN that every DC holds. It appears to take the middle field of a three-part SPN — the DSA GUID — and treat it as the hostname, then check DNS for .. That name never exists, so it's flagged as an unregistered ghost with a "register DNS to intercept auth" action.
The SPN in question (well-known DRS service class GUID E3514235-4B06-11D1-AB04-00C04FC2DCD2):
E3514235-4B06-11D1-AB04-00C04FC2DCD2//
This is serviceclass / instance / servicename, where the instance is the DC's NTDS Settings objectGUID.
Reported finding:
Account : $
SPN : E3514235-4B06-11D1-AB04-00C04FC2DCD2//
Hostname : . <-- synthesized, never existed
Action : Register DNS '.' to intercept auth
Why it's a false positive
The DSA GUID is not a hostname. Its legitimate DNS presence is a CNAME under _msdcs, not a flat A record under the domain root:
._msdcs. CNAME . (resolves fine)
. NXDOMAIN (never existed; this is what RK checks)
Confirmed against the authoritative DC DNS: the _msdcs CNAME resolves to the live DC, so the underlying SPN is fully backed by DNS. Nothing is registerable and there's no relay primitive — the flagged hostname is an artifact of the parse.
Suggested fix
Recognize the well-known DRS service-class GUID E3514235-4B06-11D1-AB04-00C04FC2DCD2 and exclude these SPNs from ghost-checking; or
For any _msdcs/replication SPN, resolve the DSA GUID as ._msdcs. (following the CNAME) rather than appending the domain suffix to the GUID.
Hello,
It was my first time running RelayKing in a live environment today and it found some goodies! Thanks for making such a cool tool! I got excited it found a potential ghost SPN, and then after stepping through the attack path slowly, it turned out to be a false positive.
Some of the technical bits make my head spin, so forgive me but I had AI help write the following issue - please let me know if you have any questions and/or want me to try anything else in this client environment (I have through next week):
AI WROTE THIS...PLEASE DON'T BEAT ME UP:
The Ghost SPN module reports a false positive for the DRS (directory replication) SPN that every DC holds. It appears to take the middle field of a three-part SPN — the DSA GUID — and treat it as the hostname, then check DNS for .. That name never exists, so it's flagged as an unregistered ghost with a "register DNS to intercept auth" action.
The SPN in question (well-known DRS service class GUID E3514235-4B06-11D1-AB04-00C04FC2DCD2):
E3514235-4B06-11D1-AB04-00C04FC2DCD2//
This is serviceclass / instance / servicename, where the instance is the DC's NTDS Settings objectGUID.
Reported finding:
Account : $
SPN : E3514235-4B06-11D1-AB04-00C04FC2DCD2//
Hostname : . <-- synthesized, never existed
Action : Register DNS '.' to intercept auth
Why it's a false positive
The DSA GUID is not a hostname. Its legitimate DNS presence is a CNAME under _msdcs, not a flat A record under the domain root:
._msdcs. CNAME . (resolves fine)
. NXDOMAIN (never existed; this is what RK checks)
Confirmed against the authoritative DC DNS: the _msdcs CNAME resolves to the live DC, so the underlying SPN is fully backed by DNS. Nothing is registerable and there's no relay primitive — the flagged hostname is an artifact of the parse.
Suggested fix
Recognize the well-known DRS service-class GUID E3514235-4B06-11D1-AB04-00C04FC2DCD2 and exclude these SPNs from ghost-checking; or
For any _msdcs/replication SPN, resolve the DSA GUID as ._msdcs. (following the CNAME) rather than appending the domain suffix to the GUID.