A Quick Few Points

1. There are lots of CTFs and vulnerable boxes out there. One post is not going to cover every possible scenario, avenue, or approach.
2. I do not proclaim to be the best at CTFs or vulnerable boxes. There is and will always be someone more skilled than me. But, I am motivated, curious, and very good at using Google.
3. The more practice you get with a wide variety of targets, the better you'll get at finding patterns and forging your own methodology. At first, you'll likely mimic others' patterns, but will do so less as you get more practice.

Step 1. Nmap Scan

As is the case with most vulnerable boxes, we begin assessing the target by running a nmap scan to understand the following:

• What is running on the target, what server names, what versions?
• What client software would we need to connect and assess the target?

nmap -h

sudo nmap -Pn -p- -A -T4 -oN scan.txt <target_ip>

sudo nmap -Pn -p- -A --min-rate 5000 -oN scan.txt <target_ip>

sudo nmap -Pn -sU --top-ports 500 -A -T4 -oN udp-scan.txt <target_ip>

Using the example nmap syntax above, this is going to run:

• Service version scan
• OS detection
• Default script scan

Example Nmap Output

PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         ProFTPD 1.3.3c
22/tcp  open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 a6:0e:30:35:3b:ef:43:44:f5:1c:d7:c6:58:64:09:92 (RSA)
|   256 c2:d8:bd:62:bf:13:89:28:f8:61:e0:a6:c4:f7:a5:bf (ECDSA)
|_  256 12:60:6e:58:ee:f2:bd:9c:ff:b0:35:05:83:08:71:b8 (ED25519)
25/tcp  open  smtp        Postfix smtpd
|_smtp-commands: funbox11, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN
80/tcp  open  http        Apache httpd 2.4.18 ((Ubuntu))
|_http-generator: WordPress 5.7.2
|_http-title: Funbox: Scriptkiddie
|_http-server-header: Apache/2.4.18 (Ubuntu)
110/tcp open  pop3        Dovecot pop3d
|_pop3-capabilities: RESP-CODES UIDL TOP SASL CAPA PIPELINING AUTH-RESP-CODE
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open  imap        Dovecot imapd
|_imap-capabilities: LOGINDISABLEDA0001 Pre-login more post-login have ENABLE LOGIN-REFERRALS SASL-IR capabilities IMAP4rev1 listed IDLE ID OK LITERAL+
445/tcp open  0�>_y      Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94%E=4%D=7/22%OT=21%CT=1%CU=39079%PV=Y%DS=2%DC=T%G=Y%TM=64BB5A4
OS:8%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=105%TI=Z%II=I%TS=8)SEQ(SP=1
OS:04%GCD=3%ISR=105%TI=Z%II=I%TS=8)OPS(O1=M5B4ST11NW7%O2=M5B4ST11NW7%O3=M5B
OS:4NNT11NW7%O4=M5B4ST11NW7%O5=M5B4ST11NW7%O6=M5B4ST11)WIN(W1=7120%W2=7120%
OS:W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%DF=N%T=40%W=7210%O=M5B4NNSNW7%CC
OS:=Y%Q=)T1(R=Y%DF=N%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y
OS:%DF=N%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=N)T7(R=N)U1(R=Y%DF=N%T=40%I
OS:PL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Network Distance: 2 hops
Service Info: Hosts:  funbox11, FUNBOX11; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
|   Computer name: funbox11
|   NetBIOS computer name: FUNBOX11\x00
|   Domain name: \x00
|   FQDN: funbox11
|_  System time: 2023-07-22T06:24:33+02:00
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-time:
|   date: 2023-07-22T04:24:33
|_  start_date: N/A
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
|_clock-skew: mean: -39m59s, deviation: 1h09m16s, median: 0s
|_nbstat: NetBIOS name: FUNBOX11, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

Breadcrumbs

Even running the default nmap scripts can reveal a good deal of information about the services running on the target. There are additional enum and brute scripts that often don't get run as a default scan.

Make sure you carefully look over the nmap script scan output, as this can have details such as:

• FTP file enumeration
• NFS share names
• HTTP robots.txt and redirects
• DNS names
• Emails
• Computer names
• OS versions
• And, much more

Open Ports

Identifying Services

Using the example nmap scan output from above, we can see that nmap was able to pull service banners for all open ports that it could connect to.

21/tcp  open  ftp         ProFTPD 1.3.3c
  ^       ^    ^             ^
  |       |    |             '----------- Application and version (banner)
  |       |    |
  |       |    '----------------- Well-known service
  |       |
  |       '------------- Port state
  |
  '----------- Port number
               and Transport protocol

You can find a list of well-known services that nmap tracks at /usr/share/nmap/nmap-services. It's this database that allows nmap to assume the service type running a particular port.

Take note of all the services running on the target and the version numbers of said services. By looking at the services, you'll also know which client software you'll need to do some manual testing. Based on the example nmap output above, we know we'll possibly need:

• FTP client
• SSH client
• SMTP / POP3 (mail) client
• HTTP (web) client
• SMB client

No Service Banners?

5040/tcp  open  unknown

What if nmap was able to connect to the port, but was unable to pull a service name and version from the port? There could be various reasons for this, some of the most common being:

• The port was opened on the box in an attempt to trick you
• The port is coupled with another service and doesn't reveal banners
• The service running on the port may be malfunctioning

You can try to manually pull banners from the service, but in all likelihood, you'll just have to move on:

nc -nv <target-ip> <target-port>

Cataloging Possible Exploits

When I want to get an idea of any public exploits that might be available for any service(s), I will typically search on Google or Exploit Database.

• Google:
  • ProFTPD 1.3.3c exploit
  • ProFTPD 1.3.3c exploit site:github.com
• Exploit Database:
  • Command Line: searchsploit ProFTPD 1.3.3c
  • Web: https://www.exploit-db.com/

In the case of a CTF, a Denial of Service exploit wouldn't do us much good, but a Command Execution or File Inclusion exploit would be very interesting.

Step 2. Service Enumeration

General Procedure

This is my generalized approach to every target:

1. File servers
2. Web servers
3. Everything else

I do it this way, because I work my way up by level of effort and amount of time involved to enumerate these services.

• File servers are quick and easy to assess, requiring only a widely available client
• Web servers require more work and enumeration due to more complex configurations that are possible on the server
• Everything else comes last when the first two aren't available or they haven't yielded enough info

DNS — UDP/53 & TCP/53

I'm putting this one at the top — above file servers — because this is one of those easy things you can try that can be potentially high-impact.

If you found — for example — in your nmap scan that a web server had a TLS certificate with a commonName=mysite.test and there is a DNS server running, you should test to see if a zone transfer is possible.

host -l mysite.test 10.10.100.44

If the zone transfer is successful, you could potentially reveal additional HTTP server names to assess later.

FTP — TCP/21

ftp anonymous@10.10.100.44

When prompted for a password, simply press the Enter key and see if it will allow you to login. If it does, try the following:

• ls to list files on the server
• get to retrieve files on the server
• less or more to read files from the FTP shell
• cd to change into any potential directories
• put to test write permissions as a way to perhaps chain an exploit with another service

We're trying to uncover:

• Usernames
• Passwords
• Configuration files
• Source code
• Backups
• Anything interesting

If there's a lot of files and folders, you could do a recursive download and parse the files locally.

SMB — TCP/139 & TCP/445

List Shares

smbclient -N -L //10.10.100.44

If you are able to anonymously list shares, then there's a decent chance you may be able to map shares.

Shares that aren't interesting from a files perspective are, for example:

• IPC$
• print$

Mapping Shares

smbclient -N //10.10.100.44/myshare

If you are able to map the share anonymously, try the following:

• ls to list files on the server
• get to retrieve files on the server
• less or more to read files from the SMB shell
• cd to change into any potential directories
• put to test write permissions as a way to perhaps chain an exploit with another service

Like FTP, we're trying to discover anything interesting. If there's a lot of files and folders, you could do a recursive download and parse the files locally.

HTTP — TCP/80 & TCP/443

Initial Questions

The first things I want to establish with the web service are:

• Are there any noticeable differences between the http:// and the https:// versions of the apps running on the web server? In other words, is http:// redirecting to https://, are they duplicates, or they completely different in behavior and presentation?
• Is the server making use of any ServerName (virtual host) directives that would cause different pages to load depending on the the hostname the client requests?

Test the Raw IP Address

• http://10.10.100.44
• https://10.10.100.44

• If the server loads different content at each unique address
  • There are distinct configurations per port
  • Plan on testing the servers independently
• If the server redirects TCP/80 to TCP/443
  • Only need to test TCP/443 (https)

Testing Server Names

The Host header is what the server is looking at to determine which virtual host configuration to serve content from. If you're interested in learning more about enumerating virtual hosts, you can see my notes here.

We can create a local name resolution entry by editing our /etc/hosts file, adding the DNS names we saw in the nmap output or any successful zone transfer.

sudo nano /etc/hosts

# Custom Entry
10.10.100.44 mysite.test dev.mysite.test admin.mysite.test

Again, as before, test the server names against both HTTP and HTTPS and see if there are any behavioral differences.

• http://mysite.test and https://mysite.test
• http://dev.mysite.test and https://dev.mysite.test
• http://admin.mysite.test and https://admin.mysite.test

• If different domain names load the same content
  • No difference in page content between http://mysite.test and http://subdomain.mysite.test
  • Safe to assume no virtual hosts are being used
  • You can most likely test the server using the raw IP address
• If different domain names load unique content
  • https://mysite.test and https://subdomain.mysite.test load completely different pages
  • More than likely this server is using virtual hosts
  • Test each virtual host as an individual server

Information Gathering

Walking the Happy Path

Walking the “happy path” :: Pwning OWASP Juice Shop

OWASP Juice Shop

At this stage, we just want to use the web page as a normal user would.

• Not doing anything malicious
• Click links and provide expected inputs in standard fields
• Doing things that a normal user would expectedly do
• Navigating to the URLs we've discovered at this point
  • Raw IP addresses
  • Domain names
  • HTTP/HTTPS
• Just click around on links and interact
• Enter input as a normal user would
• Sign up for an account and view the application as an authenticated user
• Trying to understand the application behavior

Checking the Page Source

• Press CTRL + U
• Check the page source for any servers that need to be tested
  • Raw IP address
  • Domain names
  • HTTP/HTTPS
• Look for anything interesting visible client side
  • Typically in the HTML comments
  • Usernames
  • Passwords
  • Directory names
  • File names
  • Etc

Check for Robots and Sitemap

• http://10.10.100.44/robots.txt or https://mysite.test/robots.txt
• https://10.10.100.44/sitemap.xml or https://mysite.test/sitemap.xml
• robots.txt and sitemap.xml direct legitimate web crawlers and search engines
• They're only effective to the extent bots respect them
• Can also reveal some interesting and sensitive directories or pages
• robots.txt may show an entry for the /admin directory or similar
  • A legitimate web crawler respects this and does not crawl the directory
  • Malicious users will see this an opportunity to explore

Directory and File Enumeration

• Interesting files and directories may be "hidden" or not directly exposed
• We can send a series of HTTP requests to determine if a file or directory exists
  • HTTP 20x and HTTP 30x responses would be interesting
  • HTTP 403 could be interesting from the perspective of, "What are we NOT allowed to access?"
• I typically use gobuster or feroxbuster
• Choose whichever tool is most comfortable for you

gobuster dir -u http://10.10.100.44 -w /usr/share/seclists/Discovery/Web-Content/directory-list-big.txt -x php,html -r -t 100 -o gobuster80.txt

gobuster dir -k -u https://dev.mysite.test -w /usr/share/seclists/Discovery/Web-Content/big.txt -x php,html -r -t 100 -o gobuster443.txt

• These enumeration scans could reveal:
  • "Hidden" pages or pages with unintended access
  • Path-based applications such as CMS (eg. WordPress or Drupal)
• Blogs or CMS platforms may be unpatched or use unpatched plugins
  • Should check the version numbers for public exploits
  • wp-scan can be helpful when enumerating WordPress

Testing the Application

By now, you should have plenty of places to begin looking for potential vulnerabilities with the web applications running on the server.

You want to begin testing the web applications at various points:

• Vulnerable service or plugin versions
• URL parameters
• Login forms
• Search fields
• File uploads
• Etc.

And, you could test for things like:

• Path traversal
• Local and/or remote file inclusion
• Content type filter bypass
• SQL injection
• Default credentials
• Credential stuffing
• Password spraying
• Much, much more

Unknown Ports and Services

Sometimes you will see uncommon services, uncommon port bindings, and high-number port bindings on certain CTF targets. The key here is being able to tell the difference between:

• An uncommon or high port bound to a service
  • Often included by CTF authors to confuse you
• A dynamic port bound to something like RPC
  • Just part of the operating system or another service like NFS

Fortunately, nmap does a good job of identifying services bound to ports, except for when it can't grab service banners from the port. So, you should be able to identify RPC from other port bindings with ease.

Examples

49152/tcp open  msrpc        Microsoft Windows RPC  
49153/tcp open  msrpc        Microsoft Windows RPC  
49154/tcp open  msrpc        Microsoft Windows RPC  
49155/tcp open  msrpc        Microsoft Windows RPC  
49156/tcp open  msrpc        Microsoft Windows RPC

• Very common to see on Windows targets
• These are dynamic RPC port bindings and can typically be ignored

2869/tcp  open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
5357/tcp  open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
10243/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

• These port bindings aid in network device discovery
• Can typically be ignored

8080/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))

• This is a very typical alternate HTTP port binding
• Explore this further if prior testing has been unsuccessful

5040/tcp  open  unknown

• Showing an example of nmap failing to detect a service
• I would completely ignore this port unless everything else failed
• If you decide to probe this further, try:
  • Manually grabbing a service banner using netcat or telnet
  • Open Wireshark and interact with the service and inspect the packets

PORT      STATE SERVICE      VERSION
8014/tcp  open  http         Apache httpd
60000/tcp open  http         Apache httpd 2.4.38

• nmap has identified these as alternative Apache HTTP server bindings
• Given the odd port numbers, I'd typically spend little time probing these until later
• You could use curl or your browser to open them up briefly and see what they look like, but do so much later after testing more common services

PORT      STATE SERVICE      VERSION
1883/tcp  open  mqtt

• An example of an atypical service you could see on a box
• When you encounter a new service for the first time, search on Google
• You could search something like: tcp 1883 mqtt pentest
• HackTricks often has excellent articles on getting you started with testing services with which you may be unfamiliar

1883 - Pentesting MQTT (Mosquitto) - HackTricks

HackTricks

PORT      STATE SERVICE VERSION
2222/tcp  open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)

• An example of an atypical SSH server binding
• The same SSH principles apply to this server as well
  • Do not try and pentest this service early on, just ignore it initially
  • If you come across a SSH key or a username and password later, that would be a good time to test those credentials on something like this

Information Re-Use

If you've discovered useful information while probing HTTP or some other service, you should always consider how this information may be able to used with services you previously looked at.

For example, maybe you found:

• Usernames and/or passwords
• SSH private keys
• Wordlists
• Backups

Can any of this be used to go back and get more information from another service?

Step 3. Exploit

By now, you should have plenty of information and a very educated guess about the potential exploit you're planning to use against the target.

You may end up using a publicly available exploit or you may end up chaining multiple vulnerabilities together. For example, you may have a FTP file upload and local file inclusion chained exploit to get a reverse shell.

Step 4. Post-Exploit Enumeration and Privilege Escalation

Congratulations! You've got a shell on the target and you're probably full of adrenaline. Now's the time keep a level head and methodically enumerate the target environment to plot the path to full system ownership.

Post-Exploit Enumeration

At this phase, we want to take inventory of the environment. We want to get a lay of the land and figure out as much as we can before we start attacking anything internally.

You can find the most up-to-date list of post-exploit enumeration tricks here:

WriteupTemplates/Generic-Writeup-Template.md at main · 0xBEN/WriteupTemplates

Contribute to 0xBEN/WriteupTemplates development by creating an account on GitHub.

GitHub0xBEN

Operating Environment

Users and Groups

Network Configurations

Processes and Services

Scheduled Tasks

Interesting Files

Privilege Escalation

Depending on the information you enumerated above, your path to privilege escalation could take any direction.

• You might find a server listening internally running vulnerable software
• An internal service might be using default credentials, leading to some other exploit
• You might find a SUID binary that gives you root access
• You might have SeImpersonatePrivilege allowing for a Potato attack
• You may find a kernel exploit
• The possibilities are endless, and that's why putting all of your effort into solid enumeration strategies will always pay off.