写给蓝军的滥用DPAPI操作指南（上）

我以前谈到过 DPAPI (数据保护应用程序编程接口) ，包括 KeePass 如何使用 DPAPI 作为其"Windows 用户帐户"关键选项。 最近，我深入研究了 Benjamin Delpy 在 DPAPI 方面所做的一些令人惊叹的工作，并且想要记录一些关于与 Mimikatz 一起滥用 DPAPI 的操作记录。

注意: 在这篇文章中，我关注的是基于用户的 DPAPI 滥用问题，但在某种程度上，我也打算深入研究机器的 DPAPI 密钥滥用问题。 如果我能够理解这些特定的弊端，我会起草一个后续的博文。

另一个注意事项: 我没有提出这些滥用原语，也没有编写用于滥用它们的工具。 这些都是本杰明和其他人在本文中引用的作品。 我只是将这些滥用案例和句法记录下来作为操作指南。

DPAPI速成课程

我也不会谈论太多的 DPAPI 背景，因为其他人已经做得更好了:

本杰明的 wiki 示例(这里, 这里及这里以及各种与 DPAPI 相关的推文)

· 巴托斯 · 英格洛特在OPCDE 2017的议题“DPAPI 黑盒子揭秘”

Paula J 在 Black Hat Europe 2017 的议题 “DPAPI 和 DPAPI-NG ”

· “在渗透测试和密码破解期间的 DPAPI 漏洞利用” 作者: Jean-Christophe Delaunay (@Fist0urs @ fist0urs)

· “告诉我密码我就能统治世界”( "弗朗西斯科 · 毕加索(@dfirfpi)，跟进文章在这里,以及他的"ReVaulting” 议题

· 伊泰 · 格雷迪 在@BsidesTLV的议题“在域环境中保护浏览器的秘密”

· “解密 DPAPI 数据”作者: Jean-Michel Picod 和 Elie Bursztein

· @_rastamouse 发表的很棒的博文跳转网络分割，其中包括了关于使用 Mimikatz 解密加密的DPAPI RDP 凭据块

我确信我已经遗漏了一些现有的工作，但是以上这些资源是我了解 DPAPI 的工作原理及其滥用的潜在可能性的参考。

DPAPI提供了一组简单的 API，可以使用绑定到特定用户或系统的隐式加密密钥轻松地加密(CryptProtectData())和解密(CryptUnprotectData())不透明的数据"块"。 这使得应用程序可以保护用户数据，而不必担心密钥管理之类的问题。 有很多东西都在使用 DPAPI，但我只关注 Chrome cookies / login Data、 Windows 凭证管理器/ Vault (例如保存的 IE/Edge登录和文件共享/RDP 密码)和远程桌面连接管理器的.rdg后缀的文件。

在较高的级别上，对于用户场景，使用用户的密码来派生特定于用户的"主密钥"。 这些密钥位于 C:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>，其中 <SID>是用户的安全标识符，GUID 是主密钥的名称。 一个用户可以有多个主密钥。 这个主密钥需要使用用户的密码或域备份密钥(请参阅 Chrome，场景4)进行解密，然后用于解密任何 DPAPI 数据块。

因此，如果我们试图解密用户的已加密的 DPAPI 数据块(比如 Chrome cookie 值) ，我们需要获得特定用户的主密钥。

Chrome

Chrome使用 DPAPI 存储了我们关心的两个主要信息: cookie 值和保存的登录数据:

· Cookie 文件位置:%localappdata%\Google\Chrome\User Data\Default\Cookies

· 保存的登录数据位置: %localappdata%\Google\Chrome\User Data\Default\Login Data

%localappdata%在大多数系统上映射到了" C:\Users\<USER>\AppData\Local "。 此外，本节中的任何 Mimikatz 命令都可以用于"Cookie"文件或"Login Data"文件。

Chrome 将其 cookie 存储在 SQLite 数据库中，cookie 值本身作为加密的 DPAPI 数据块加以保护。 幸运的是，Benjamin 在 Mimikatz 中实现了 Chrome SQLite 数据库的解析！ 要列出当前用户可用的 Cookies，可以运行以下 Mimikatz 命令:

mimikatz dpapi::chrome /in:”%localappdata%\Google\Chrome\User Data\Default\Cookies”

然而，实际的 cookie 值使用了用户的主密钥进行加密的 DPAPI，而主密钥又受到用户密码(或域备份密钥)的保护; 在尝试检索这些 cookie (或登录数据)值时，我们可能会遇到两种情况。

场景1: 在目标用户的上下文中执行代码

这可能是最简单的情况。 如果你有一个 Beacon或者Mimikatz或者是其他代码正在你的目标用户的上下文中运行，只需将 /unprotect 标志添加到 dpapi: : chrome 命令中:

这只是指示 Mimikatz 使用 CryptUnprotectData API 为我们解密这些值。 因为我们在用户的上下文中执行代码，所以他们的密钥将被隐式地用于解密。

注意: 有时候你会遇到一个问题，就是当 Cookies 数据库被 Chrome 使用时会无法打开。 在这种情况下，只需将 cookies / login Data 文件复制到当前操作位置，并使用新路径运行 dpapi: : chrome 命令。

场景2: 目标用户当前登录的计算机上的管理访问

如果你不想将信标注入到其他用户的上下文中，或者你的跳板机上当前登录了多个用户，那么你有几个选项可以执行。

如果在由不同用户拥有的给定数据库上运行 /unprotect ，则在试图调用 CryptUnprotectData ()时会出现错误。 Mimikatz 的新版本实际上将识别所需的 masterkey 的 GUID (一旦 Mimikatz 在 Cobalt Strike 中更新，它将在输出中显示出来) 在下面的 mimikatz.exe 示例中，所需主密钥的 GUID 为{ b8854128-023c-433d-aac9-232b4bca414c } :

我们可以推断出图中圈出的是 harmj0y的基于 Chrome Cookies文件夹的位置的主密钥。 我们还可以通过列出用户文件夹(C:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>)中的主密钥 GUID来跟踪任何用户的密钥。 请参阅Seatbelt 部分，了解如何为所有用户轻松做到这一点。

因此，我们需要以某种方式获取这个特定的 harmj0y 的主密钥。 一种选择是运行 sekurlsa: : DPAPI 从当前登录到系统的用户的内存中提取所有 DPAPI 密钥(偶尔也会出现在 sekurlsa: : msv 中) :

注意: 如果你没有通过 Beacon 使用 mimimikatz，那么你可以利用 Mimikatz 的 DPAPI 缓存(请参阅本文末尾的 Cache 部分) 由于 Beacon 的作业架构，每个 mimikatz 命令都将在一个新的进程中运行，因此 mimimikatz 命令之间不会保留状态。 目前还没有一种方法可以通过 GUI 发送多个 mimikatz 命令，尽管可以通过攻击者脚本来实现。

将GUID  { b8854128-023c-433d-aac9-232b4bca414c }匹配到的DPAPI 密钥提取出来，我们需要的 SHA1主密钥是 f35cfc2b44aedd7... (可以使用完整的主密钥或 SHA1版本)。 可以手动为 DPAPIChrome 模块指定此选项，可以执行如下命令：

beacon> mimikatz dpapi::chrome /in:”C:\Users\harmj0y\AppData\Local\Google\Chrome\User Data\Default\Cookies” /masterkey:f35cfc2b44aedd7…

场景3: 目标用户在当前未登录的计算机上的管理访问

如果目标用户当前没有登录到系统，你需要知道他们的明文密码或 NTLM 散列。 如果你知道它们的明文密码，你可以使用 spawnas/runas 来生成一个新的代理作为特定的用户运行，然后在目标用户的上下文中运行

beacon> mimikatz dpapi::chrome /in:”%localappdata%\Google\Chrome\User Data\Default\Cookies” /unprotect

或者，也可以运行 

dpapi::masterkey /in:<MASTERKEY_LOCATON> /sid:<USER_SID> /password:<USER_PLAINTEXT> /protected

(用于现代操作系统) :

如果你只有一个用户的散列，则可以使用 Mimikatz 的 sekurlsa:: pth 产生一个新进程(或使用 Beacon 的 pth 包装器获取模拟令牌)。 但是，由于 Mimikatz 在新的登录会话中使用的登录类型是9(例如：NewCredentials/netonly)作为凭据，所以这些凭据不会在本地主机上使用，因此仅仅使用 / unprotect 将会失败，并会出现相同的 NTE_BAD_KEY_STATE错误。

但是，由于这些凭证将在网络上使用，我们可以使用 Mimikatz 利用 MS-BKRP  (BackupKey Remote Protocol)为我们检索密钥，因为密钥属于当前用户。 Benjamin 在他的 wiki 上详细记录了这个过程(在本文的"Credential Manager and Windows Vaults"部分的最后有更多细节) 实现这个 RPC 调用的代码位于 kull_m_rpc_bkrp.c文件中。 我们所需要做的就是指定主密钥的位置并提供 / rpc 参数标志：

beacon> mimikatz @dpapi::masterkey /in:”C:\Users\dfm.a\AppData\Roaming\Microsoft\Protect\S-1–5–21–883232822–274137685–4173207997–1110\ca748af3–8b95–40ae-8134-cb9534762688" /rpc

注意: 模块前的@前缀是必要的，因此 Beacon 强制 Mimikatz 使用模拟线程令牌来模拟新的 Mimikatz 进程。

From here, we can take this masterkey and manually specify it to decrypt what blobs we want (syntax is in scenario 2.)

从这里，我们可以使用这个主密钥并手动指定它来解密我们想要的数据块(在场景2中提到的)。

场景4: 提高域访问权限(即 DPAPI 上帝模式)

这是最有趣的一个场景;

一个选择是利用 DCSync 同步一个目标用户的散列并重复场景3。 但是有一个更好的办法！

域用户主密钥也使用域范围的备份 DPAPI 密钥进行保护。 这就是实际使用 /rpc 命令对每个用户密钥进行解密的方法，也是体系结构的一部分。 那么，为什么不好好利用这个备份密钥呢？ ;)(假设我们已经拿到域管理权限或同等权限) :

语法是 lsadump::backupkeys /system:<DOMAIN CONTROLLER> /export。 这个.pvk 私钥可以用来解密任何域用户主密钥，而且这个备份密钥不会改变！

而且，这在 Mimikatz的实现已经有一段时间了！

因此，让我们下载 harmj0y 的 主密钥文件(b8854128-023c-433d-aac9-232b4bca414c)和 Chrome cookies 数据库，以及 .pvk私钥。

旁注: 备份密钥检索

虽然 MS-BKRP 看起来确实支持基于 RPC 的备份密钥的远程检索(参见3.1.4.1.3 BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID 章节) ，而 Mimikatz 确实实现了这个 RPC 调用，但 lsadump::backupkeys 方法使用 LsaOpenPolicy/LsaRetrievePrivateData API 调用(而不是 MS-BKRP)来检索 G$BCKUPKEY_PREFERRED LSA 密钥的值

我想更好地理解这个逻辑，所以我将 Benjamin 的远程备份密钥检索逻辑移植到 C# 中。项目(SharpDPAPI)在 GhostPack存储库中。 默认情况下，DPAPI 备份密钥将从当前的域控制器文件中检索，并以 base64字符串的形式输出，但是这种行为可以修改:

一旦获取了用户的主密钥或域备份密钥，就不必在目标主机上执行解密命令。 你可以下载任何找到的用户主密钥文件(参见本文后面的 Seatbelt 部分) ，然后锁定 DPAPI 容器(比如 Cookies) ，或者 a)使用域备份密钥来解密用户的主密钥(然后用它来解密你的目标数据块) 或者 b)如果你从内存中提取了主密钥，你可以直接使用它。

因此，让我们使用 Mimikatz 通过使用域备份密钥来解密 harmj0y 的主密钥，然后使用该主密钥来解密 Chrome cookies 数据库:

· mimikatz # dpapi::masterkey /in:b8854128–023c-433d-aac9–232b4bca414c /pvk:ntds_capi_0_32d021e7-ab1c-4877-af06–80473ca3e4d8.pvk

· mimikatz # dpapi::chrome /in:Cookies /masterkey:f35cfc2b44aedd7… 

如果我们保存这个.pvk 密钥，我们就可以根据需要下载 主密钥 /DPAPI 数据块并离线解密！