Extracting PEAP Credentials from Wired Network Profiles

渗透技巧 2个月前 admin

16 0 0

A colleague of mine recently found himself in a situation where he had physical access to a Windows machine connected to a wired network using 802.1X and saved user credentials for the authentication. Naturally, he wanted to extract those credentials. Nothing extraordinary about that you might think, and yet, there was a twist…
我的一位同事最近发现自己可以物理访问使用 802.1X 连接到有线网络的 Windows 计算机，并保存用于身份验证的用户凭据。自然，他想提取这些凭证。你可能会认为这没什么特别的，然而，事情却出现了转折……

Where to start? 从哪儿开始？

For this blog post, I will assume the reader is already familiar with basic Windows credential extraction techniques and 802.1X network authentication concepts because I want to keep it short (for once).
对于这篇博文，我假设读者已经熟悉基本的 Windows 凭据提取技术和 802.1X 网络身份验证概念，因为我想保持简短（仅此一次）。

If you search for how to extract Protected Extensible Authentication Protocol (PEAP) credentials on Windows, you will find numerous results about wireless networks, but nothing (?) about wired networks. This makes sense because when it comes to Network Access Control (NAC) on wired networks, common implementations rely on certificate-based authentication (e.g. EAP-TLS) or third-party software and appliances.
如果您搜索如何在 Windows 上提取受保护的可扩展身份验证协议 (PEAP) 凭据，您会发现大量有关无线网络的结果，但没有（？）有关有线网络的结果。这是有道理的，因为当涉及有线网络上的网络访问控制 (NAC) 时，常见的实现依赖于基于证书的身份验证（例如 EAP-TLS）或第三方软件和设备。

The one thing we can learn about PEAP for wireless networks though, is that credentials are saved encrypted using the Data Protection API (DPAPI). It’s a very basic piece of information, but at least we know what to expect.
不过，关于无线网络 PEAP，我们可以了解到的一件事是，凭证是使用数据保护 API (DPAPI) 加密保存的。这是一个非常基本的信息，但至少我们知道会发生什么。

So, first things first, how do we set up 802.1X PEAP authentication on a wired interface? Well, that’s simple, we open the “Windows Settings” app, click on “Network & Internet”, go to the “Ethernet” section, click on the link “Change adapter options”, and… we are presented with the “Network Connections” view of the legacy Control Panel.
那么，首先，我们如何在有线接口上设置 802.1X PEAP 身份验证？嗯，很简单，我们打开“Windows 设置”应用程序，单击“网络和 Internet”，转到“以太网”部分，单击链接“更改适配器选项”，然后…我们会看到“网络连接” ” 旧控制面板的视图。

Network connection settings
网络连接设置

The procedure is slightly different on Windows 11 since the control panel UI was completely revamped, but the overall idea remains the same.
由于控制面板 UI 已完全修改，因此 Windows 11 上的过程略有不同，但总体思路保持不变。

From there, we can select an Ethernet interface, right-click on it to open the contextual menu, click “Properties” and go to the “Authentication” tab…
从那里，我们可以选择一个以太网接口，右键单击它打开上下文菜单，单击“属性”并转到“身份验证”选项卡…

Ethernet interface properties
以太网接口属性

But there is no “Authentication” tab! Oh wait, we need to start the “Wired AutoConfig” service, a.k.a. dot3svc! After doing that, the “Authentication” tab becomes visible in the Properties.
但没有“身份验证”选项卡！哦等等，我们需要启动“Wired AutoConfig”服务，又名 dot3svc ！完成此操作后，“身份验证”选项卡将在属性中可见。

Authentication tab visible in the interface’s properties
界面属性中可见的身份验证选项卡

Finally, we can click on “Advanced Settings…”, tick the box “Specify authentication mode”, select “User authentication” in the drop-down list, click on “Save credentials”, and enter our credentials.
最后，我们可以单击“高级设置…”，勾选“指定身份验证模式”框，在下拉列表中选择“用户身份验证”，单击“保存凭据”，然后输入我们的凭据。

Saving PEAP user credentials
保存 PEAP 用户凭据

For the sake of this blog post, I chose easily identifiable values: ThisIsMyUsername and ThisIsMyPassword. The setup is now ready, we may start our investigation.
为了这篇博文，我选择了易于识别的值： ThisIsMyUsername 和 ThisIsMyPassword 。设置现已准备就绪，我们可以开始调查。

Where my credentials at? 我的凭证在哪里？

The plan is very simple. Assuming that the credentials are stored somewhere on the file system or in the registry, the idea is to use Process Monitor to find operations such as CreateFile, WriteFile, or RegSetValue.
计划非常简单。假设凭据存储在文件系统或注册表中的某个位置，我们的想法是使用进程监视器来查找诸如 CreateFile 、 WriteFile 或 RegSetValue

I used highlight rules rather than filters because I wanted to see the big picture before focusing on more specific events.
我使用突出显示规则而不是过滤器，因为我想在关注更具体的事件之前先了解全局。

An interesting RegSetValue operation
一个有趣的 RegSetValue 操作

Within a matter of seconds, thousands of events were captured. While patiently scrolling through them I noticed a very interesting chain of events. The lsass.exe process opens the Preferred file of the LocalSystem account, which hints towards the use of DPAPI, followed by a RegSetValue operation from another service (svchost.exe process).
几秒钟之内，数千个事件被捕获。当我耐心地浏览它们时，我注意到一系列非常有趣的事件。 lsass.exe 进程打开 LocalSystem 帐户的 Preferred 文件，该文件暗示使用 DPAPI，然后执行 RegSetValue 操作另一个服务（ svchost.exe 进程）。

Call stack of a server-side CryptProtectData API call
服务器端 CryptProtectData API 调用的调用堆栈

The RPC procedure s_SSCryptProtectData is the server-side function corresponding to the client-side CryptProtectData API. And because the Preferred file of the LocalSystem account is accessed, we know which master key is used.
RPC过程 s_SSCryptProtectData 是与客户端 CryptProtectData API相对应的服务器端函数。并且由于访问了 LocalSystem 帐户的 Preferred 文件，因此我们知道使用了哪个主密钥。

The screenshot below shows some details about the RegSetValue operation. A binary blob is written to a value with the name Wired in the registry key HKLM\SOFTWARE\Microsoft\dot3svc\Interfaces\{215B523B-D0D3-42AB-BF7E-C143108E2422}\UserData\Profiles\{9A2E6B93-5356-49B7-A0E1-67B8CE8AEBBE}. This operation originates from the service dot3svc (information not shown on the screenshots), the one we had to start earlier to be able to configure PEAP in the first place.
下面的屏幕截图显示了有关 RegSetValue 操作的一些详细信息。二进制 blob 被写入注册表项 HKLM\SOFTWARE\Microsoft\dot3svc\Interfaces\{215B523B-D0D3-42AB-BF7E-C143108E2422}\UserData\Profiles\{9A2E6B93-5356-49B7-A0E1-67B8CE8AEBBE} 中名为 Wired 的值。此操作源自服务 dot3svc （屏幕截图中未显示信息），我们必须早点启动该服务才能首先配置 PEAP。

A binary blob being saved in the registry
保存在注册表中的二进制 blob

Unsurprisingly, the binary data starts with 01 00 00 00 D0 8C ..., which definitely looks like a DPAPI blob!
不出所料，二进制数据以 01 00 00 00 D0 8C ... 开头，它看起来绝对像一个 DPAPI blob！

Time for decryption 解密时间

A quick look at the registry confirms that a new “User Data Profile” was attached to our network interface in the form of a registry key with a random GUID, and that a binary value named Wired was added to this profile.
快速查看注册表可以确认，一个新的“用户数据配置文件”以带有随机 GUID 的注册表项的形式附加到我们的网络接口，并且一个名为 Wired 的二进制值已添加到此配置文件中。轮廓。

Example of a “Wired” data blob
“有线”数据 blob 的示例

We can extract the raw data and save it to a file using the following commands in PowerShell.
我们可以在 PowerShell 中使用以下命令提取原始数据并将其保存到文件中。

1
2
3

$RegPath = "HKLM\SOFTWARE\Microsoft\dot3svc\Interfaces\{215B523B-D0D3-42AB-BF7E-C143108E2422}\UserData\Profiles\{9A2E6B93-5356-49B7-A0E1-67B8CE8AEBBE}"
$Blob = Get-ItemPropertyValue -Path "Registry::$RegPath" -Name "Wired"
[IO.File]::WriteAllBytes("C:\Temp\wired.bin", $Blob)

By feeding the output file into mimikatz, we can confirm that the data is indeed a DPAPI blob. The tool also shows the ID of the associated master key: 48c77ef6-4aa9-4da5-b850-b545e4b86de6.
通过将输出文件输入 mimikatz，我们可以确认数据确实是 DPAPI blob。该工具还显示关联主密钥的 ID： 48c77ef6-4aa9-4da5-b850-b545e4b86de6 。

1	dpapi::blob /in:c:\temp\wired.bin /raw

DPAPI blob parsed by Mimikatz
Mimikatz 解析的 DPAPI blob

Note that we could also have obtained this information by reading the content of the Preferred file because it contains the GUID of the master key currently in use. In a real-world scenario though, it could have been an older key, so it’s still more reliable to get this information from the blob itself.
请注意，我们还可以通过读取 Preferred 文件的内容来获取此信息，因为它包含当前使用的主密钥的 GUID。但在现实场景中，它可能是旧密钥，因此从 blob 本身获取此信息仍然更可靠。

DPAPI master key ID extracted from the “Preferred” file
从“Preferred”文件中提取的 DPAPI 主密钥 ID

One way to get the value of the master key is to use the mimikatz command sekurlsa::dpapi. Note that it requires to have access to the LSASS process (with debug privileges for instance).
获取主密钥值的一种方法是使用 mimikatz 命令 sekurlsa::dpapi 。请注意，它需要有权访问 LSASS 进程（例如具有调试权限）。

DPAPI master key obtained with Mimikatz
使用 Mimikatz 获得的 DPAPI 主密钥

We are almost there. To get the clear text data, we just need to add the command line parameters /unprotect and /masterkey:KEY to our previous dpapi::blob command, and…
我们就快到了。要获取明文数据，我们只需将命令行参数 /unprotect 和 /masterkey:KEY 添加到之前的 dpapi::blob 命令中，然后…

1	dpapi::blob /in:c:\temp\wired.bin /raw /unprotect /masterkey:73b724580d0abfd9ebb62c462151334ced52fb75203dace1f8ab631326b75c3a297246e577362dfba88bb3ae5561fa091e1d9b02c450d859a19fed66e397d9f5

Mimikatz failing to decrypt the DPAPI blob
Mimikatz 未能解密 DPAPI blob

… we get the error code 0x80090005, i.e. NTE_BAD_DATA.
…我们得到错误代码 0x80090005 ，即 NTE_BAD_DATA 。

According to the documentation of CryptDecrypt, this error is returned when “the data to be decrypted is not valid” or “when the padding is found to be not valid”.
根据 CryptDecrypt 的文档，当“要解密的数据无效”或“当发现填充无效时”会返回此错误。

At this point, I tried to fiddle with the input data, I also double-checked the blob data using a hexadecimal editor, and verified the master key, but I couldn’t figure out what was wrong with the decryption.
此时，我尝试摆弄输入数据，还使用十六进制编辑器仔细检查了 blob 数据，并验证了主密钥，但我无法弄清楚解密出了什么问题。

A step back 退一步

I was pretty sure there was not much I could do about the input data (i.e. the data blob and the master key), so I came to the conclusion that there was something else involved in the decryption process. I took a step back, and got a closer look at the event leading to the RegSetValue operation to see if I had missed something.
我非常确定我对输入数据（即数据 blob 和主密钥）无能为力，因此我得出的结论是解密过程中还涉及其他内容。我后退了一步，仔细查看了导致 RegSetValue 操作的事件，看看我是否错过了某些内容。

Call stack leading to “RegSetValueW”
导致“RegSetValueW”的调用堆栈

According to this call stack, the RPC procedure RpcSetProfileEapUserData is invoked. This leads to the internal function StSaveUserData being called, and the DPAPI blob being written to the registry using the API RegSetValueExW, as we saw earlier.
根据这个调用堆栈，调用RPC过程 RpcSetProfileEapUserData 。这会导致调用内部函数 StSaveUserData ，并使用 API RegSetValueExW 将 DPAPI blob 写入注册表，如我们之前所见。

With a quick look at dot3svc.dll in Ghidra, it’s easy to reconstruct the following part of the StSaveUserData function’s source code.
快速浏览一下 Ghidra 中的 dot3svc.dll ，就可以轻松重构 StSaveUserData 函数源代码的以下部分。

// ...
status = RegCreateKeyExW(hKey, lpSubKey, 0, NULL, 0, KEY_WRITE, NULL, &hNewKey, NULL);
if (status == 0) {
  bSuccess = CryptProtectData(
              &DataIn,    // pointer to DATA_BLOB: encrypted data
              NULL,       // optional description
              &blobSalt,  // pointer to DATA_BLOB: optional entropy
              NULL,       // reserved
              NULL,       // optional
              CRYPTPROTECT_UI_FORBIDDEN, // flags
              &DataOut    // pointer to DATA_BLOB: decrypted data
            );
  if (bSuccess) {
    status = RegSetValueExW(hNewKey, lpValueName, 0, REG_BINARY, DataOut.pbData, DataOut.cbData);
  }
}
// ...

And here is the interesting part, the third (optional) parameter is used to pass a reference to a global variable named blobSalt. Note that I did not name this variable, the name blobSalt was provided in the public symbol file linked to dot3svc.dll.
这是有趣的部分，第三个（可选）参数用于传递对名为 blobSalt 的全局变量的引用。请注意，我没有命名该变量，名称 blobSalt 是在链接到 dot3svc.dll 的公共符号文件中提供的。

According to the documentation of CryptProtectData, this parameter is “a pointer to a DATA_BLOB structure that contains a password or other additional entropy used to encrypt the data”. Additionally, “The DATA_BLOB structure used in the encryption phase must also be used in the decryption phase”.
根据 CryptProtectData 的文档，该参数是“指向 DATA_BLOB 结构的指针，该结构包含密码或用于加密数据的其他附加熵”。此外，“加密阶段使用的 DATA_BLOB 结构也必须用于解密阶段”。

A DATA_BLOB structure is defined as follows. It contains a pointer to a buffer, and the buffer’s size.
DATA_BLOB 结构定义如下。它包含指向缓冲区的指针以及缓冲区的大小。

typedef struct _CRYPTOAPI_BLOB {
  DWORD cbData;
  BYTE  *pbData;
} CRYPT_INTEGER_BLOB, /* ... */, DATA_BLOB, /* ... */ *PCRYPT_ATTR_BLOB;

_CRYPTOAPI_BLOB is the base name of the structure, DATA_BLOB is just one of its many aliases (see the documentation of CRYPT_INTEGER_BLOB).
_CRYPTOAPI_BLOB 是结构的基本名称， DATA_BLOB 只是其众多别名之一（请参阅 CRYPT_INTEGER_BLOB 的文档）。

In my version of the DLL (10.0.19041.3636), the global variable blobSalt is located at address 0x1800400c0, in the writable .data section. The data type was initially set to _CRYPTOAPI_BLOB by Ghidra’s PDB analyzer, but this structure is not defined, so I set the data type to DATA_BLOB instead.
在我的 DLL 版本 ( 10.0.19041.3636 ) 中，全局变量 blobSalt 位于可写 .data 部分中的地址 0x1800400c0 处。 Ghidra 的 PDB 分析器最初将数据类型设置为 _CRYPTOAPI_BLOB ，但未定义此结构，因此我将数据类型设置为 DATA_BLOB 。

Content of “blobSalt” “blobSalt”的内容

I would have expected the structure to be all zeroes, and populated during the initialization of the service, but instead, I found that the buffer address is set to 0x1800377e0, which is within the readonly .rdata section. In other words, it looks like the entropy / salt value is just hardcoded!
我本希望该结构全部为零，并在服务初始化期间填充，但相反，我发现缓冲区地址设置为 0x1800377e0 ，位于只读 .rdata

Value of “blobSalt” “blobSalt”的价值

And it is! In the end, our credentials are just encrypted using the master key of the LocalSystem account and a salt. Thankfully, mimikatz has a command parameter through which we can pass this optional value.
确实如此！最后，我们的凭据只是使用 LocalSystem 帐户的主密钥和盐进行加密。值得庆幸的是，mimikatz 有一个命令参数，我们可以通过它传递这个可选值。

dpapi::blob /in:c:\temp\wired.bin /raw /unprotect /masterkey:73b724580d0abfd9ebb62c462151334ced52fb75203dace1f8ab631326b75c3a297246e577362dfba88bb3ae5561fa091e1d9b02c450d859a19fed66e397d9f5 /entropy:6eafe55eabc3495c9808c61ee123342f /out:c:\temp\wired_decrypted.bin

DPAPI blob decrypted with Mimikatz
使用 Mimikatz 解密 DPAPI blob

This time, the decryption is successful, and we can read the output file to get our cleartext credentials!
这次，解密成功了，我们可以读取输出文件来获取我们的明文凭证！

Cleartext credentials extracted from the output binary file
从输出二进制文件中提取的明文凭据

Now, you might be wondering whether this value is the same in all versions of the DLL. Well, I cannot say for sure, but I checked a couple of them, and it was, so it’s most probably the case.
现在，您可能想知道该值在 DLL 的所有版本中是否都相同。好吧，我不能肯定地说，但我检查了其中几个，确实如此，所以很可能是这样。

A stealthier approach 更隐蔽的方法

Mimikatz is a great tool, but it can be a pain to get it running on a target machine, especially nowadays, with all those EDR / XDR protections. I have some packers of my own that could do the job, but we would simply be better off not having to run anything directly on the target. For that purpose, I devised a procedure for decrypting the data using only impacket scripts offline.
Mimikatz 是一个很棒的工具，但让它在目标机器上运行可能会很痛苦，尤其是现在，具有所有这些 EDR / XDR 保护。我自己有一些打包程序可以完成这项工作，但我们最好不要直接在目标上运行任何东西。为此，我设计了一个仅使用 impacket 脚本离线解密数据的过程。

First things first, we can reuse the initial PowerShell commands to dump the DPAPI blob to a file.
首先，我们可以重用初始 PowerShell 命令将 DPAPI blob 转储到文件中。

1
2
3

$RegPath = "HKLM\SOFTWARE\Microsoft\dot3svc\Interfaces\{215B523B-D0D3-42AB-BF7E-C143108E2422}\UserData\Profiles\{9A2E6B93-5356-49B7-A0E1-67B8CE8AEBBE}"
$Blob = Get-ItemPropertyValue -Path "Registry::$RegPath" -Name "Wired"
[IO.File]::WriteAllBytes("C:\Temp\wired.bin", $Blob)

Alternatively, if we have network access to the target, we can use the following commands to query the registry recursively, and dump the value we are interested in.
或者，如果我们可以通过网络访问目标，我们可以使用以下命令递归查询注册表，并转储我们感兴趣的值。

# 1. Get the network interface and profile IDs
export KEY_BASE="HKLM\SOFTWARE\\Microsoft\\dot3svc\\Interfaces"
impacket-reg 'USER:PASS@TARGET' query -keyName "${KEY_BASE}" -s
# 2. Get the content of the 'Wired' value
export INTERFACE_GUID="{INTERFACE_GUID_HERE}" # {215B523B-D0D3-42AB-BF7E-C143108E2422}
export PROFILE_GUID="{PROFILE_GUID_HERE}"     # {9A2E6B93-5356-49B7-A0E1-67B8CE8AEBBE}
impacket-reg 'USER:PASS@TARGET' query -keyName "${KEY_BASE}\\${INTERFACE_GUID}\\UserData\\Profiles\\${PROFILE_GUID}" -v "Wired"

Assuming we have a file named wired.bin containing the DPAPI blob, we can then feed it into the dpapi.py script to get the ID of the master key.
假设我们有一个名为 wired.bin 的文件，其中包含 DPAPI blob，那么我们可以将其输入到 dpapi.py 脚本中以获取主密钥的 ID。

1	impacket-dpapi unprotect -file "wired.bin"

Master key ID obtained using “dpapi.py”
使用“dpapi.py”获取的主密钥ID

With this information, we know which master key file we need to retrieve from the target machine.
有了这些信息，我们就知道需要从目标计算机检索哪个主密钥文件。

Here, I create a temporary copy of the file and use the built-in tool attrib.exe to remove the “hidden” file attribute, but this step is not strictly necessary.
在这里，我创建了文件的临时副本，并使用内置工具 attrib.exe 删除“隐藏”文件属性，但这一步并不是绝对必要的。

1 2	cp "C:\windows\System32\Microsoft\Protect\S-1-5-18\User\48C77EF6-4AA9-4DA5-B850-B545E4B86DE6" "c:\temp" attrib.exe /s /h /r /d "C:\temp\48C77EF6-4AA9-4DA5-B850-B545E4B86DE6"

The master key is protected with the DPAPI user key of the LocalSystem account. If you have a copy of the SYSTEM and SECURITY hives, you can extract it as follows. Otherwise, you can use secretsdump.py to dump it remotely as well.
主密钥受 LocalSystem 帐户的 DPAPI 用户密钥保护。如果您有 SYSTEM 和 SECURITY 配置单元的副本，则可以按如下方式提取它。否则，您也可以使用 secretsdump.py 远程转储它。

# Locally
impacket-secretsdump -system "system.bin" -security "security.bin" LOCAL
# Remotely
impacket-secretsdump 'USER:PASS@TARGET'

Decrypting the DPAPI user key of the “LocalSystem” account
解密“LocalSystem”帐户的DPAPI用户密钥

Thanks to the DPAPI user key, we can then decrypt the master key file, and thereby extract the key that protects our DPAPI blob.
借助 DPAPI 用户密钥，我们可以解密主密钥文件，从而提取保护 DPAPI blob 的密钥。

1	impacket-dpapi masterkey -file "48C77EF6-4AA9-4DA5-B850-B545E4B86DE6" -key "0xc99eb525bc17b9da543b4851290dff4066502f39"

Decrypting the master key file with “dpapi.py”
使用“dpapi.py”解密主密钥文件

And finally, we can provide the DPAPI blob, the encryption key and the entropy file to dpapi.py to decrypt the DPAPI blob and extract the saved credentials.
最后，我们可以向 dpapi.py 提供 DPAPI blob、加密密钥和熵文件，以解密 DPAPI blob 并提取保存的凭据。

1
2

echo "6eafe55eabc3495c9808c61ee123342f" | xxd -r -p > entropy.bin
impacket-dpapi unprotect -file "wired.bin" -key "0x73b724580d0abfd9ebb62c462151334ced52fb75203dace1f8ab631326b75c3a297246e577362dfba88bb3ae5561fa091e1d9b02c450d859a19fed66e397d9f5" -entropy-file "entropy.bin"

Decrypting the DPAPI blob with “dpapi.py”
使用“dpapi.py”解密 DPAPI blob

Conclusion 结论

It was a fun ride, and most importantly, a good opportunity to play around with DPAPI. Hopefully, this post will help anyone who finds themselves in a similar situation.
这是一次有趣的旅程，最重要的是，这是一个使用 DPAPI 的好机会。希望这篇文章能够帮助任何遇到类似情况的人。

One question remains though, why on earth would you use a hardcoded salt / entropy value? I’m no crypto expert, but I can reasonably say that I have a basic understanding of crypto concepts, and to me, this doesn’t make sense. It looks like it serves just as an obfuscation trick.
但仍然存在一个问题，为什么要使用硬编码的盐/熵值？我不是加密专家，但我可以合理地说我对加密概念有基本的了解，对我来说，这是没有意义的。看起来它只是一种混淆技巧。