Last updated
Last updated
To enumerate a user's vaults, you can use the native vaultcmd tool.
Another is to use Seatbelt with the -group=user parameter, or more specifically, the WindowsVault parameter.
Based on this, we now know that the user has saved credentials for the local administrator account on SQL-2. The encrypted credentials themselves are stored in the users' "Credentials" directory.
Seatbelt can also enumerate them using the WindowsCredentialFiles parameter.
As far as I'm aware, there is no way to know which credential blob belong to which vault; and by extension, if a vault has multiple entries, which credential blob corresponds to which. This just ends with us having to decrypt each one in turn.
Seatbelt also provides the GUID of the master key used to encrypt the credentials. The master keys are stored in the users' roaming "Protect" directory. But guess what... they're also encrypted.
So we must decrypt the master key first to obtain the actual AES128/256 encryption key, and then use that key to decrypt the credential blob. There are two ways of doing this.
The first is only possible if you have local admin access on the machine and if the key is cached in LSASS. It will not be in the cache if the user has not recently accessed/decrypted the credential.
We can see that the GUID matches what we are looking for, so the key 8d1539[...]19c214 is the one we need.
Another way to obtain the master key (which does not require elevation or interaction with LSASS), is to request it from the domain controller via the Microsoft BackupKey Remote Protocol (MS-BKRP). This is designed as a failsafe in case a user changes or forgets their password, and to support various smart card functionality.
This will only work if executed in the context of the user who owns the key. If your Beacon is running as another user or SYSTEM, you must impersonate the target user somehow first, then execute the command using the @ modifier.
Finally, the blob can be decrypted.