So, there’s hacking…
If you’re here, you probably share a similar interest in hacking, like myself. What’s not to find interesting? You’re finding an entrance into a system that shouldn’t exist. Sometimes, like when you’re coding, you even have moments of sheer bliss because you know how to do something only a handful do. Imagine that, you’re part of an elite group of computer users.
The problem we run into is society tends to frown on hacking things all willy nilly. Uncle Sam gets grumpy, and a SWAT team takes your door out lest you weiled your dangerous h4x0r p0w3rz against them. Before you know it, you’re holding up in a closet lined with aluminum foil somewhere in the Carribean. Ok, enough of the McAfee cracks – let’s get serious.
You should’ve heard of it by now, the platform hackthebox.eu. It’s a place where all things are sitting, waiting to get attacked. And you know what? It’s damn good. Over my years I’ve seen a lot of wargame environments, various vulnerable VMs, websites specifically devoted to “learning to hack.” None have gone as far as htb has in terms of being truly realistic. While I’ve only pwned a couple boxes so far (like I said, realistic. These aren’t simple challenges), I’m eager to keep learning more while building my stats. Today, I intend on laying out my process as accurately as possible, including head-desk sessions and all. Are you ready? Because I’m not.
Prepare for attack!
Step 1: Find a box. No you don’t have to scan the network (despite having to do a little hacking to even get an account). Just pick a machine. Despite doing this for years, most of my experience has been had clearly defined tasks or vectors of attack. HTB doesn’t really give that to you. They give you a list of boxes, a name and an IP. So, I pick a box that I think looks reasonable for my abilities.
Step 2: Set up your hosts file. This isn’t mandatory, but it’s helpful as you dig into the more complex boxes (as I’m now learning). Just edit
/etc/hosts and put the hostname in there. Typically the hostname will be the name of the box plus .htb. So, for instance, the box I’m working on now is
craft.htb. Easy enough – this just makes it so you can access the site by hostname instead. If you’re using a jump box, and SOCKS5 proxy like I am, you’ll need to do this same thing on your SOCKS client machine as well. I learned this the hard way yesterday – apparently SOCKS doesn’t forward host information.
Step 3: Make a directory to store all the things. Seriously, keep a good file structure for each box. I’m learning this will be a valuable habit to be in when I go for OSCP (yeah, I’m starting training for my first infosec cert XD). Documentation is vital in an penetration test and if you can hack all the things but not record anything, well, you’re shit out of luck.
Step 4: Put together a game plan. As I write this, I have a purpose. I’m not only wanting to share my process with you, I’m writing this down for myself. I’ve noticed I have some general “flow” I go through, but I don’t really have a clearly defined process. This is to help me get there, and maybe save you some time in you getting there too. This will probably change and be refined over time, but for now we can just assume this is the end-all-be-all SOP going forward.
re·con·nais·sance (noun) military observation of a region to locate an enemy or ascertain strategic features; preliminary surveying or research.
Despite what the movies would have you believe, you can’t drop a logic bomb in the pipeline and get teh r00tz. In reality, if you don’t have an opening (using this term very loosely here), you aren’t getting in. In order to find openings, you have to do some recon. Time to bust out those port scanners and some basic terminal utilities to learn about your target!
nmap is a tool I use religiously. I use it in my day-to-day work for configuring servers, mapping networks, checking ports, etc. I’m eternally in debt to Fyodor for this tool; it’s fucking amazing. Anyways, I start off with a basic scan – this is a quick and clean way to tell us (a) the host is up and (b) if we have some open ports. This is my first scan:
nmap -oA base_scan [host]
Easy enough. Depending on those results, I’ll expand a bit. The next scan I’ll run is a SYN scan coupled with running the default script scan from nmap. I dump this out to a file called
nmap -sS -sC -oA sssc_scan [host]
This yields us output similar to:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-11-22 17:39 PST Nmap scan report for athena (192.168.1.133) Host is up (0.00018s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh | ssh-hostkey: | 2048 38:3d:66:73:b6:06:f5:3d:6e:d2:d7:82:4e:01:22:11 (RSA) | 256 f2:bb:bb:5b:2f:bc:d4:79:e8:28:44:2c:44:be:06:4f (ECDSA) |_ 256 75:40:41:86:96:d7:89:3f:51:88:a7:ee:47:cf:eb:db (ED25519) 80/tcp open http | http-methods: |_ Potentially risky methods: TRACE_ |_http-title: Site doesn't have a title (text/html). 3306/tcp open mysql MAC Address: 00:1A:A0:1D:24:7B (Dell) Nmap done: 1 IP address (1 host up) scanned in 66.27 seconds
And just for good measure:
nmap -sT -A -n -p- -Pn -oA st_scan [host]
You can anticipate that scan taking some time, as
-Pn forces nmap to scan every single port. It also identifies services and version numbers, which will be helpful in finding exploits or known configuration issues. Regardless, this scan gives us:
> nmap -sT -A -n -p- -Pn athena Starting Nmap 7.70 ( https://nmap.org ) at 2019-11-22 17:42 PST Nmap scan report for athena (192.168.1.133) Host is up (0.00019s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.8 (FreeBSD 20180909; protocol 2.0) | ssh-hostkey: | 2048 38:3d:66:73:b6:06:f5:3d:6e:d2:d7:82:4e:01:22:11 (RSA) | 256 f2:bb:bb:5b:2f:bc:d4:79:e8:28:44:2c:44:be:06:4f (ECDSA) |_ 256 75:40:41:86:96:d7:89:3f:51:88:a7:ee:47:cf:eb:db (ED25519) 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) PHP/7.1.33) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.41 (FreeBSD) PHP/7.1.33 |_http-title: Site doesn't have a title (text/html). 3306/tcp open mysql MySQL (unauthorized) MAC Address: 00:1A:A0:1D:24:7B (Dell) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.70%E=4%D=11/22%OT=22%CT=1%CU=44314%PV=Y%DS=1%DC=D%G=Y%M=001AA0% OS:TM=5DD88FDB%P=x86_64-pc-linux-gnu)SEQ(SP=103%GCD=1%ISR=10B%TI=Z%CI=Z%TS= OS:21)SEQ(SP=103%GCD=1%ISR=10D%TI=Z%CI=Z%II=RI%TS=21)OPS(O1=M5B4NW6ST11%O2= OS:M5B4NW6ST11%O3=M5B4NW6NNT11%O4=M5B4NW6ST11%O5=M5B4NW6ST11%O6=M5B4ST11)WI OS:N(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF)ECN(R=Y%DF=Y%T=40%W=FF OS:FF%O=M5B4NW6SLL%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3 OS:(R=Y%DF=Y%T=40%W=FFFF%S=O%A=S+%F=AS%O=M5B4NW6ST11%RD=0%Q=)T4(R=Y%DF=Y%T= OS:40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0 OS:%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z OS:%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G OS:%RUCK=G%RUD=G)IE(R=Y%DFI=S%T=40%CD=S) Network Distance: 1 hop Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd TRACEROUTE HOP RTT ADDRESS 1 0.19 ms 192.168.1.133 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 351.40 seconds
These provide us with pretty much all the details we need to get started in determing our forward movement. Given I do web development, and am most comfortable in the Linux environments, I tend to focus on systems that are in that arena. Throughout the rest of this article we’ll be discussing the processes I follow in the course of attacking this class of systems.
Despite having ports, it can be really tedious figuring out all the paths available on a website. That’s where people like The Dark Raver are considered incredibly generous people. A tool that I only discovered after getting on htb (prior to this I used Burp for this), is called dirb. What dirb does is provides a simple terminal-based interface to enumerate subdirectories within a domain. Keep in mind, this is a pretty noisy process, so if you’re trying to be subtle, this might not be the best tool. On htb, I’m not sure subtlety matters, so send it!
You can provide wordlists to dirb, but typically I’ll start with just the defaults:
This will net us something along these lines:
----------------- DIRB v2.22 By The Dark Raver ----------------- START_TIME: Fri Nov 22 18:58:19 2019 URL_BASE: http://athena/ WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt ----------------- GENERATED WORDS: 4612 ---- Scanning URL: http://athena/ ---- + http://athena/index.html (CODE:200|SIZE:45) ----------------- END_TIME: Fri Nov 22 18:58:21 2019 DOWNLOADED: 4612 - FOUND: 1
While this isn’t an extensive list for this particular host (using one of my home servers for these examples, sorry if you’re looking for spoilers!), on a real target, sometimes you’ll find places of interest. Sometimes, depending on the host, if nothing returns from this initial scan, I’ll feed in one of the other lists dirb provides, which you can find in
/usr/share/dirb/wordlists/ on Debian 10.
And now we attack!
At this point, we have plenty of information to go off of and start plotting a path to gain access to this box. If you’re aiming for OSCP style, pulling out metasploit isn’t an option yet. While it is usable in the exam (I think it’s required, don’t quote me though), they want to see you exhaust all other means of gaining a foothold and compromising a target before reaching for the life saver. Given I’ve only done two boxes, one of which I used metasploit for, I haven’t completely worked out my process here yet.