Golden Ticket Attack Execution Against AD-Integrated SSO providers

29 July 2018

Background

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.

Auth0

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 “metropolis@fractalindustries.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:

auth0 dropbox

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

auth0 dropbox sign-in

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

auth0 dropbox authenticate

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:

auth0 dropbox kerberos filter

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

auth0 dropbox sso portal

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

auth0 dropbox redirect

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

auth0 dropbox redirect account

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

auth0 dropbox confirm login

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:

GT attack execution

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

GT attack 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:

GT attack login attempt

Wireshark shows that SSO returned “Unauthorized” errors:

GT attack Wireshark unauthorized error

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

GT attack execute mimikatz

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

GT attack purge tickets

Paste Golden Ticket injection command:

GT attack injection command

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:

GT attack krbtgt hash

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 dropbox sso link launch

Click Use Windows Credentials button as before:

GT attack windows credentials

Wireshark shows Golden Ticket sent in TGS_REQ:

GT attack TGS REQ

Using Wireshark we see the actual forged ticket:

GT attack Wireshark forged ticket

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

GT attack DC response

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

GT attack ticket success

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

GT attack ticket success http response

Next we log into Dropbox with SSO:

GT attack dropbox sso login

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

GT attack dropbox confirm

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:

GT attack Auto0 user details

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

GT attack Auto0 logs

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:

GT attack Auto0 logs userID

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:

GT attack Auto0 logs logID

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.

Okta

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:

In the case of a Golden Ticket attack, the Kerberos credential in Step 5 above 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:

see user login

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

mimikatz inject golden ticket

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

launch chrome session to sso

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):

simple sam

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

wireshark logs show TGS_REQ

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

TGS_REP for ssam

Conclusion

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…

ACDP 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

©2018 Fractal Industries, Inc. All Rights Reserved.