Anubis
Webserver Shell
Nmap scan:
$ nmap -p- --min-rate 5000 -Pn 10.129.190.189
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-15 04:21 EDT
Nmap scan report for 10.129.95.208
Host is up (0.024s latency).
Not shown: 65531 filtered tcp ports (no-response)
PORT STATE SERVICE
135/tcp open msrpc
443/tcp open https
445/tcp open microsoft-ds
593/tcp open http-rpc-epmap
49703/tcp open unknownWindcorp -> SSTI
crackmapexec can be used to enumerate domain name.
$ crackmapexec smb 10.129.190.189
[*] completed: 100.00% (1/1)
SMB 10.129.190.189 445 EARTH [*] Windows 10.0 Build 17763 x64 (name:EARTH) (domain:windcorp.htb) (signing:True) (SMBv1:False)Visiting windcorp.htb does not show anything though. In this case, we can do a sub-domain enumeration and find something.
Add the domains to the /etc/hosts file, and www is visited it shows a typical corporate page:
When we fill in the Contact and try to submit, it let's us preview our submission at preview.asp.
Here's the HTTP request for the Send function, which is a GET request to save.asp:
Interesting. Since this is using asp, and the output is printed on another screen, we can test some SSTI. I used this payload:
And this was returned:
This confirms that SSTI is possible on this machine, and that we can use this to gain a reverse shell (if there's no AMSI / AppLocker).
Using this, we can get a reverse shell easily.
Localadmin Creds
Cert Rq -> Port Forwarding
Perhaps the first thing we notice is that we are already the SYSTEM user. This is a little early for an Insane machine, so it's probably one of the hosts in the domain. I thought that there would be a flag within the administrator's desktop, but instead I got a certificate:
We can transfer this back to our machine for analysis using openssl.
We can see that it makes requests to a softwareportal.windcorp.htb domain. However, when trying to visit it, nothing is loaded. This must mean that the domain is listening within the machine only.
First, let's see if there are any web servers active on the machine itself.
The error tells me that there's something present there, so let's do some port forwarding for the machine using chisel.
Afterwards, we can add softwareportal.windcorp.htb within our /etc/hosts file under 172.25.80.1, and visit it using our browser (with FoxyProxy Proxychains).
VNC -> Responder Creds
Within the software present on the page, we can see that there is a VNC service available.
When we click on it, it would show us this page before going back to the main website. The URL also contains another IP address:
Since VNC is like an RDP software, there might potentially be credentials beign sent in the packets, so I started wireshark and also changed the client parameter to be my IP address. When the packets are viewed, we can see a lot of failed TCP requests:
This occurs because port 5985 is not open on our machine. So, using this SSRF, we can start responder and intercept the request to retrieve any NTLM hashes, which works:
We can then crack this hash easily using john:
Then, we can verify these creds with with SMB:
Diego Shell
SMB Access
We can enumerate the shares as localadmin.
We can view Shared first.
I got a bit lazy, so I recursively downloaded all of the files from this share.
Here, we can see some .exe and .omv files, which are associated with Javmovi.
Javmovi RCE
When researhcing for Jamovi exploits, I came across this:
The author of the PoC above is also the creator of this box, so I think we need to exploit something similar for this. The intended method is probably to run and install Jamovi on a Windows instance and then perform the XSS, but there are faster methods, such as here:
We can follow this PoC and unzip the file, then modify our metadata to include our XSS payload. First, let's craft our JS shell:
Then, we can change the name parameter to this:
Afterwards, re-zip the Whatif.omv file together, and host the respective Python HTTP servers. Then, we need to use smbclient to delete the old Whatif.omv file on the share and replace it with our own.
Then we just wait. After a while, we would start to get calls on our HTTP servers and get a reverse shell as the user.
We can then grab the user flag.
Privilege Escalation
ESC1 Exploit
Earlier, we saw a share about CertEnroll, which is a possible exploit path to get an Administrator shell. First, let's use Certify.exe to locate any vulnerable templates on the machine.
It seems that the webdevelopers group has Full Control over this one template, and makes it vulnerable to some exploits:
However, we have to note that this template is used for Server Authentication instead of Client Authentication. This means that we cannot directly request a certificate and use rubeus to obtain the NTLM hash of the administrator yet.
We have to either change this or make it such that we can still impersonate the administrator. I couldn't really figure this part out, so I used a writeup that redirected me to this repo:
The repo itself explains the exploit in detail, something I found rather helpful. Basically, we want to create a 'Smart Card' for the user, and allow the certificate to be used for Smart Card authentication. This would allow us to impersonate the user using this new certificate.
Afterwards, when we check Certify.exe, we can see that the vulnerable template has changed:
Afterwards, we can use Get-ChildItem to retrieve the certificate's ID, and rubeus to request for the NTLM hash of the administrator:
Then, using this hash, we can easily psexec.py in as the administrator and grab the root flag:
This part was pretty hard for me, and I had to use a walkthrough because I couldn't find the right tools to use. Great machine though!
Last updated