Vault
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 4000 -Pn 192.168.240.172
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-07 15:05 +08
Nmap scan report for 192.168.240.172
Host is up (0.18s latency).
Not shown: 65514 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
5985/tcp open wsman
9389/tcp open adws
49666/tcp open unknown
49667/tcp open unknown
49669/tcp open unknown
49670/tcp open unknown
49671/tcp open unknown
49689/tcp open unknown
49704/tcp open unknownLoads of ports.
Guest Shares
There were some shares that smbmap picked up on with guest credentials:
Within the DocumentsShare share, there was nothing within it:
There was nothing else about this machine. This reminded me of a few HTB machines where we had to place a malicious file that would trigger a user to click on, which would send requests to our attacker machine and allow us to capture NTLM hashes on responder.
There a few methods of creating such files, but I used this repository:
Afterwards, we can place this file within the share and start a responder instance, which would immediately capture a hash:

This can be cracked almost instantly:
Then, we can evil-winrm in:

Privilege Escalation
Server Operators -> DA
Our current user was part of the Server Operators group:
Since we are part of this group, we can do loads of things like manipulate services and what not.
We can abuse the VMTools service.
A SYSTEM shell would spawn on a listener port:

Rooted!
Last updated