All Articles

Password, AD, and the like

Hello, Windows password!

To start it off on a simple note, every computer have some type of password. When you first set up your local account for Windows, the password you put in will be the password you use to unlock your screen, elevate your Windows privilege, run as admin, and all that jazz.

That, is known as a local password. Local password are stored in a SAM database.

Then you go to work, and then you get a work-issued computer. On this computer,, your IT dept have probably pre-created an user account for you already. They’ll give you a password for you to log in, and make you change it when you do. These are the password stored in the Active Directory.

So, all the buzz and fizz about stealing tokens and passwords are mainly targeted against your corporate environment. Why? Because attacker now have tools like Mimikatz which will dump hashes, and BloodHound which will map out exactly how to get to Domain Admin in 6 or less paths. And once the attacker get to Domain Admin? They essentially have access to every. single. computer. on. the. corporate. network. That’s why they sometimes call it key to the kingdom!

Accessing a service

So instead of making you type in your password every single time you want to open up an application, a ticket is used instead. Imagine you’re going on a cruise, people want to make sure you paid for it, so you show your ticket and as long as it’s a valid ticket, they let you in! On computer, Kerberos issues tickets to authenticated users that can be reused to access computers and services and these tickets are cached in memory.

When requesting access to a service or host, three interactions take place between you and:

  • the Authentication Server
  • the Ticket Granting Server
  • the Service or host machine that you’re wanting access to

Ok, so what’s there to know about the AD?

A few good things to know are:

  • The Key Distribution Center (KDC)

    • KDC create a ticket-granting ticket (TGT) for the client
    • It then encrypts it using the client’s password as the key, and sends the encrypted TGT back to the client
    • If client can successfully decrypt the TGT with their key, it indicates proof of the client’s identity.
    • This KDC stores all of the secret keys for user machines and services in its database.
    • The KDC itself is encrypted with a master key to add a layer of difficulty from stealing keys from the database.
    • The service or machine you are requesting access to never communicates directly with the KDC.
  • Ticket-Granting-Ticket (TGT) - first ticket obtained in a kerberos system.

    • The TGT does expire at a certain time but it does permits the client to obtain additional tickets, which give permission for specific services.
  • krbtgt - Kerberos TGT and describes the authentication service.
  • Kerberos - a protocol for authentication that uses tickets to authenticate. It help to avoid storing passwords locally or sending them over the internet by involving a trusted 3rd party and is built based on symmetric-key cryptography.

    • Kerberos’s’ name comes from Greek mythology, the three-headed guard dog of Hades. :)

Tickets, all the tickets

Each of these tickets are essentially a forged service authentication ticket.

  • Silver ticket

    • A hacker can create a Silver Ticket by cracking a computer account password and using that to create a fake authentication ticket. Kerberos allows services (low-level Operating System programs) to log in without double-checking that their token is actually valid, which hackers have exploited to create Silver Tickets.
    • Harder to detect than Golden Tickets due to no communication between the service and the DC – and any logging is local to the targeted computer.
  • Golden ticket

    • kerberos TGT for ANY account with no expiration; survives full password reset
    • When an attacker has complete and unrestricted access to an entire domain — all computers, files, folders, and most importantly, the access control system itself.

WDigest

An older protocol known as Digest Authentication is a challenge/response protocol that was primarily used in Windows Server 2003 for LDAP and web-based authentication. It utilizes Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges to authenticate. Prior to 2008R2, Wdigest credentials remained in the LSA of the Operating System in an unencrypted state, allowing a tool such as Mimikatz to enumerate the password of all logged on accounts in clear text.

Attacks

Kerberos Attacks

  • Pass The Ticket - steal ticket from memory then pass it onto other systems.
  • Overpass the hash - use NT Hash to request a new service ticket
  • Kerberoasting - request service ticket for highly privileged service and then crack all the hash!
  • Skeleton Key Attack - The Skeleton Key is a particularly scary piece of malware targeted at Active Directory domains to make it alarmingly easy to hijack any account. This malware injects itself into LSASS and creates a master password that will work for any account in the domain.

Tools

  • Mimikatz
  • Fgdump
  • Gsecdump
  • PWDumpX
  • Creddump
  • WCE
  • And so so many more

Detection

It’d be off brand if I talk about being a blue teamer but not talk anything about detections, so here it goes… This talk by Chad Tilbury from the SANS summit does a GREAT job at outlining each attack, and ways to mitigate it. Here’s the summary:

Depending on your environment and the privilege you have to run audit, one of the easiest way is probably to perform some type of authentication auditing. During this, map out any Admin$ shares, PsExec, scheduled tasks, VSSAdmin, RDP/VPN Activity. Check for any weird suspicious new service, look at crashes and security alerts. And look any any abnomalies in local admin/domain admin, service account use.

  • Kerberoasting uses RC4 encryption downgrade

    • Check for Ticket Encryption Type: 0x17 From Sean Metcalf (adsecurity.org)
  • Account domain field is blank
  • Account Domain field is Domain FQDN when it should be DOMAIN

Sources / Resources:

Special thanks:

  • Jessica Payne from Microsoft. She was the first person to describe the entire process to me, and the work she does really inspired me to go home and dig into AD, play with all the tools, and was one of the moment in my career that I really valued.
  • All the amazing blog posts and presentations from the guys/gals at SpecterOps. Not only did they created many amazing tools and open sourced them, they made the whole security industry better as a whole. I used many of their tools in order to learn and test.