The Downfall Of Dpapi Top Secret Weapon

TL;DR

In recent years, the Windows DPAPI mechanism has been exploited by threat actors to extract secrets across an organization, using the immutable DPAPI domain backup key as a kind of ‘joker’ during the attack.

In this post, we demonstrate for the first time how defenders can replace their DPAPI backup key, to better defend their organization during or following an Active Directory compromise event. Replacing this key enables defenders to eliminate the ability of threat actors to indefinitely exploit a compromised key, and decrypt users’ secrets.

Overview

Data Protection API (DPAPI) is a widely-used functionality within Windows applications that encrypts sensitive data, without implementing the underlying encryption algorithm itself.

Every Windows user has a DPAPI Master Key that can be used to encrypt and decrypt data; this data may be stored either locally or remotely.

For Active Directory users, the Master Key is encrypted with the user’s password, and another copy of the key is encrypted with the domain backup key. The encrypted copy is made for recovery purposes, and allows users to recover encrypted secrets if they forgot their password.

The domain backup key is a unique RSA key pair that is generated only once during the domain inception. Currently, the only way to properly replace the key is by re-building the domain. Today, we are going to change this reality!

Setting expectations

This article will familiarize you with the following:

• DPAPI basics
• DPAPI internals
• Detecting DPAPI domain backup key dump
• Replacing the backup key as part of a remediation process
• Get new tools that automate the process

A common attack path

The following steps are commonly taken by threat actors to create a successful attack path that exploits the DPAPI backup key to extract sensitive data, such as browser credentials:

1. Dump the domain backup key from a Domain Controller.
   • Requires a set of specific permissions that are commonly found in Domain Admin accounts.
   • Dump may be done locally or remotely.
2. Decrypt domain users’ Master Keys.
   • Requires access to users’ roaming profiles; access to a profile can be achieved by using a user’s credentials, or by obtaining local administrator access to a machine where the user is logged on, or using admin access to the file share in which roaming profiles are stored.
3. Decrypt secret blobs that are tied to the decrypted Master Key.
   • Requires access to read secret data, AKA secret blob. Usually stored under a user’s profile path (%USERPROFILE%).
   • The secret blob location depends on the configuration of the storing application, but it will generally be found somewhere under the user’s profile path, which may require part of, or the same access, as above.
   • In some misconfigured environments, we observed broader access to users’ files, which allowed any user in the domain to read various encrypted blobs.

Tools that can aid in automating the process of the above steps include Mimikatz, SharpDPAPI, DSInternals, Impacket, and DonAPI.

Remediating this attack

The decryption of Master Keys and subsequent secret blobs (steps 2 and 3 above) can be remediated by rotating the compromised user’s credentials. However, once the first step of dumping the backup key has been accomplished, you cannot fully remediate the situation, as the backup key is immutable. This means that the threat actor can decrypt additional secret blobs in future attacks, without needing to perform the first step.

DPAPI recap

If you are familiar with DPAPI usage, data blobs and Master Keys, you can skip directly to the DPAPI Domain Backup key section – although it is strongly recommended to review the upcoming chapters, as they provide useful background about the role of the DPAPI backup key.

DPAPI USAGE

DPAPI allows Windows application developers to encrypt and decrypt sensitive data, without the headache of implementing the underlying encryption algorithm or managing a key.

The following diagram illustrates the encryption operation, from the perspective of a developer

The CryptProtectData function:

• *pDataIn – A pointer to the plaintext data we wish to encrypt using DPAPI.
• dwFlags – Flags related to the encryption operation. This is primarily referred because dwFlags stores, among other values, details of the encryption scope – user or local machine. The scope simply tells DPAPI whether to encrypt the data using the Master Key of the current user, or of the local machine. Data that was encrypted with the local machine scope cannot be decrypted on another machine, even when the machine is running with the same user.
• *pDataOut – A pointer to the resulting encrypted data.

More information: https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptunprotectdata

The following diagram illustrates the decryption operation from the perspective of a developer.

The CryptUnprotectData function:

• *pDataIn – A pointer to the encrypted data to be decrypted.
• dwFlags – Seldom used for decryption operations; usually set to zero.
• *pDataOut – A pointer to the decrypted plaintext data.

More information: https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptunprotectdata

A couple of additional interesting variables that are not widely used for either encryption or decryption functions are:

• *pPromptStruct – The developer may require the end user to provide account credentials in order to complete the operation and to prove the identity of the requesting user. (Google Chrome uses this function when users try to read – ‘decrypt’ – their stored passwords.)
• *pOptionalEntropy – Another seed phrase that a developer may add in order to harden the encryption of the data blob. The developer will need to provide the same phrase in order to decrypt the data.

DPAPI – encrypted data blob

Security researcher Benjamin Delpy (@gentilkiwi) did a great job of describing DPAPI-encrypted blobs using his Mimikatz tool. We won’t dive into every value of a blob structure here, as these are explained in many other places.

Instead, let’s highlight the values that are important within the scope of this post:

• guidMasterKey – A Guid representing the identifier of the Master Key that was used to encrypt this blob. This can be either a user’s Master Key or a local machine Master Key.
• pbSalt – A salt value that was generated during the encryption operation. This salt is coupled with the Master Key to encrypt the plaintext data.
• pbData – The actual encrypted data. As shown above, the blob structure contains a list of algorithms, format, and additional information related to how the data was encrypted.

Now that we understand the structure of a standard encrypted data blob, we can see that its security level relies on the Master Key specified in guidMasterKey.

Let’s take a closer look at the Master Key, in its various forms.

Master key – under the hood

Each authority (see details below) in a Windows operating system (OS) has its own DPAPI Master Key, which is used by any application running in the related authority context. The Master Key is stored to a file and encrypted at rest using one method or two methods – depending on the authority being used, and the Windows version.

Master key structure

Every Master Key can be identified with a Guid that is also used as its name. The Master Key file consists of a header, and four additional sections for the various methods with which the key might be encrypted.

The illustration below shows the Master Key file’s structure on Windows XP and above operating systems:

Explanation:

• Version – The Master Key version; commonly has a value of 2. In Windows 2000, this field is set to 1.
• Guid – The Master Key GUID identifier.
• Flags – Includes settings of the Master Key. For example, one of the flags indicates whether Section 1: User-encrypted Master Key is encrypted with the SHA1 or the NTLM hash of the user’s password.
• Sections lengths – Specifies the length of each section. Lengths can help to determine which sections are used to encrypt this Master Key.

The sections contain the actual Master Key (the one that is used to encrypt and decrypt data blobs) in an encrypted form – see brown highlights in Figure 4.

• Section 1: User-encrypted Master Key – Stores the Master Key in a user-encrypted form, where the phrase used to encrypt it is the user’s password or DPAPI_SYSTEM registry key (depending on the authority).
• Section 2: Local Encryption Key (legacy) – This legacy section, used in Windows 2000, stores a local encryption key to decrypt a local backup of the Master Key; in Windows 2000, this key is stored in Section 3. This section is not in use from Windows 2K3/XP versions, but still contains data.
• Section 3: Credential History – Stores a Guid that points to a link stored in the user’s CREDHIST file. The CREDHIST (Credential History) file maintains a chain of a local user password history, in an encrypted form. As local users may change their passwords, DPAPI requires the ability to read the password that was used to encrypt a Master Key created in the past.
  
  In Windows 2000, this section was used to store a local encrypted backup of the Master Key. This design created a risk that allowed the decryption of any user’s data blob, without knowing the user’s password or hash.
• Section 4: Domain Backup – Stores another Master Key copy that was encrypted with the domain backup key. The domain backup key is an RSA key pair in which the private and public keys are stored in the Domain Controller (DC), and the public key is also distributed to every user’s profile, enabling each user to encrypt their own Master Key. This does not back up a copy of the Master Key to the DC, but provides the ability to recover it if the domain user’s password is forgotten. As there might be more than one domain backup key, this section includes a slot for the Guid of this key. The slot is highlighted in grey in Figure 4.

During our research, we observed four different authorities within the Windows OS that utilize the Master Key structure in various ways:

• Local Machine
  • Master Key location: %WINDIR%\System32\Microsoft\Protect\S-1-5-18\
  • Sections in use:
    1. Section 1: DPAPI_SYSTEM (m) LSA secret encrypts the Master Key.
    2. Section 3: Points to an empty Guid, as this authority does not maintain a CREDHIST file, but uses the DPAPI_SYSTEM key.
  • Common encrypted data blobs path: C:\ProgramData\
  • Additional information: This Master Key is used when the application scopes the data encryption to use the local machine. The ‘CRYPTPROTECT_LOCAL_MACHINE’ flag is set.
• System Users
  • Master Key location: %WINDIR%\System32\Microsoft\Protect\S-1-5-18\User\
  • Sections in use:
    1. Section 1: DPAPI_SYSTEM (u) LSA secret encrypts the Master Key.
    2. Section 3: Points to an empty Guid, as this authority does not maintain a CREDHIST file, but uses the DPAPI_SYSTEM key.
  • Common encrypted data blobs paths:
    1. C:\Windows\System32\config\systemprofile\AppData\
    2. C:\Windows\System32\config\LocalService\AppData\
    3. C:\Windows\System32\config\NetworkService\AppData\
  • Additional information: This Master Key is used when the encryption is scoped to the user, but the process is running with either System, LocalService or NetworkService users.
• Local Users
  • Master Key location: C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID>
  • Sections in use:
    1. Section 1: Master Key is encrypted with the user’s password at the time of the key’s creation.
    2. Section 3: A Guid pointing to a link in the user’s credential history file.
  • Common encrypted data blobs path: C:\Users\<User>\AppData\
  • Additional information: Previous Master Keys of local users points to the relevant link within the CREDHIST file, as the key might be encrypted with an older password.
• Domain Users
  • Master Key location: C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID>
  • Sections in use:
    1. Section 1: User’s current AD password encrypts the Master Key.
    2. Section 4: Domain backup key encrypts the Master Key.
  • Common encrypted data blobs path: C:\Users\<User>\AppData
  • Additional information: Unlike local users, all domain users’ Master Keys are always encrypted with their latest password, because domain users do not maintain a CREDHIST file.

The preferred file

When we navigate to the Master Key’s path, we may encounter more than one Master Key file. This is because Master Keys are set to expire after approximately 90 days from the day they were created. DPAPI uses the ‘Preferred’ file, located in the same folder, to keep track of the currently used (preferred) Master Key and its expiration date.

The image below shows an example of the files that may be located in a domain user’s Master Key path:

*Note that these files are system files, and might be hidden from Windows Explorer. You can follow this method to unhide them.

The Preferred file includes a Guid to identify the file name of the preferred Master Key stored in the path, including its creation time, within a FILETIME structure:

1. PreferredMasterKey { 2.           GUID guidMasterKey; 3.            FILTETIME ExpirationTime; 4. }

By reading this file and using this function, it is possible to transform the ‘ExpirationTime’ into human-readable format:

Note that the parsed Guid identifier {a69426b8-c41e-478e-af6c-734df79bb294} matches the second Master Key shown in Figure 5: Master Key path listing #1, indicating that it is the preferred Master Key.

Public RSA domain backup key file

Another file that can be found within every domain user’s Master Key path is BK-<DOMAIN-NETBIOS-NAME>. This file is fetched from the Domain Controller through a protocol named MS-BKRP. The fetch operation is performed only once for each user profile creation.

The public RSA domain backup key file contains the public part of the backup key that encrypts a copy of a domain user’s Master Key, as shown in ‘Section 4: Domain Backup’ of the key structure. The same domain-related ‘BK-XXXX’ file appears in every user’s Master Key path:

The process of fetching the RSA public key and encrypting the Master Key copy is specified within the MS-BKRP protocol – ClientWrap subprotocol [1.3.1.2, 3.1.4.1]. The encryption operation produces a log with event ID 4692 on the workstation. The log specifies the initiated account, and the Guid of the domain backup key used.

The purpose of the domain backup process is to enable domain users to recover their Master Keys in case they forget their password. Unlike local users, who maintain a CREDHIST file, a domain user’s password might be set from the Active Directory in a password reset scenario. In that case, when the domain user logs back in using the new password, DPAPI will not be able to decrypt any Master Key, and will thus start the Master Key recovery process, using the MS-BKRP protocol.
During the recovery process, DPAPI takes the data from ‘Section 4: Domain Backup’ (MASTERKEY_DOMAINKEY) of the Master Key, and sends it to the DC over a secured RPC call, utilizing the MS-BKRP protocol. The DC decrypts the data sent by the user, and validates that the user owns this key. Finally, the DC returns the unencrypted Master Key value so that DPAPI can re-encrypt ‘Section 1: User encrypted Master Key’ of all Master Keys files with the new user’s password:

To put this recap in a nutshell: top secret data associated with domain users is encrypted with each user’s ‘preferred’ Master Key. Each Master Key is protected in two different ways: with the user’s password, and with the domain backup key. This means that secrets protection is only as robust as the user’s password or the backup key being used. Users’ passwords can be changed … but what about the domain backup key we all trust?

DPAPI domain backup key

The DPAPI Domain Backup key – let’s just call it ‘backup key’ – is a unique RSA key pair that is generated only once, when the domain is created. Microsoft did not design a method to rotate this key, or provide a method to create a new one.

The backup key is stored in the Active Directory as an LSA secret object, and is replicated across all Domain Controllers in the same domain. Members of the Domain Administrators group have the required privileges to read this key, and tools like Mimikatz and SharpDPAPI can aid in automating the dump process and conversion of the key to a PVK format. The PVK can be later used to decrypt a Master Key of any user in the domain.

One way to locate your domain’s backup key is through the DSA.msc, under ‘System’:

*Note that ‘System’ objects might be hidden. To show them, navigate to View → Advanced Features.

In default environments, we will always see four secret objects with the ‘BACKUPKEY_’ prefix:

• BACKUPEKY_PREFERRED Secret – As with the Preferred file for Master Keys, this secret stores the Guid of the actively used (preferred) backup key secret.
• BACKUPEKY_P Secret – This secret stores the Guid for the active compatible backup key. This compatible key is used in Windows 2K and below operating systems. You can set your OS to use the legacy key by modifying the registry value of ‘MasterKeyLegacyCompliance’.
• 2 x BACKUPEKY_{GUID} Secret – Stores backup key contents. One secret is for the compatible key, and the second is for the modern RSA key pair.

The MS-BKRP protocol [section 2.2.5] specifies the structure for the backup key, where it requires the use of 2,048-bit length RSA key. The following diagram shows the backup key version 2 structure in detail:

We highlighted some important segments and parameters that the protocol requires and suggests complying with:

• Required (highlighted in gray):
  • BACKUPKEY_CSP – The protocol works with RSA key pairs only. This CSP blob contains both private and public RSA key parameters, where the key must be 2,048 bits in length (keyLen).
  • BACKUPKEY_CERT – This segment must contain a DER-formatted x509 certificate. The certificate must contain the public key (pubKey) part of the RSA key pair.
  • subjectUniqueID – This field must be set with the backup key Guid in a byte-encoded format. This is the same Guid that is used as part of the backup key name shown in Figure 10: AD System objects.
• Suggested (highlighted in brown):
  • IssuerUniqueID – This field should be identical to the subjectUniqueID which is the Guid.
  • serialNumber – This field should also be identical to subjectUniqueID, however in this case, it is formatted as a BigInteger
  • notBefore, notAfter – The validity period of the certificate should be exactly 365 days.
  • domainName – This should include the full DNS domain name.

Backup key dumps

The important role of the DPAPI backup key in the domain makes it a lucrative target for threat actors. Below, we list three common methods and tools that threat actors use to dump the backup key contents. For each method, we also list ways to detect the dump operation on default environments, without the need for a commercial product.

Method 1 – LSA remote protocol [ms-lsad]

From the perspective of an adversary, Mimikatz is a great tool to dump the backup key secrets into an operatable format. First, it gets the preferred GUID identifier of the backup key; then, it dumps the secret contents and re-assembles the key pair into PVK and PFX formats. It also takes the certificate part of the backup key and exports it to a DER-formatted file. For the legacy key, Mimikatz just exports the key contents:

The operation shown above is done through a protocol named MS-LSAD. This protocol allows interacting with AD secret objects, where section 3.1.4.6.6 (LsarRetrievePrivateData) specifies the operation used to extract the data of a secret (such as the backup key). The SharpDPAPI tool dumps the backup key contents in the same way.

Detection

Following are a few specific tactical approaches to detect and hunt for this type of key dump:

• Monitor the entire environment for the execution of binaries with suspicious command line arguments (Enable command line auditing and monitor Event ID 4688):

1. lsadump::backupkeys 2. backupkey

• The log below illustrates backup key dump using SharpDPAPI:

• Monitor Active Directory for Object access (Configure audit policies and object auditing, and monitor Event ID 4662) of ‘SecretObject’ object type, where the accessed Object Name contains ‘BACKUPKEY’, and Access Mask is 0x2:

• If Microsoft Threat Analytics is installed, you may detect this operation using this alert.

Method 2 – ntds.dit

Another way to get the backup key content is by dumping the NTDS.dit database. As the backup key is an Active Directory object, it will also be included within its database. One way to dump the NTDS.dit is to use the built-in tool ‘Ntdsutil’ on a Domain Controller:

Once the operation is completed, we can go offline and use the DSInternals framework with the ‘SYSTEM’ hive and NTDS.dit database, to extract the backup key and re-assemble it to PFX and PVK formats:

Detection

The following are specific tactical approaches to detect and hunt for this type of key dump:

• Monitor Domain Controllers for events related to the usage of NTDS dumping tools and commands (Enable command line auditing and monitor Event ID 4688):
  • Processes: ntdsutil.exe, Diskshadow.exe, NTDSDumpEx.exe, NTDSDump.exe, vshadow.exe
  • Command arguments:

1. vssadmin shadows 2. vssadmin create shadow /for= 3. copy \\?\GLOBALROOT\Device\\*\windows\ntds\ntds.dit 4. copy \\?\GLOBALROOT\Device\\*\config\SAM 5. reg SAVE HKLM\SYSTEM 6. esentutl /y /vss *\ntds.dit* 7. esentutl /y /vss *\SAM 8. esentutl /y /vss *\SYSTEM 9. esentutl /m 10. \windows\ntds\ntds.dit 11. ntds.dit 12. ntds 13. ntdsutil 14. vshadow 15. Diskshadow 16. Invoke-NinjaCopy 17. vssown.vbs 18. Copy-VSS 19. VolumeShadowCopy 20. VolumeShadowCopyTools 21.”\”ifm\” \”create’

• The following log illustrates the usage of ‘ntdsutil’ to dump NTDS:

• Monitor for NTDS database creation and detachment within the ESENT event source (application log). Search for event IDs 325, 327, and 216 where the description contains the NTDS database location: \Windows\NTDS\ntds.dit:

Method 3 – dcsync

A less commonly used method to dump the backup key is by using DCSync. The backup key is replicated in the same way that any other AD object is replicated across DCs. Mimikatz implements its DCSync capabilities in a way that allows us to retrieve data based on the AD object Guid. To dump the backup key contents, we first need to get its AD object Guid – which is different from the backup key Guid:

Detection

The following are specific tactical approaches to detect and hunt for this type of key dump:

– Monitor for DC replications from a non-Domain Controller account name.

• Look for event ID 4662 where access mask is 0x100, and the operation properties are any of the following replication access rights:
  • DS-Replication-Get-Changes – {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}
  • DS-Replication-Get-Changes-All – {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
  • DS-Replication-Get-Changes-In-Filtered-Set {89e95b76_444d_4c62_991a_0facbeda640c}

Game on

You just realized that a threat actor dumped your DPAPI backup key, and is running all over your network to decrypt DPAPI secret blobs through SMB connections. In terms of the backup key (PVK) the attacker is using, there is nothing you can do. The backup key is permanent, and there is no option to replace it without creating a new domain:

This led us to apply the knowledge we gained through researching this topic, and develop a method that replaces this key. This method was implemented to a new tool named DPAPI Backup Key Manager a utility aimed at helping defenders and IT administrators to secure the exploitation of a DPAPI backup key exposure.

Preferring a new DPAPI backup key

Unlike other keys, credentials, and passwords, we do not want to rotate or overwrite our existing backup key, as all users’ Master Keys in the organization are encrypted with it as a recovery method. If we rotate this key, any users in our domain who forget their passwords will simply lose all access to browser-stored passwords, email accounts, wireless network keys, RDP connections, Credential Manager-stored passwords, and more. Instead, we are going to solve the problem both from the server side, and the client side. We can do this by adding a new backup key, and forcing users to select this key to encrypt their Master Keys.

Server-side

The following process is used on the server side (DC):

1. Generate a new DPAPI backup key (GenerateNewBackupKey).
2. Import the key as a secret object to the Active Directory (–push).
3. Set the new backup key as the preferred one by placing its Guid in G$BACKUPEKY_PREFERRED secret (–set).

4. Restart the DC for the changes to take effect. The MS-BKRP protocol is an RPC interface that is handled by the LSASS process, and must be reloaded after setting a new preferred key. Note that the new key settings will be replicated to other DCs in the domain shortly after this operation; this means that they also require a restart.
5. Validate the MS-BKRP setup against every DC in the domain. Verify the GUID of the recently set key:

Important: Do not start the client-side phase before validating the MS-BKRP setup against all DCs.

Client-side

New domain users that are created after the server-side process will receive the new public backup key part (BK-XXXXX file) during their profile initiation.

The bigger issue is existing domain users, as they already fetched the public backup key part, and will not replace it as long as it exists in their path. Also, the older the user, the more Master Key files the user owns.

To deal with this issue, we came up with a script that IT admins can use to onboard existing users to encrypt their Master Keys with the latest preferred backup key. The script must be executed from the user context, so it may be implemented for users through GPO, Logon Script, Intune, etc.

By using this method, we state that from this point onward, any new Master Key that a user generates will be backed up (encrypted) with the new backup key. Existing Master Keys will continue to be backed up by previously-preferred backup keys, and decryptable in a recovery scenario – as shown in Figure 9: Master recovery process. This is the reason we should never delete older backup keys.

Onboarding a user:

1. Rename the ‘BK-XXXX’ file from the Master Key path:
   C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID>.
2. Expire the currently Preferred Master Key.
3. Trigger the DPAPI.
   1. DPAPI will generate a new Master Key and encrypt it with the user’s password.
   2. DPAPI will fetch the new public backup key.
   3. DPAPI will encrypt the Master Key with the new public key as well.

* We may skip steps 2 and 3 if we don’t mind waiting for the Master Keys to expire (90 days max).

Once the operations of preferring a new backup key and onboarding domain users to use it have been performed, we may want to verify whether users have any Master Keys encrypted with the old, exposed backup key. We can use the same utility (executed from the subject user’s context) to check this:

The script to onboard existing users is included in the BackupKeyManager repository, and can be found here. More information on the usage is included in the README. This method does not replace existing Master Keys, rather it creates new ones to rely on when encrypting DPAPI data.

Conclusion

While delving into the backup key role, process, and structure, we can hazard a guess as to why Microsoft did not equip IT administrators with a method to replace this key themselves. The impact of overwriting an existing backup key, or the need to onboard users to a new key, makes this process way more complicated than a simple process like password reset. The complexity of implementing this process into legacy systems that used DPAPI in an earlier version might also be a reason. But from our point of view, even if we take these difficulties into account, we still see a potential risk in keeping the initial backup key forever – especially following an Active Directory compromise. The option of re-building the domain from scratch is not even accounted for in most organizations, given the wide impact and difficulty of implementation. These are some of the considerations that inspired us to create this key replacement method, with zero operational impact in mind. This method can now be added to your AD compromise remediation process, and treated with the same importance as regularly rotating the KRBTGT account, or immediately rotating compromised credentials.

And remember: if anything goes wrong, you can always revert to your original Preference 🙂

Refernces

Other DPAPI-related posts:

• https://docs.microsoft.com/en-us/previous-versions/ms995355%28v%3Dmsdn.10%29
• https://docs.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection
• https://web.archive.org/web/20211212230634/https://support.microsoft.com/en-us/topic/bf374083-626f-3446-2a9d-3f6077723a60
• https://o365blog.com/post/adsync/#what-is-dpapi
• https://www.usenix.org/legacy/event/woot10/tech/full_papers/Burzstein.pdf
• https://www.passcape.com/windows_password_recovery_dpapi_analyse
• https://www.passcape.com/windows_password_recovery_dpapi_credhist
• https://www.passcape.com/index.php?section=docsys&cmd=details&id=28
• https://blog.harmj0y.net/redteaming/operational-guidance-for-offensive-user-dpapi-abuse/
• https://sudonull.com/post/6370-Secrets-DPAPI-or-DPAPI-for-pentesters
• https://cdmana.com/2021/04/20210419171504164n.html
• https://threathunterplaybook.com/library/windows/data_protection_api.html

Related tools:

• https://github.com/gentilkiwi/mimikatz
• https://github.com/GhostPack/SharpDPAPI
• https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Get-ADDBBackupKey.md
• https://github.com/SecureAuthCorp/impacket/blob/master/examples/dpapi.py
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc753343(v=ws.11)
• https://github.com/gentilkiwi/basic_rpc

Basics structures, formats and libraries:

• https://docs.microsoft.com/en-us/windows/win32/api/dpapi/
• https://docs.microsoft.com/en-us/dotnet/api/system.guid?view=net-6.0
• https://docs.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime
• https://renenyffenegger.ch/notes/Windows/dirs/Users/username/index
• https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=net-6.0
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adsc/4ebb9507-6460-4d3c-a9f9-e21608708598
• https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh848267(v=ws.11)#:~:text=Roaming%20User%20Profiles%20%20
• https://web.archive.org/web/20170531040754/http:/www.drh-consultancy.demon.co.uk/pvk.html
• http://oid-info.com/get/1.3.14.3.2.29
• https://www.rfc-editor.org/rfc/rfc8017.txt
• https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/ns-wincrypt-cert_info#syntax
• https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.dataprotectionscope?view=dotnet-plat-ext-6.0#fields

Microsoft-related protocols:

• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-bkrp/90b08be4-5175-4177-b4ce-d920d797e3a8
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lsad/1b5471ef-4c33-4a91-b079-dfcbb82f05cc
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adsc/9abb5e97-123d-4da9-9557-b353ab79b830
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/cca27429-5689-4a16-b2b4-9325d93e4ba2

Windows Event logs:

• https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4692
• https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
• https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5145
• https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4663
• https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656
• https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688

This advisory and any information or recommendation contained herein has been prepared for general informational purposes and is not intended to be used as a substitute for professional consultation on facts and circumstances specific to any entity. While we have made attempts to ensure the information contained herein has been obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study, and needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results obtained from the use of this Advisory. This Advisory is provided on an as-is basis, and without warranties of any kind.