Golden Ticket Attacks & 2FA
Golden Ticket Attacks & 2FA
Using 2FA to Turn the Tides on a Golden Ticket Attack
When an attacker gains access to a Windows server, that server can easily be turned into a weapon to be used against your infrastructure and data. And of all the ways that can be done, one of the most severe attacks that can be performed is the golden ticket attack, which allows the attacker to create users with arbitrary permissions and from there, gain access to any domain-controlled resource.
First, what is a golden ticket attack? Without going into the deep dark details of Kerberos, Windows’ authentication infrastructure relies on a special service account named KRBTGT. This account is used to encrypt and sign all Active Directory (AD)-related authentication information for users. It’s possible to hijack this account by gaining access to its password hash and then use it to generate a forged ticket granting ticket, then use it to create new users with arbitrary permissions (almost always a domain admin permission set). Once this happens, the attacker now has full access to the Windows based infrastructure of the targeted organization. MITRE has more details here.
Once an attacker has been able to compromise the DC and start forging tickets, it becomes very difficult to stop the ongoing compromises as any new domain-joined Windows machine can be compromised at will. This is something we’ve ended up getting a fair bit of familiarity with. While we were working with a customer who was affected by this attack, we had found ourselves in something of a loop – we’d work with our customer to build a new, un-compromised machine then watch it get broken into almost immediately. Trying to track down what was happening ended up being tricky, but we were able to identify this behavior as an ongoing golden ticket attack.
Once we knew what we were dealing with, the next steps were to figure out how to break the ongoing attack chain and begin the process of digging the attackers’ footholds out of our customer’s infrastructure. We needed to find some way to ensure that a fraudulently created set of credentials would no longer be able to log into a Windows machine long enough that we could execute a KRBTGT account password reset (the industry-standard process is two password resets, 12 hours apart) and stop the ongoing compromises. Our customer had not deployed any MFA system prior to the intrusion, so an emergency Cisco Duo deployment looked like an interesting avenue for stopping the attackers. Looking at how users were enrolled into Duo, we saw how to break that attack chain – users would not be auto-enrolled into Duo, so any fraudulent user created by the attackers would find themselves unable to pass the new MFA requirement. Only the users that our team explicitly added to Duo were able to pass the MFA requirement and gain access to the Windows domain controllers. Once we saw that the attackers were no longer able to compromise machines, we then executed the KRBTGT password resets and – finally – put a halt to the recurring compromises and make real headway on cleaning up the intrusion.
When we talk about MFA, it’s usually in a proactive context or as a post-cleanup hardening effort. In this case, though, MFA gave us the breathing room we needed to get ahead of the attackers and disrupt their attack chain. We always recommend that every customer use MFA to protect infrastructure admin access, though – a good amount of pain that our customer experienced would have been avoided entirely had MFA been in place pre-intrusion. But, if MFA hasn’t been deployed and there is an ongoing intrusion, be aware that MFA systems can be a potent tool in breaking up an ongoing intrusion attempt – just getting some breathing room is often all that’s needed to get more durable remediation efforts started.
