• Active Directory Attacks
  • Jul 29, 2018

Golden Ticket Attack Execution Against AD-Integrated SSO Providers

Golden Ticket Attack Execution Against AD-Integrated SSO Providers


The broad movement towards identity-centric security is being accelerated by architectural shifts towards a zero-trust environment with point-to-point encryption between services and users. The shift to cloud and SaaS offerings—which are an important part of most users’ daily activities—is well underway. Despite more cloud-centric user experiences, Active Directory remains a critical part of most modern enterprises, and many cloud identity solutions and applications integrate with Active Directory via some federation scheme. Major recent breaches in private industry and government demonstrate the importance of securing Active Directory Infrastructure. For those not familiar, the EU-CERT papers describe in detail that Advanced Persistent Threats are widely using Kerberos and Active Directory exploitation to persist and enable lateral movement in enterprise networks (see e.g. Lateral Movements PDF and Kerberos Golden Ticket Protection.

The reality is that tools like Mimikatz, Kekeo, CrackMapExec, Deathstar, and others have helped to commoditize sophisticated attack vectors such that any reasonable actor with basic knowledge of scripting can achieve effects once limited to elite threat actors. It is also increasingly common to see such forms of credential compromise bundled in ransomware, wipers, and other malware to increase the ability of software to spread to otherwise non-vulnerable hosts.

While the EU-CERT guidance regarding the use of Windows Event Logs from Domain Controllers (DCs) to do very basic instrumentation of Active Directory (AD), these logs cannot be trusted in a number of realistic and commonly seen attack scenarios. This means that unless a security operations team is doing sophisticated behavioral analysis at the Kerberos protocol level (with instrumentation on actual Domain Controllers), they are likely to miss key attack types leveraging these more recent tools and techniques. Practical limits from the challenge of exchanging shared secrets across an untrusted network enable attackers to continue to abuse fundamental weaknesses in Kerberos, and in Active Directory as the most widely used Kerberos implementation in the world. Tools for exploitation are being consistently developed, used on real targets, and enhanced.

Given the lack of alternatives to underpin authentication in modern IT enterprises, any organization serious about defending its network will need to address these key gaps. This post is meant to introduce some basic fundamental security issues with Kerberos while diving into more specifics regarding how AD federation can unintentionally increase attack surface, regardless of what tool or service is integrated via a supported federation approach.

Golden Ticket Attack Execution

Many organizations depend on third-party Single Sign-On (SSO) providers to improve user experience by requiring only a single authentication to access numerous protected services. SSO providers typically accomplish this by integrating directly with Windows Active Directory and its use of the Kerberos authentication protocol.

In the exercise below, we walk through the steps used to demonstrate the ability to successfully execute a Golden Ticket attack against two common SSO providers (Auth0 and Okta).

It should be noted that this post is exclusively about vulnerabilities of the underlying authentication schema trusted by SSO services in general and the unintended consequences that may arise from federated services. It is not a critique of any SSO vendor. SSO services are important mechanisms to improve user experience and ease of management. They are transport services to extend an authentication solution, not designed to mitigate any underlying vulnerabilities in the authentication framework itself. For more information, see the Okta Security Technical White Paper.


Verification of Valid User Login via Auth0:

First, we want to demonstrate normal SSO behavior for a valid user. Below we see in the ‘User Details’ in Auth0 settings that the account associated with the email “user(blurred)@qomplx.com” is linked to the SAM account “artem” for the domain “DCC.local”:

auth0 valid user

Also shown is the user_id value for user “artem”:

auth0 userId

‘SSO Integrations’ in Auth0 settings show the URL one would use to access the SSO page for Dropbox:

Drop Box configuration screen

Navigating to this URL shows the email that is linked with the “artem” account having been used previously to log into Dropbox for Business:

Dropbox login

The email used to authenticate on Dropbox links to an account for “Clark Kent” (arbitrarily named in Dropbox ‘User Accounts’):

Drop Box authenticate screen

At this point, we log out of Dropbox, clear browser data, and start Wireshark network traffic capture utility with a filter for Kerberos, HTTPS and Auth0 AD/LDAP agent traffic:

Drop Box kerberos screen

We launch SSO portal for Dropbox and allow it to use windows credentials:

Dropbox SSO portal

Authentication passes the SSO provider and redirects to the Dropbox SAML page with the expected email for user “artem”:

Dropbox Single Sign on

Logging in takes us to the same account as shown before:

Drop Box redirect account screen

We log out, clear browsing data, and examine Wireshark results to confirm valid login:

Wireshark Window

Golden Ticket Attack Initiation Against Auth0:

Now we want to execute a Golden Ticket attack, successfully log on to Dropbox with forged credentials, and examine the logs to demonstrate how this traffic appears to be perfectly valid.

First we log in as a local admin with no domain rights on the same computer that was shown being used properly in the previous section, as demonstrated with ‘whoami’ command:

Whoami command in terminal

We start Wireshark and filter for Kerberos, Auth0 AD/LDAP agent traffic:

Golden ticket agent traffic

Next we attempt to log into SSO for Dropbox with credentials assigned to this account and fail, in this case falling back to NTLM:

Dropbox login window

Wireshark shows that SSO returned “Unauthorized” errors:

Unauthorized wireshark screen

We reset browser data to remove failed session cookies, then execute Mimikatz:

Mimikatz window

Purge tickets in an adjacent window to avoid cross-contamination:

Purge wireshark window

Paste Golden Ticket injection command:

Golden Ticket Injection window

Switch to the Domain Controller to show that the krbtgt hash is really from this domain, and that the SID and RID match for the user being impersonated:

Wireshark window on golden ticket attack

Switching back to the attacking computer, we launch the same Dropbox SSO link as before (where access was disallowed previously) from the PowerShell window with the Golden Ticket in the session:

GT attack on Dropbox

Click Use Windows Credentials button as before:

Dropbox Login

Wireshark shows Golden Ticket sent in TGS_REQ:

Golden Ticket TGS wireshark

Using Wireshark we see the actual forged ticket:

Wireshark forged ticket

Here we see that the DC responded to the forged ticket as if it was for the user “artem”:

Artem DC response window

…and that the service ticket just granted was sent over HTTP to the Auth0 AD/LDAP agent:

GT attack success window

The Auth0 AD/LDAP agent responds with a “200 OK” HTTP response, thus accepting the forged ticket presented previously:

HTTP response

Next we log into Dropbox with SSO:

SSO login

…and confirm we’re logged in as the same Dropbox account as previously used:

Dropbox Confirm Login

Looking again at ‘User Details’ in Auth0 settings, we see the user_id is the same as its initial value in the beginning of this document:

Auth0 user ID window

Finally we examine of Auth0 logs to compare the last login attempt to the previous two attempts:

Auth0 full log comparison

The user_id from most recent attempt with the forged ticket (4 minutes ago according to the ‘Logs’ screen in the Auth0 UI above) is shown below:

user ID displayed

The two previous, valid login attempts that took place 16 and 19 minutes ago per the ‘Logs’ screen on the Auth0 UI (see different “log_id” values) show the same login_id values as the login attempt using the forged Golden Ticket:

User ID displayed

One of the key takeaways here is that the forged ticket appears exactly the same as valid authentication attempts across all associated logs, making even forensic detection of Golden Tickets exceedingly difficult.


Next we’ll demonstrate a Golden Ticket attack against Okta. But first, it’s important to understand the data flow that takes place during these transactions involving third-party SSO providers:

Okta flowchart

Source: Okta Documentation

In the case of a Golden Ticket attack, the Kerberos credential in Step 5above is the forged Golden Ticket.

Golden Ticket Attack Initiation Against Okta:

We begin by confirming the url for SSO and showing that DCC.local is federated:

GT attack against okta

We launch a Chrome session to the SSO url:

launch chrome session

…and see that the user is unable to log on:

Failed Okta Login

After clearing browser history, we execute Mimikatz and inject the Golden Ticket for user ssam@DCC.local (which is also linked to the “user(blurred)@qomplx.com”  address):

Mimikatz execution window

We again launch a Chrome session to the SSO url, this time with the forged Golden Ticket being submitted:

Ticket Submission google chrome

This time, the login is successful (with “simple” being the first name for user “Simple Sam” which was the user “ssam” that was tested previously):

Succesful login SSam

Examination of Wireshark logs shows the TGS_REQ associated with the Golden Ticket attack:

Wireshark logs

…as well as the TGS_REP for user “ssam”:

TGS_REP for simple sam window


Third-party Single-Sign-On (SSO) systems provide convenience to users by linking existing authentication infrastructure to cloud services. However, it’s important to understand that by anchoring cloud service authentication to existing services, companies are effectively extending their network perimeter and thereby increasing their overall exposure. As shown here, techniques such as Golden and Silver Ticket attacks can easily be extended to cloud services linked to Active Directory authentication.

With readily available tools like Mimikatz, it’s alarmingly easy for threat actors to forge Kerberos tickets that enable them to traverse the network as an authenticated, valid user. That’s what makes these techniques nearly impossible to detect—without a “paper trail” of ticket exchanges there’s virtually no sign of a compromise. Even Windows Event Logs record forged tickets as valid. As a result, Golden Ticket attacks are often still just a “best guess” as the only possible explanation for a breach, after everything else has been ruled out. Because if you can’t verify the authentication process, how can you know for sure?

By extension, how can you trust anything your logs are telling you if you can’t trust the authentication event itself? Without knowing for sure that users are who they claim to be, your entire cybersecurity posture is put into question. For particularly devastating compromises like Golden Ticket and other lateral movement attacks, security analysts are historically reduced to making heuristics-based guesses according to vague notions of anomalous behavior. More false positives, more alert fatigue, more successful attacks…

QOMPLX:CYBER was designed and built from the ground up to break this cycle.

Additional Resources

Kerberos-Based Attacks and Lateral Movement

Kerberos Attacks: What you Need to Know
Detecting Lateral Movements in Windows Infrastructure
Kerberos Golden Ticket Protection: Mitigating Pass-the-Ticket on Active Directory
MIT Kerberos: The Network Authentication Protocol
Return from the Underworld: the Future of Red Team Kerberos
Abusing Microsoft Kerberos: sorry you guys don’t get it

Mimikatz Attacks

Tales of a Threat Hunter 1: Detecting Mimikatz & other Suspicious LSASS Access - Part 1

Active Directory Security

Active Directory Security: Active Directory & Enterprise Security, Methods to Secure Active

2016 Attack on the Office of Personnel Management

Inside the Cyberattack That Shocked the US Government
Technical Forensics of OPM Hack Reveal PLA Links to Cyberattacks Targeting Americans

2015 Cyberattack on the DNC

Bears in the Midst: Intrusion into the Democratic National Committee

©2019 QOMPLX All Rights Reserved.

You might also be interested in

Lessons from the Medibank breach

Lessons from the Medibank breach

Ming Fu, a member of the Americas Pre-Sales Engineering Team at QOMPLX, looks at the much publicized Medibank breach in Australia last year, and draws a few much needed lessons based on the published findings of this breach.

Read more
IcedID Malware Gaining Prominence by Adding Identity Attack Chains

IcedID Malware Gaining Prominence by Adding Identity Attack Chains

Brian Freedman, WW Director of Solution Architecture highlights how identity controls are necessary tools, along with EDR, to combat evolving malware threats that have been expanding to include identity compromise as a primary objective in their attack strategies.

Read more
Active Directory is Your #1 Cyber Risk. Start Treating It That Way.

Active Directory is Your #1 Cyber Risk. Start Treating It That Way.

If Active Directory is so critical, why do so many firms take a hands off approach to AD security? In our latest report, we explore that issue and offer some steps organizations can take to secure it.

Read more
Request a Demo

Interested in learning more?

Subscribe today to stay informed and get regular updates from QOMPLX.