Conceal
Reconnaissance:
NMAP:
┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.116
All 1000 scanned ports on 10.10.10.116 are in ignored states.
┌──(kali💀kali)-[~]
└─$ sudo nmap -sU -O 10.10.10.116
161/udp open snmp
500/udp open isakmp
OS CPE: cpe:/h:allen-bradley:micrologix_1100 cpe:/h:atcom:at-320 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_xp::sp3 cpe:/o:microsoft:windows_server_2012 cpe:/a:vmware:player
OS details: Allen Bradley MicroLogix 1100 PLC, Atcom AT-320 VoIP phone, Microsoft Windows Embedded Standard 7, Microsoft Windows 8.1 Update 1, Microsoft Windows Phone 7.5 or 8.0, Microsoft Windows XP SP3 or Windows 7 or Windows Server 2012, Palmmicro AR1688 VoIP module, VMware Player virtual NAT device
We have one open port.
Port 500: running isakmp
A quick google search tells us that it is the Internet Security Association and Key Management Protocol( ISAKMP) which is commonly called Internet Key Exchange (IKE). A lot of the documentation references configuring IPsec and ISAKMP standards to build VPNs.
So there are probably other ports that are open, however, we won’t be able to see them before we establish that VPN connection. In order to do that, we need some kind of key for authentication and since this is an HTB box, we have to find this key somewhere. So what we’ll do is rerun all the nmap scans to see if we missed any ports the first time around.
Enumeration:
Port 161 is open. This usually runs the SNMP service. Let’s check that using nmap.
The port is running SNMP version 1 and was able to query the service using the default “public” community string. We see that there are a bunch of ports that are open including FTP, HTTP and SMB. We won’t get access to these ports until we establish a secure connection.
For now, we can only interact with the SNMP and ISAKMP ports. Let’s first query SNMP for any sensitive information.
SNMP - UDP 161
Knowing that snmp is open, I’ll use snmpwalk with the standard parameters:
It leaks the IKE VPN password hash!
This looks like an MD5 hash.
IKE - UDP 500
Now that we have a plaintext password, let’s try and establish a connection to the VPN. First run ike-scan to determine the IKE implementation and configuration that the host is using. UDP 500 is used for Internet Key Exchange (IKE), which is used to establish an IPSEC VPN. There is some recon I can do on the IKE using ike-scan:
Things I take from that:
The Internet Key Exchange (IKE) is encrypted with triple DES, using SHA1 hash, and modp1024.
Auth is Preshared Key (PSK)
The IKE is v1, not v2.
Connecting to IPSEC VPN
Install strongswan Next, we’ll use strongswan to establish the IPsec connection. This does not come preinstalled on Kali. To install it, run the following command.
Build Config Files We have to make changes to two files:
ipsec.secrets
ipsec.conf
In the /etc/ipsec.secrets, add the following entry.
In the /etc/ipsec.conf, add the following entry.
charondebug="all" - be more verbose to help me troubleshoot the connection.
authby="secret" - use PSK auth.
ike, esp, and keyexchange are set based on information from ike-scan.
left and right represent my computer and the target computer.
type=transport - use ipsec transport mode to connect host to host.
Then run the following command to establish the connection.
With the VPN connected, I can start recon over again and see a lot more.
NMAP: This time, nmap shows more ports, clearly a Windows host, matching what I saw in SNMP:
Enumeration:
Port 80 HTTP
I always start off with enumerating HTTP. Visit the application in the browser.
We get the default Windows Microsoft IIS welcome page. The page source doesn’t contain any sensitive information. Next, run gobuster to enumerate directories/files.
Directory listing is on, but no files:
Port 21 FTP
The nmap scan showed anonymous login is allowed.
Let’s test if we’re allowed to upload files. Create a test.txt file on the attack machine.
Upload the test.txt file on the FTP server.
But after few minutes the file was deleted, so if we want to use this, we might need to do it quickly.
Perfect! According to the nmap scan, this is a Microsoft IIS server version 10, so it should be able to execute ASP and ASPX code. Let’s test this out on the web server.
Create a test.aspx file on the attack machine and upload it on the FTP server in the same way we did before. Then execute the file from the /upload directory on the web server.
We get an HTTP error saying that the file can’t be served because of the extension configuration. So we can’t upload ASPX files. Next, let’s try an ASP file.
Create a test.asp file on the attack machine and upload it on the FTP server in the same way we did before. Then execute the file from the /upload directory on the web server.
Perfect, it does execute ASP code! We’ll use this to gain an initial foothold on the system.
Foothold:
Create a cmd.asp file on the attack machine that contains the following simple web shell.
The above code executes the whoami command and outputs it on the screen. Upload the cmd.asp file on the FTP server and view it on the browser.
We have code execution!
Nishang Shell
Download the Nishang repository and copy the Invoke-PowerShellTcp.ps1 script into your current directory.
When called, this sends a reverse shell back to our attack machine on port 1234. Setup a listener to receive the reverse shell.
Next, change the cmd.asp file to download the PowerShell script and execute it.
Start up a python server in the directory that the shell script resides in.
Upload the cmd.asp file on the FTP server and view it on the browser. We get a shell! Grab the user.txt flag.
Privilege Escalation:
Run the systeminfo command.
We’re on a Microsoft Windows 10 Enterprise 64-bit OS. Let’s first check the system privileges that are enabled for this user.
SetImpersonatePrivilege is enabled so we’re very likely to get SYSTEM using juicy-potato Users running the SQL server service or the IIS service usually have these privileges enabled by design. This privilege is designed to allow a service to impersonate other users on the system. Juicy Potato exploits the way Microsoft handles tokens in order to escalate local privileges to SYSTEM.
Let’s test it out. Grab the Juicy Potato executable and transfer it to the target machine using the following command.
Run the executable file to view the arguments it takes.
It requires 3 mandatory arguments. -t: Create process call. For this option we’ll use * to test both options. -p: The program to run. We’ll need to create a file that sends a reverse shell back to our attack machine. -l: COM server listen port. This can be anything. We’ll use 6666.
First copy the Invoke-PowerShellTcp.ps1 script once again into your current directory. Add the following line to the end of the script with the attack configuration settings.
When called, this sends a reverse shell back to our attack machine on port 6666. Next, create a shell.bat file that downloads the above shell-2.ps1 PowerShell script and runs it.
Then download the shell.bat file on the target machine.
Setup a listener on the attack machine to receive the reverse shell.
It fails to escalate privileges with the default CLSID. We can get the list of CLSIDs on our system using this script
However, let’s first manually try one of the Windows 10 Enterprise CLSIDs available on the Juicy Potato
Rerun the Juicy Potato executable with the above specific CLSID.
Last updated