A Guide To King of the Hill
A detailed description of what is King of the Hill, how to play it and more importantly, How NOT to play it.
What is King of the hill?
(A very, very small summary)
King of the Hill is a competitive hacking game, where you play against 10 other hackers to compromise a machine and then patch its vulnerabilities to stop other players from also gaining access. The longer you maintain your access, the more points you get.
Before we dive into what we can do and how we can fight in the game with other players, we should clear some boundaries on what should not be done in this, otherwise with a root shell, the scope is limitless.
How not to play King of the Hill?
This is a gentleman's game and should be played like one.
First, you should read KoTH rules: https://tryhackme.com/games/koth
Here's a detailed explanation of rules and boundaries regarding rules mentioned above:
Service Port 9999:
There is one thing common in every KoTH machine and that is, port 9999, which is running king service so you are definitely not supposed to stop/alter that service or close the port itself.
There is an option available to reset the box and that should only be used when the machine is broken, not when it's patched. When you face a dead end you should try looking for other possible options instead of voting to reset the box.
You should not alter, remove or replace flags from the machine as it's totally against the rules.
While patching, you should not completely delete a whole web server but instead try looking for a method to patch it. There's no vulnerability that can't be patched. Stuff like shifting the service to another port is allowed.
You should not do things like:
rm -rf /usr/bin/* or
chmod 700 /usr/bin/* as it will make it impossible for other users to use simple commands or even interact with the box using their shell. As that essentially made the machine unavailable for them.
You should not use autopwns (Or Any sort of script that automatically hack/harden the box) as that really will defy the purpose of the game. Scripted autopwns which root a box from start to finish are banned from public games. Go wild in private games with your friends.
You shouldn't use scripts to automatically kill other people's shells. Killing shells is allowed but it shouldn't be abused.
Remember its not a fight if there is no one in the ring.
Try to patch the ways others are getting the shells instead of just spamming kill command.
Speaking of which you can always use urandom or my personal favorite: Nyancat that would be more fun, too, instead of just killing the shell.
Or if you want to more cheeky try to find a way to make them play Tetris.
- You are allowed to use rootkits. But as implied by rules, while planting rootkits, make sure you do not break the machine or make it unusable for everyone but you.
If you think anyone breaking any of the above rules or the ones mentioned at the site's rules page, you can report them at [email protected] or let koth-staff know in the discord. If possible share game link and username of the person breaking the rules.
How to play King of the Hill?
We start this machine like every other box/machine on TryHackMe, we get an IP, and we enumerate it. If you are playing king of the hill, then it is obvious that you are on intermediate level on TryHackMe, because this is for players with some experience in solving/hacking boxes, if you are new, we'd advise you to NOT play this and solve some basic boxes first. You can refer to this blog post that is by Bee (TryHackMe Moderator), Link: https://blog.tryhackme.com/free_path/
Now, we get an IP address, and we get a timer, our goal is to get a root shell on this IP address before other players in your game do and the timer ends. Now, we know how to hack, but we need to know how to hack fast. We are not the best at this, but following are few things that you can use that will (maybe) make you faster than others.
In place of using nmap, Using Rustscan.
This thing is ridiculously fast, you can make it faster if you give its documentation a read and make a config file that suits your system.
(P.S. This is also made by Bee, and this thing can go as fast as scanning all 65535 ports in one second.)
Using custom wordlists:
You know there are 2 wordlists named big.txt? One in SecLists (If you don't know about this, then minimize this article and google.) and one in dirbuster? BUT what if you combine them and make one wordlist, with unique-ed out directories in alphabetical order?
Most important of them all, Taking Notes:
You can use (any note taking app you like) Notion, make folders of machines, log the commands you used to get into machines, these small things will save your time the next time you face the same machine.
Do NOT use msfconsole: (This is my personal opinion)
The entire aim of this is to learn stuff, but if you are always just searching in msfconsole and using it to get shells, well that defeats the purpose.
Speaking in terms of speed, It'll take you longer to find the same vulnerability in Metasploit and run it than it will take you to directly run the exploit file that you saved from last time you faced the same machine. (Makes sense now? Yeah.)
Know your tools:
Simple tips for tools that might speed you up:
-t to increase the number of threads, hence increasing your chances to get password before others do. The highest stable that we know of is 64, however, this can vary by service.
Gobuster: This is for game purposes only, use
-t with high values, We have used
-t 100 and it worked just fine. Just don't do that against a real machine, that will really hammer the server.
Rustscan: Already mentioned above. Read about it and make a config file that suits your system.
Kali Browser Machine: If you are looking for even faster speed, you can use THM kali browser machine for your scans as it would be multiple times faster. This eliminates any overhead from using the VPN connection.
Pwncat: (Using GOD of reverse shells)
(From it's github page)
pwncat is a post-exploitation platform for Linux targets. It started out as a wrapper around basic bind and reverse shells and has grown from there. It streamlines common red team operations while staging code from your attacker machine, not the target.
Though we suggest using pwncat, but only for reverse shell handling and doing quick persistence etc. As of now, other features of this tool are, auto-enumeration and backdoor planting. (Read more on their GitHub.)
Owning king.txt file:
If you give the manual page of chattr binary a read, you'll see that it can set immutable flags on files. That means, even root cannot make mutations in the file without removing that immutable bit.
chattr +i /root/king.txt
This is used by many players to make that king file immutable and hence persisting their name in that file.
To get the upper hand in game, use another bit, 'append-able' on king.txt. This bit makes the file append-able only, and since most of the players 'write' in the file and not append, hence they can't modify the file even though they removed the immutable bit.
(How to add that bit? Research.
man chattr )
Now almost always whoever uses the chattr binary first, either deletes it (foolish move) or hides it somewhere.
Once that's done, you don't have much choice but to either upload your binary or hope that no one deleted busybox from the machine. (whats busybox? GOOGLE!)
Make sure you upload statically linked binaries. (reason? GOOGLE!)
Here's the link to download static binaries to upload: https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/
Just upload them onto the box using
nc or any other method. We would suggest not to use the default location for your binaries but hide them in different places.
Now its on you how you use it, try finding a way to run it in a loop?
Now, this is a tricky bit, here, you can set the environment variable setting of root user to prevent overwriting in the files.
Hence, the word clobber, This means that the user cannot add anything to any file using
Although this doesn't stop many players, but this is hard to figure out and chances are they won't realize what's wrong if they don't know about this.
Basic command is
set -o noclobber
But this will only be effective in current shell, so to make it persistent across entire machine, add this to bashrc of root and source that.
As soon as you get root shell on machine, add some reverse shells and/or bind shells in the machine, so that even if get kicked out, which you will, you can always get back in.
(Make your own in whichever language you like, or you know, google.)
Make copies of SUID binaries, even though they are easy to find, but can sometimes save get you a root shell from www-data.
You can always put your ssh keys on to the user/root authorized_keys. So you can always ssh in using them.
You can use
ssh -tto hide your session from tty.
First things first, if they can't get in, you don't need to kick them out.
So, start by patching stuff on the box. Patch security issues, not legitimate services. For example, disabling ssh is not allowed unless it's a purposefully broken ssh installation.
Patch the path you get in from right after you make a backdoor.
You can use different commands like
ps aux | grep pts to see who else is on the system so far.
Look for the most common possible ways to patch a box i.e: changing ssh keys, changing passwords, look for the processes running or give cronjobs a look?
Always set your persistence so even if someone kicks you out you have ways to get back in.
Few links that can come in handy: