DPAPI — a popular vector for attacks on Windows-family OSes

DPAPI — a popular vector for attacks on Windows-family OS 💻

Wi-Fi keys, certificates, credentials, browser cookies, DropBox, Skype — and that’s only part of the targets that attackers aim for.

Today we’ll look at what happens if a user has saved credentials on a workstation joined to an Active Directory domain, and an attacker has loaded the well-known Mimikatz onto it.

👀 First, let’s look at how DPAPI is connected to user credentials and other secrets.

The DPAPI interface has been used by Microsoft in Windows since 2000. It allows sensitive user data to be stored in encrypted form.

What does this interface use to encrypt data?

• The user’s SID;
• the password hash;
• the Masterkey — the key entity that attackers will hunt for.

The Masterkey, in turn, is generated from so-called prekeys and 64 random bytes. The SID, the user’s password hash, and the Masterkey, through cryptographic manipulations, form a blob. Therefore, to decrypt, the attacker needs to know the specific blob that needs to be decrypted, the Masterkey in plaintext form, the user’s password hash, and their SID for decryption.

🗂 The aforementioned objects and parameters are contained in various folders and registry hives. We are interested in the following folders:

• Folder with the credential blob

\Users\<user>\appdata\local\microsoft\credentials\<credential blob>Code language: plaintext (plaintext)

• Folder with user masterkey files

\Users\%USER%\AppData\Roaming\Microsoft\Protect\%SID%Code language: plaintext (plaintext)

• Folder with private RSA key files

%APPDATA%\Roaming\Microsoft\Crypto\RSA\<SID>Code language: plaintext (plaintext)

A single user can have multiple masterkeys on a host. The attacker will first need to find out which masterkey is currently being used for the credential blob.

While on the host and having loaded Mimikatz, the attacker can find this information by reading the properties inside the blob using the mimikatz command:

dpapi::cred /in:C:\users\<username>\appdata\local\microsoft\credentials\<blob>Code language: YAML (yaml)

💡 Disclaimer: if the commands are executed via Cobalt Strike or another C2, the command syntax will be different.

To correctly identify the Masterkey, attention must be paid to the guidMasterkey parameter — this is the identifier of the Masterkey that was used to encrypt this blob. Thanks to the fact that in our case the workstation is joined to the domain and has a connection to it, the backup RSA key can be requested from the domain controller.

It is important to note here that the attacker can only request it for their own authorized user. In order to request this key for all users and decrypt all Masterkeys, domain administrator rights will be required.

The request for the RSA key to the domain controller will be performed via the MS-BKRP (backupkey remote protocol) RPC service:

dpapi::masterkey /in:C:\users\<username>\appdata\roaming\microsoft\protect\<SID>\<masterkey> /rpcCode language: YAML (yaml)

In response, the attacker will receive the masterkey in plaintext form (the key: parameter) and its sha1 hash.

After that, they can attempt to decrypt the user’s credentials and obtain the password in plaintext form.

They will do this using the command:

dpapi::cred /in:C:\users\<username>\appdata\local\microsoft\credentials\<blob> /masterkey:<masterkey_as_plain_text>Code language: YAML (yaml)

And will get as output, in the CredentialBlob: parameter, the password of the compromised user 💻

🔦 To detect the activity, a combination of events on the attacked workstation (1, 2) and the domain controller (3) can be used:

1. Event ID 4663, application of access rights to an object. Here, objects are understood as the contents of the aforementioned folders with the credential blob, user masterkeys, and private RSA keys. Access to the objects of these folders will be performed in the context of the compromised user.

2. Establishment of a TCP connection with the DC, Sysmon 3 on port 445. Its availability can be checked by creating, in the context of the compromised user, a Sysmon 17 named pipe with the PipeName parameter: \\protected_storage.

3. Access to a network resource with Event ID 5145. Despite the large number of events, this event can be correlated with the previous ones, since the access is performed in the context of the compromised user to the shared folder \\IPC$\Protected_Storage, which was already mentioned in the second point. Access to Protected_Storage is one of the indicators of possible DPAPI manipulation.

#DPAPI #win #hunt #ti #detect
@ptescalator