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.

Edit: Useful? Check out our training :)