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  unknown

Loads 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