Edit

Module 22: Attacking Active Directory Authentication

Understanding Active Directory Authentication

NTLM Authentication

The NTLM authentication protocol consists of seven steps:

  1. Calculate NTLM hash on Client

  2. Username sent: Client -> Application Server

  3. Nonce sent: Application Server -> Client

  4. Response (Encrypted nonce) sent: Client -> Application Server

  5. Response, username and nonce sent: Application Server -> Domain Controller

  6. Encrypt nonce with NTLM hash of user and compare to response on Domain Controller

  7. Approve authentication sent: Domain Controller -> Application Server

Kerberos Authentication

The Kerberos authentication protocol consists of six steps:

  1. Authentication Server Request (AS-REQ) sent: Client -> Domain Controller

  2. Authentication Server Reply (AS-REP) sent: Domain Controller -> Client

  3. Ticket Granting Service Request (TGS-REQ) sent: Client -> Domain Controller

  4. Ticket Granting Server Reply (TGS-REP) sent: Domain Controller -> Client

  5. Application Request (AP-REQ) sent: Client -> Application Server

  6. Service Authentication sent: Application Server -> Client

Cached AD Credentials

In modern versions of Windows, the hashes to renew a TGT request are stored in the Local Security Authority Subsystem Service (LSASS) memory space.

A TGS would allow us to access only particular resources associated with those tickets. Alternatively, a TGT would allow us to request a TGS for specific resources we want to target within the domain.

Performing Attacks on Active Directory Authentication

Password Attacks

Learning more about a domain's account policy:

There are a few password spraying attacks we could perform:

First, is performing a low and slow password attack leveraging LDAP and ADSI. This is a slight modification of the previous module's enumeration via DirectoryEntry:

The above commands could thus be turned into a script, performing a password spray across multiple accounts, with various passwords.

Second, would be leveraging SMB:

The third kind of password spraying attack is based on obtaining a TGT:

If you receive a network error, make sure that the encoding of usernames.txt is ANSI. You can use Notepad's Save As functionality to change the encoding.

AS-REP Roasting

We can use impacket-GetNPUsers to perform AS-REP roasting which takes an AS-REP from the domain controller, then performs an offline password attack against the encrypted part of the response:

AS-REP Roasting can also be performed on Windows. In this example, we'll use Rubeus:

To identify users with the enabled AD user account option Do not require Kerberos preauthentication, we can use PowerView's Get-DomainUser function with the option -PreauthNotRequired on Windows. On Kali, we can use impacket-GetNPUsers as shown in listing 14 without the -request and -outputfile options.

If we found that no users had that account option set, we might find that we have GenericWrite or GenericAll permissions on another AD user account which we could then modify the account to not require Kerberos preauthentication.

Kerberoasting

Using Rubeus to kerberoast:

Cracking the hash:

Using impacket-GetUserSPNs to kerberoast:

Silver Tickets

If we can get the service account password/hash, we can forge our own service ticket to access the target resource with any permissions desired. This is called a silver ticket. If the SPN is used on multiple servers, this ticket can be leveraged against them all.

In general, there are three things required to create a silver ticket:

  1. SPN password hash

  2. Domain SID

  3. Target SPN

Testing our current credentials to teh HTTP SPN:

Dumping the hash for the service account:

Querying the Domain SID, omitting the RID of our user:

Generating our golden/silver ticket, (in this case golden):

Confirming the ticket is in memory:

Requesting the HTTP SPN again, which will now use our ticket in memory:

Domain Controller Synchronization

To launch a replication, a user needs to have the Replicating Directory Changes, Replicating Directory Changes All, and Replicating Directory Changes in Filtered Set rights. By default, members of the Domain Admins, Enterprise Admins, and Administrators groups have these rights assigned.

Using mimikatz to perform a dcsync attack, impersonating a domain controller:

Using impacket-secretsdump to perform a dcsync attack:

PreviousModule 21: Active Directory Introduction and EnumerationNextModule 23: Lateral Movement in Active Directory

Last updated