It implements a Symmetric Cypher to encrypt credentials before store them here
These credentials are stored in the form of Blobs or VCRD files
Important
Note that Blobs are encrypted directly by the Data Protection API (DPAPI) using the User’s Masterkey
While .VCRD files are encrypted with the VEK (Vaul Encryption Key) and the VEK, in turn, is encrypted by DPAPI using the User’s masterkey
The Windows Credential Manager is the API/Interface where a user can view as entries the information related to the data contained within the Blobs and VCRD files
Therefore, the following elements stand out →
Masterkey
System File Attribute Enabled
Format (GUID - 256 Bits) → 36 Hex Chars e.g. cc6eb538-28f1-4ab4-adf2-f5594e88f0b2
Symmetric Encryption Key randomly generated the first time a user logs in to a system
Usually, there is one per Logon Session i.e., one per user, at least until the user’s password is changed
This masterkey is used by the Data Protection API (DPAPI) to encrypt data such as →
Blobs
.VPOL Files
Credentials (Chrome, OneDrive…)
In turn, this masterkey is also stored encrypted
According to the type of user, domain or local account, the key used to encrypt the masterkey differs →
Local User
Masterkey encrypted using a key derived from the User’s password by applying a PBKDF2 with SHA1 or SHA512, depending on the version of the Windows System
Domain User
Masterkey encrypted using the Backup Key generated by the DC
Storage Path
%APPDATA%\Microsoft\Protect
Credential File
System File Attribute enabled
BLOB
Format → 32 Hex Chars e.g. 85E671988F9A2D1981A4B6791F9A4EE8
This Binary Long Object contains the encrypted user credentials in a binary format
It is directly encrypted by the Data Protection API (DPAPI) using the User’s masterkey
This type of file is not part of the modern Windows Credential Locker (Windows Vault)
This is the classic storage method of storing the user’s secrets → Credential Blob encrypted by DPAPI
The steps below follow the manual process of decrypting Users’ secrets stored in the form of Blobs or stored in the Windows Credential Locker, both on Disk
But, before proceed with them, if we log into any system as a Local Admin Account and we are able to launch a process with a High IL (Full Access Token), we can extract the Users’ secrets stored in the LSASS.exe’s memory space
Note that sekurlsa::credman only reads the Active Logon Sessions on LSASS.exe
Therefore, it will only get the ones that were used recently and are stored in memory
To make sure that we collect all stored credentials, just follow the below steps
Local Admin Account
Masterkey encrypted with a Key derived from the User Password using PBKDF2-HMAC-SHA1 or SHA512
If an attacker logs on system as a Local Admin User, it is not necessary to decrypt the Masterkey by providing the User’s password
I.e., As a Local Admin User, a process launched with a Full Access Token has the required privileges in order to be able to access the LSASS.exe space memory
Important
Be aware that, on modern Windows System, several measures are usually implemented to prevent access to the LSASS.exe Memory Space from an arbitrary process
Lsa Protection → LSASS.exe runs as a PPL (Protected Process Light)
Credential Guard → LSAISO.exe runs in an Isolated Virtual Environment
Therefore, we could proceed as follows →
Plain Text Masterkey Extraction
RunAsPPL and Credential Guard disabled
To extract Plain Masterkeys of all users with an active logon session on the system →