DPAPI Backup Key Compromise Pt. 1: Some Forests Must Burn

Jul 28 2025

By: Alexander Sou • 9 min read

TL;DR The industry recommendation for DPAPI backup key compromise remediation is to destroy and rebuild the environment. This article aims to explore why this is the current industry guidance.

Every Blue Team’s Worst Nightmare

Imagine this scenario: every level of security fails and an attacker has landed on a domain controller (DC). An analyst notices the attackers extracted the Data Protection API (DPAPI) domain backup keys with the Mimikatz command:

lsadump::backupkeys

What now?

Microsoft’s recommendation: burn down the domain and migrate users to a new domain.

Well, That Seems Extreme

Creating a brand new domain and migrating every user to that domain is an exceptionally expensive and painful process, so why is this the recommendation for the compromise of a couple keys?

Microsoft gives this reasoning:

If a malicious actor is able to gain access to the DPAPI backup keys, it’s likely that they have acquired domain administrator-level access to the domain and have full access to its resources. An attacker may also install other backdoor systems in the domain with the level of access that they now have, hence the recommendation to migrate to a new domain.

While this is a very valid reason for drastic measures, the explanation is hardly satisfying. Some organizations may still be tempted to evict attackers from the environment and “accept the risk” of backdoors.

However, even if we ignore Microsoft’s reasoning, DPAPI backup key compromise is still a “Game-Over” scenario for the domain. The compromise of these keys gives attackers permanent, domain-wide access to secrets of countless common applications. Let’s explore the ramifications of this compromise.

DPAPI Background

At a very high level, DPAPI provides a simple interface for encrypting sensitive data. The interface allows applications to tie sensitive data to a specific local machine or specific user. It does this by including local machine or user information as part of the data protection process. For user-encrypted DPAPI data, DPAPI uses one or more user “master keys” which are formulated using the user’s password. These types of master keys are used to protect user DPAPI data. Will Schroeder has an excellent blogpost that covers how DPAPI works and an attacker can abuse it. Here are the bits of DPAPI that is important to us on the blue side:

DPAPI uses master keys to protect data
Master keys must be decrypted before they can be used to unprotect DPAPI data
Master keys can only be decrypted with the user’s password or the domain backup key
DPAPI protection is used everywhere

User-encrypted DPAPI data can be found protecting countless sensitive data blobs, including:

Google Chrome cookies and credentials
Microsoft Edge cookies and credentials
Firefox cookies and credentials
ASP.NET Core Windows keys
Skype application data
Azure persistent token caching
Microsoft Dynamics 365 for Financials keys
Credential material stored in the Windows Credential Manager
Saved RDP credentials
Outlook email account passwords

DPAPI domain backup keys are keys which can be used to decrypt any master key in the domain. This makes the backup keys incredibly powerful. As Microsoft puts it:

Due to the sensitive nature of these keys, it is imperative that access to these keys be protected and regarded as one of the most highly confidential pieces of information in the entire Active Directory domain

This insecure design is intentional. Master keys are tied to the user’s password, so in the event a user forgets their password, or has their password reset by an admin, DPAPI data protected with that password would be lost. Microsoft implemented backup keys to guarantee data accessibility.

Therefore, if an attacker has access to the DPAPI domain backup keys, they have the means to decrypt any master key they can obtain. In the case of DPAPI backup key compromise, if the attacker has access to any DPAPI-protected data, and the master key which was used to protect that data, the attacker can unprotect the data.

Can’t We Just Rotate the Keys?

Ignoring Microsoft’s advice, a natural instinct might be to look for ways to rotate the DPAPI domain backup keys. This would be the only way to secure the DPAPI process; however, Microsoft does not support any method of rotating these keys, and the keys remain unchanged throughout the entire lifetime of the AD domain. Here is what Microsoft’s documentation states:

There currently is no officially supported way of changing or rotating these DPAPI backup keys on the domain controllers. In accordance with the document MS-BKRP, 3rd parties have the ability to develop an application or script that creates a new DPAPI Backup key and sets the new key to be the preferred key for the domain. However, these 3rd party solutions would be unsupported by Microsoft

Microsoft does leave the door open for a third-party tool to implement key rotation, but the domain would remain highly exposed even if the DPAPI domain backup keys rotated. There are three reasons as to why this is.

Reason 1: DPAPI Architecture

Microsoft’s documentation suggests that a third-party tool could rotate the keys by generating a new backup key and setting that key as the preferred key for the domain. This process technically accomplishes rotating the DPAPI key; however, with the way DPAPI currently works, all current master keys would still be encrypted with the compromised backup key. The attacker would lose access to new keys generated with the new DPAPI backup key, but would still have access to all DPAPI-protected data generated prior to the key rotation.

Thus, for a tool to truly rotate the DPAPI backup key, it would have to:

Generate a new DPAPI backup key
Set the new key as the preferred key for the domain
Set the new key as the preferred key for every domain user on every host
Decrypt every master key for every domain user on every host
Re-encrypt those master keys with the new DPAPI backup key

This would be an arduous undertaking and any mistakes during the process could result in the loss of DPAPI data or the attackers retaining access to some of the master keys in the domain.

Reason 2: Compromised Master Keys

Let’s pretend Microsoft did support rotation of the DPAPI domain backup key; if the adversary compromised or exfiltrated any master keys during their attack, those master keys would remain compromised. Changing the domain backup key does not alter the key material that is used to protect and unprotect DPAPI data. To truly fix compromised master keys, we’d have to take these steps:

Identify every master keys which has been compromised
Create a replacement master key
Decrypt every data blob protected with the compromised master keys
Re-encrypt the blobs with replacement master keys

However, this process is near impossible. By its nature, DPAPI data blobs are not centralized, and DPAPI does not keep a record of DPAPI-protected data. This makes blob re-encryption infeasible.

Reason 3: The Advice We’ve Been Ignoring

Up until now, we’ve been putting aside Microsoft’s recommendation, but this recommendation is the strongest reason for abandoning the current domain. If an adversary has compromised the DPAPI backup key, the adversary has spent some amount of time in the environment with privileges equivalent to “Domain Admin”. They had sufficient permissions to make whatever modifications they wanted to the domain.

In Microsoft’s words:

If an attacker has obtained privileged access to a domain controller or a highly privileged account in Active Directory, unless you have a record of every modification the attacker makes or a known good backup, you can never restore the directory to a completely trustworthy state.

Once the adversary has attained this level of control over a domain, there are countless methods they could employ to establish persistence. Under the best circumstances, any one of those methods could take an analyst days to weeks to uncover. However, the adversary has complete control over the domain’s security telemetry. They could have tampered with security controls in a way that makes it impossible to trace their activities. The attacker could have also maliciously modified the domain ways that allow them to retake control of the domain, even if they are completely evicted. Once the domain has been this thoroughly compromised, it is nearly impossible for an organization to completely remove a competent attacker.

Some Forests Must Burn

So to recap: if your domain’s DPAPI backup keys are compromised, there is no supported way to rotate the keys. Even if there were a supported way to rotate the backup keys, elements of the DPAPI data protection process would remain compromised. Even if we could secure those compromised elements, the attacker has had dwell time in the environment with privileges equivalent to “Domain Administrator”.

While the process is exceptionally painful, the only way to fully secure the environment is to take Microsoft’s advice: migrate users and set fire to the old domain. This recommendation may be infeasible for larger organizations, so in part 2, we’ll explore different methods to partially secure DPAPI.

References

Post Views: 679

DPAPI Backup Key Compromise Pt. 1: Some Forests Must Burn

Jul 28 2025

Share

By: Alexander Sou • 9 min read

Every Blue Team’s Worst Nightmare

Well, That Seems Extreme

DPAPI Background

Can’t We Just Rotate the Keys?

Reason 1: DPAPI Architecture

Reason 2: Compromised Master Keys

Reason 3: The Advice We’ve Been Ignoring

Some Forests Must Burn

References

Microsoft DPAPI Docs:

Other DPAPI Resources:

Microsoft Domain Recovery Docs:

DPAPI Use Cases:

Sign Up For Updates From SpecterOps

Share

By: Alexander Sou • 9 min read

Every Blue Team’s Worst Nightmare

Well, That Seems Extreme

DPAPI Background

Can’t We Just Rotate the Keys?

Reason 1: DPAPI Architecture

Reason 2: Compromised Master Keys

Reason 3: The Advice We’ve Been Ignoring

Some Forests Must Burn

References

Microsoft DPAPI Docs:

Other DPAPI Resources:

Microsoft Domain Recovery Docs:

DPAPI Use Cases:

By: Kieran Croucher

Jun 2, 2025 • 20 min read

By: Hugo van den Toorn

May 21, 2025 • 9 min read

By: Kieran Croucher

Apr 22, 2025 • 19 min read

Sign Up For Updates From SpecterOps