22. AD Authentication

• NTLM authentication

• Kerberos authentication

• AD credential caching on Windows Systems

Used when clients authenticate to a server by IP instead of hostname.

• TGT tickets are encrypted with the NTLM hash of the krbtgt account

  • “Ticket Granting Ticket” issued by DC after successfull authentication

  • Used to request Service Ticketes

• Service ticket is encrypted with the NTLM hash of the service account

  • Service Tickets are issued by DC after providing TGT + information about the service to log in to

  • Used to get access to service

• Hahses of passwords are cached in LSASS memory space (Local Security Authority Subsystem Service)

• LSASS runs as SYSTEM, so we need SYSTEM or local admin rights to extract hashes

• DC might act as CA and issue and revoke certificates

  • e.g. HTTPS cert for web server

  • e.g. Certificates for users smartcards

• Mimikatz ca be used to extract private keys (crypto::capi and crypto::cng)

AS-REP roasting is a technique that allows retrieving password hashes for users that have Do not require Kerberos preauthentication property selected.

For those users, we can request the DC which response with data encrypted using its hash. We can crack this offline with hashcat.

• as a valid domain user, we can request a service ticket for a known SPN

• the DC issues a service ticket, which is encrypted with the password hash of the service account

• this allows us to perform a offline attack against the service account password

• Forging Service Tickets

Root Problem:

• privileges in Service Tickets are trusted often without validation

• “Privileged Account Certiciate validation“ must be set explictly -> Service verifies privileges in Service Ticket against DC

Attack:

• if we know the password hash of the service, we can provide arbitrary privileges to our ticket/session -> “silver tickets”

• we can also provide arbitrary domain users -> from the perspective of the server we are logged in as the user we specify

• domains usually have multiple DCs

• they are synced via the DRS protocol

• updates are propagated, but those updates are not verified

  • it is only checked, if the associated SID has appropriate permissions

  • if we are domain admin, we can request all user password hashs

  • dsync attack