Golden Ticket Attack Execution Against AD-Integrated SSO providers

[Nytro]

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

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

‘SSO Integrations’ in Auth0 settings show the URL one would use to access the SSO page for 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:

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

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:

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

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

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

We log out, clear browsing data, and examine Wireshark results to confirm valid 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:

We start Wireshark and filter for Kerberos, Auth0 AD/LDAP 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:

Wireshark shows that SSO returned “Unauthorized” errors:

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

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

Paste Golden Ticket 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:

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:

Click Use Windows Credentials button as before:

Wireshark shows Golden Ticket sent in TGS_REQ:

Using Wireshark we see the actual forged ticket:

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

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

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

Next we log into Dropbox with SSO:

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

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:

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

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:

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:

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:

Source: https://support.okta.com/help/Documentation/Knowledge_Article/Install-and-configure-the-Okta-IWAWeb-App-for-Desktop-SSO-291155157

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:

We launch a Chrome session to the SSO url:

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

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

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

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

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

…as well as the TGS_REP for user “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.

 

Sursa: https://www.fractalindustries.com/newsroom/blog/gt-attacks-and-sso