Kerberos Party Tricks: Weaponizing Kerberos Protocol Flaws

This is a quick run-down for anyone who missed my talk at LayerOne this year

Background

The vulnerabilities and techniques are based on abuse of the Kerberos v5 protocol, but all of this should work on earlier versions too. In my mind, these kinds of bugs are better than memory corruption exploits because they are unlikely to get fixed and are hard to patch out.  As a bonus Kerberos is the underlying mechanism for all of the multi-factor authentication schemes in Windows, e.g. RSA SecureID, smart-card, biometrics, etc and once we get a Kerberos ticket for the user, we can bypass all of that other stuff. We also never send any packets to the target systems to do this, only to the domain controller so these techniques are super stealthy and are unlikely to ever get identified by an IDS, IPS, or other attack detection tool.

I tested against Windows Server 2008 and 2012, but all of these attacks are likely to apply to other implementations too (MIT, Heimdal, Centrify, etc.)

Kerberos party tricks toolkit capabilities

  • Enumerate/brute force domain users
  • Get Kerberos TGS-REP and AS-REPs interactively
  • Parse PCAPs for Kerberos tickets
  • Identify accounts with weak pre-auth configurations
  • Crack account passwords
  • Enumerate services on the domain (SPN scan)

So how do we do all of these things?

User enumeration

We brute force usernames from by sending legacy Kerberos V4 Authentication Requests (AS-REQ) and examine the error codes to determine if a user exists, if they are locked out, and if they have "Do not use Kerberos pre-authentication" set.  If the user has "Do not use Kerberos pre-authentication" set, then we recover an Kerberos AS-REP encrypted with the users RC4-HMAC'd password.  We can attempt to crack this ticket offline.  As a bonus, this does not trigger Microsoft's account lockout policy.

Recover Kerberos tickets interactively and from packet captures

Just like before, if we know a user has "Do not use Kerberos pre-authentication" set, then we recover an Kerberos AS-REP encrypted with the users RC4-HMAC'd password. With authentication, we can request "Service Tickets" or TGS-REP.  As with the AS-REPs, these are encrypted with the service account's password, but any user can request a ticket for any service. Even if they are not authorized to use it.  This is because the service is responsible for determining who is authorized to access it and the Key Distribution Center (KDC), typically the domain controller, is only responsible for creating and controlling the tickets and not determining access levels.

We can also parse PCAP style packet captures for encrypted AS-REPs and TGS-REPs.

Identify accounts with weak pre-auth configurations

We can search the LDAP directory for accounts with a specific account setting, if we have domain authentication. We can then request AS-REPs for those accounts. 

Crack passwords offline

Because all of the tickets are signed with the RC4-HMAC'd version of the account's password, we can take a wordlist, run it through the RC4-HMAC algorithm, and compare the values.  If they match, we know the password!

We can do this with any of the tickets we have recovered, either directly through interaction or from packet captures.

Enumerate services on the domain (SPN scan)

Active Directory uses “Service Principal Names” (SPNs) to register user accounts with “services”.  A SPN looks something like:

  • Service Type/host.domain.com:port

For example. the SPN below represents a Microsoft SQL server running on port 1433 on a system named domainw7.onlyfor.hax.  

  • MSSQLSvc/domainw7.onlyfor.hax:1433

We can use LDAP to lookup all of the SPNs in a domain and determine the username of the service, the groups that the account is in, the type of service, the host it is running on, and the port we need to connect to so that we can access the service.

You may be asking why all of this is in Active Directory.  It is because it allows “Single Sign On” (SSO) for domain services.  For example, when user wants to connect to service X they request a ticket from the Key Distribution Center (KDC), typically the Domain Controller.

Once you have account and passwords for a service you can generate a Silver Ticket with Mimikatz and impersonate any user to that service since the key is considered a shared secret between the service account and the KDC.  We can't create a legitimate Privileged Attribute Certificate (PAC), but we don't have to.  This is because the services never validate the PAC with the KDC for performance reasons.  If they did, they would have to send every ticket for every request to the KDC and wait for it to validate the connection, creating a huge amount of work for both the service and KDC. 

If you happened to recover the password for a domain admin, you can user mimikatz to inject a ticket into your current session, impersonate another domain controller, and ask it to synchronize the account database with you. You end up with the encrypted versions of the passwords for any domain user without getting a shell and it all happens over RPC!

Slides and toolkit are here.

Join EXUMBRA @ ISSA Ventura

Join us at ISSA Ventura on June 25th for a Penetration Testing 101 and live demos.

We will be demonstrating methods to find and exploit:

  • Misconfigurations
  • Missing patches
  • Plain-text Credentials 
  • File Permissions
  • Local Services
  • Network Services

Date: Saturday June 25th 9am to 5pm
Location: 
Cal Lutheran University
60 West Olsen Road : Ullman 101
Thousand Oaks, CA 91360

Don't forget to install the extra tools, instructions are here.

Penetration Testing training Dec 14-18 2015

We are running a 5 day penetration testing course in the Los Angeles area starting December 14th.  

Contact us to schedule!

Course Outline

Day 1

  • Introduction & Setup
  • Methodology
  • Reconnaissance
  • Exploitation
  • Metasploit Basics part 1

Day 2

  • Metasploit Basics part 2
  • Unix Privilege Escalation

Day 3

  • Windows Privilege Escalation
  • Metasploit Post Exploitation
  • Windows Domain Exploitation

Day 4

  • Post exploitation w/o Metasploit
  • Pivoting
  • Layer 2/3 attacks, combo attacks

Day 5

  • Network Tradecraft
  • Web Exploitation

 

One Team. Two Team. Red Team. Blue Team.

Like many areas in the tech industry, a lot of jargon gets used in Information Security.  You may have heard the terms ‘Red Team’ or ‘Blue Team’ or maybe even ‘Purple Team’ get thrown around, but what do they actually mean? 

Well, first some background, the terms originate in with the military where they do exercises all of the time and have, not surprisingly, lots of jargon to go along with it.  In this scenario, the ‘Blue Force’ is your military and the ‘Red Force’ is the opposing military.  We then borrow those colors to identify which side you are modeling in a penetration test, so a ‘Red Team’ assessment is conducted from the perspective of a potential attacker.

Red Team’ assessments typically includes areas that go well beyond a network penetration test and include techniques like Social Engineering, lock and access control bypass, tailgating, creating fake badges, covert data exfiltration, in addition to the live exploitation executed during a network penetration test.  This type of assessment models an aggressive first-world intelligence service and leverages everything can they can throw at you.  Ultimately, the team will attempt to exercise all of an organizations defenses.  It is an intense, thorough, and eye-opening experience for many organizations.

Conversely, a ‘Blue Team’ assessment is conducted as a friendly insider with access to engineers, designs, and documentation.  This allows the ‘Blue Team’ to cover a much larger number of potential vulnerabilities, but will not exercise the defenses of an organization and will not give an outside perspective of the security posture.  These types of assessments are also typically more driven by documentation and process, whereas a ‘Red Team’ is solely practically focused.

A ‘Purple Team’ is, not surprisingly, a mix of the two, with some exploitation as would be conducted by a ‘Red Team’ and an open look at process and design as conducted by a ‘Blue Team’.

What is right for you