Credential Manager
The way the Windows Credential Manager works is a bit confusing at first - if you read up on the subject, you'll find both the terms "Vaults" and "Credentials". A "vault" essentially holds records of encrypted credentials and a reference to the encrypted blobs. Windows has two vaults: Web Credentials (for storing browser credentials) and Windows Credentials (for storing credentials saved by mstsc, etc). A "credential" is the actual encrypted credential blob.
To enumerate a user's vaults, you can use the native vaultcmd tool.
beacon> run vaultcmd /list
Currently loaded vaults:
Vault: Web Credentials
Vault Guid:4BF4C442-9B8A-41A0-B380-DD4A704DDB28
Location: C:\Users\bfarmer\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
Vault: Windows Credentials
Vault Guid:77BC582B-F0A6-4E15-4E80-61736B6F3B29
Location: C:\Users\bfarmer\AppData\Local\Microsoft\Vault
beacon> run vaultcmd /listcreds:"Windows Credentials" /all
Credentials in vault: Windows Credentials
Credential schema: Windows Domain Password Credential
Resource: Domain:target=TERMSRV/sql-2.dev.cyberbotic.io
Identity: SQL-2\Administrator
Hidden: No
Roaming: No
Property (schema element id,value): (100,2)\
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.
Last updated