Discovering the Chatter
I began with an nmap scan of common TCP ports:
Huh. This machine didn't seem like a "chatterbox" so far. No listening ports were definitively detected by the scan. That usually means that either the machine is behind some sort of network obstacle (such as a firewall) that's interfering with the scan, or the machine's services are listening on irregular ports that nmap won't scan by default.
I conducted a more comprehensive (though hasty) TCP connect port scan and discovered services on ports 9255 and 9256:
Okay, now I had a little something to go on. I hit the discovered services with a version scan to obtain more information:
A little bit of research told me that Achat is a freeware solution for conducting instant messaging and file sharing across a LAN. A little bit more research told me that some versions of it are vulnerable to a remote buffer overflow attack:
I decided to use the public exploit in the above image, which can be found either in your install of Kali at the path described in the screenshot or at this url. With this exploit, I quickly compromised the box.
Exploit Modification, Exploitation, User Flag
Reading the exploit code, it seemed like a fairly simple Python script that constructs a buffer of a couple hundred thousand bytes. The buffer consists of boilerplate to appease the application, junk bytes to overflow the application's buffer, and finally the shellcode that will be executed when the exploitation process is complete. The script then sends the buffer to a hard-coded IP address and port a few thousand bytes at a time in UDP packets.
Two salient points jumped out at me while reading the exploit:
First of all, the exploit as written is a proof of concept in the truest sense: its payload is not weaponized at all and does nothing but open Windows Calculator on the target machine. This is a common test that exploit writers use because it provides easy visual proof of exploitation and demonstrates the potential impact of the exploit (running a program on a remote system) while also being non-invasive relative to a shell or other payload. However, if we want to use this script to actually compromise a system, we need to generate our own shellcode payload and use it instead of the calc shellcode. We can do that with the Metasploit Project's msfvenom program.
The exploit author was nice enough to show the full msfvenom command used to generate the calc.exe shellcode, including bad characters. Appropriate shellcode for exploitation could therefore be generated by running the same command but with a reverse shell payload specified:
LHOST was my attacking machine's IP address. Once this shellcode was generated, I edited the exploit proof of concept and replaced the entire "buf" variable shown in the previous image with the generated shellcode.
The second salient point from reading the exploit script was that the IP and port that the exploit will target were hard-coded:
The port is fine, but obviously the exploit wouldn't work against Chatterbox until I replaced the IP address with Chatterbox's IP, 10.10.10.74. I did so, then set up a netcat listener to catch the reverse shell connection and fired away*:
I had hacked the machine and become chatterbox\alfred. Grabbing the flag that signifies I've breached a user account:
Next up: post-exploitation.
*In testing this exploit since then, I have noticed that the exploit is finicky and sometimes must be run two or three times before successfully executing the shellcode. This may have been another cause of frustration among HackTheBox participants. Reading Rapid7's description of the exploit, it seems like this may have been because the exploit deals with timing issues/race conditions.
Post-Exploitation, Root Flag
On HackTheBox, the "root" flag is always on the Desktop of the Administrator account:
I could cd to the directory and see the flag file, but I could not list its contents. Examining the file with the icacls permission utility, I could see why:
The Administrator account had full access to the file and my Alfred account had none. However, once I obtained a little more information about the file, it was easy to change that. The dir command's /q switch will show ownership information ("q" for "ownership"...makes sense, no?) about every file and directory in the output listing. In this case, it showed that my compromised user account Alfred actually owned the root.txt flag file:
In Windows, if you are the owner of a file, you have the ability to grant users access to it regardless of anything else. So while my account had apparently been stripped of permission to read or edit the file, my ownership of it gave me the ability to grant those permissions to anyone, myself included. I used icacls with the /grant switch to give my account full access to the file:
Thus ends the walkthrough; at this point I had obtained both the user flag and the root flag and fulfilled the challenge requirements.
Lessons Learned
After I've solved a vulnerable machine, I often search the internet to see what other participants found difficult about it. I was surprised to find a huge number of people who struggled mightily with this machine. It seemed that the enumeration process in particular frustrated many. Yet we cannot blame the machine simply for presenting us with a challenge, and must instead learn more and adapt our ways of thinking to meet any challenge. It is our own misgivings and gaps in knowledge that can turn an exercise such as this from trivial to excruciating. Here are some lessons from this machine that could help avoid that excruciation in the future and in the real world.
Learn How Your Tools Work
Something I learned from reading of issues people had with this challenge: many did not seem to know how nmap works, how to adapt it to their needs, or how to recognize a situation wherein their needs diverted from the norm. They were unable to effectively cope when the default nmap port settings weren't suited to this challenge. This is significant. Nmap is among the most flexible and essential tools in a hacker's kit.
When executed without port settings specified, nmap scans ports based on a popularity contest. It has an internal database of ports ranked by how common they are. When you perform this scan...
nmap -sSV 127.0.0.1...you have not specified any port-related parameters, so nmap will use its default port settings, which are to scan the 1000 most common ports for the underlying transport protocol of your scan. A SYN scan is a TCP scan, so this command will scan the 1000 TCP ports that are statistically the most common--ports like 80, 443, 445, 139, 21, and so on. A talk by the creator of nmap gives a window into how the data regarding port use frequency was initially obtained.
Port scanning is a balancing act in which you must weigh how comprehensive the scan is against how much the scan "costs." That is, how long the scan will take, how much bandwidth the scan is using, how intrusive the scan is, the environment in which you are conducting the scan, and a variety of other factors. Nmap's default settings are meant to represent an ideal reward:cost ratio. Using these settings bears a high probability that you will discover some open ports for your efforts, but you must also understand that such a scan is not comprehensive and comes bundled with at least a slight chance that you could be missing something critical like the AChat service. When you get the feeling that you need to widen your scanning berth, you need to be familiar enough with nmap's port and timing options to cook up different scans on the fly.
I cannot teach you everything there is to know about nmap, but I will tell you what served me well and what I would recommend you do. Go to this page. Read everything there from beginning to end. Take notes. Then do that again. The second time, try each newly described scan parameter against a VM image with some services exposed. Then try combining it with others. Once in a while, come back and study your notes and the linked page. Do whatever you need to do to remember the bulk of nmap's settings, know what each does, and be able to concoct a scan at any given moment. In addition to studying this page, taking notes, and regularly using nmap, I made a deck of flash cards about nmap and studied them for a few minutes each day.
These might not sound like the most exciting exercises in the world, but I cannot describe how much time and frustration all of the above saved me in the long run and how much it amplified the usefulness of nmap to me.
nmap is only one tool, and this lesson holds true for all tools: know how they work or their usefulness is severely limited. Most security tools have a default setting that will be of some use, but it's knowing the other parameters and how the tool functions internally that allows you to bend the tool to your will. For every tool that you use, you should:
• Be able to describe at a high level how that tool functions and what it is doing/automating
• Fluently understand each of its options and when/how to use them
Read and Understand Public Exploit Code Before Use
This definitely falls under the header of "learn how your tools work," but public exploits are a special case for several reasons:
• They tend to be one-off scripts written by anonymous individuals and sourced from various places.
• They may require modification to suit your needs.
• They often contain encoded code or code the purpose of which is not immediately obvious.
A few reasons you should always review exploit code before running it:
• The exploit code may be fake or harmful, and you want to determine this before running it rather than after.
• You want to know how the exploit code works, what payload it delivers, whether you need to change that payload, and what will constitute a successful exploitation. Knowing this information up front could save you loads of wasted time speculating about why the exploit doesn't work the way you want it to later.
• The exploit author's description of how to use/modify the exploit or common pitfalls encountered during exploitation may be embedded within the exploit code itself as comments.
Recall that the exploit used in this challenge was originally a proof of concept that did nothing but launch the Windows "calc.exe" application when the exploit was successful. Well, sure enough, when I ran the tasklist command on the compromised Chatterbox, I found some lingering calculators...
This means that other people attempting the challenge--ostensibly people people studying information security--were running the same exploit that I had discovered against the target without reading the actual exploitation code and having modified only the IP/port values in the script. This course of action is a waste of time at best and dangerous at worst. To avoid such a mistake, read the exploit code up front and understand what it expects from you and what you should expect from it.
A Non-Administrative Breach Can Spell Trouble
You'll notice something about this challenge: I never elevated my privileges to the administrative level, yet I still manipulated sensitive information that I was not supposed to have access to.
Modern penetration testing and security education seems heavy on privilege escalation and post-exploitation strategies. This is a good thing. Real attackers clearly love tightening and persisting their control of a network and pivoting deeper into an organization after they've made their initial intrusion. It's often how they find sensitive data and strike at that organization's heart. So it behooves us to study privilege escalation and pivoting in a general sense.
Yet here is a good lesson: attackers sometimes don't need to hack a domain controller or even be a local administrator to steal information or cause damage. Intruders tend to "live off the land" in numerous ways. They do whatever they can with what they have access to. If they have access to Alfred in Operations's account and he controls all of your Operations Department's information, well, the intruders control all of your Operations Department's information regardless of whether they have pivoted adequately, own your whole network, have domain admin privileges, etc. This is why defenders and attackers must analyze the organization in question and consider all ways attackers could conceivably harm it (a process called threat modeling) rather than simply recycling generic goals like "let's get domain admin."
Conclusion
I actually liked this machine a lot. It presents the opportunity to learn several good lessons about reconnaissance, exploitation and file permissions. It was also nice to see a challenge with more traditional network exploitation techniques, as HackTheBox machines seem heavily tilted toward web exploitation in general. I can see how it might have frustrated some, but from frustration much knowledge and motivation to be better can be obtained. A huge thank you to HackTheBox.eu for hosting the vulnerable machine, the machine's creator for spending time to create a fun little puzzle, and the astute reader for making it through this walkthrough.