Microsoft系统中心配置管理器(SCCM)。SCCM是微软产品架构下的桌面接口,服务器，移动端管理产品。主要负责桌面标准化,网络批量安装部署软件及操作系统,杀毒策略，资产收集，移动端管理等等。他是资讯科技经理,企业基础设施管理的基本工具。在这篇文章中，我们将解释SCCM如何使用其HTTP API来初始化客户端。我们还将学习如何从SCCM检索网络访问帐户,我们如何解密这些证书,而不使用DPAPI或管理员帐户。
实验室设置
对于我们的实验室设置，我们将使用默认的 SCCM 部署。我发现最简单的方法是通过自动化实验室，它支持通过 ConfigurationManager 角色进行安装：
我们将在这篇文章中使用的版本是 Configuration Manager 2103，我们将把我们的主站点命名为 P01。本实验的服务器将称为 SCCM01，我们将配置为使用 HTTP 进行通信。
一旦SCCM服务器的设置完成，我们将把一切都保留为标准，并添加一个Network Access Account供以后使用：
一旦完成,我们就可以继续探索!
客户端注册
让我们先看看客户试图注册到SCCM时生成的请求。为此,我们使用@_Mayyhem awesome SharpSCCM工具:
当 SharpSCCM 调用实际的 .NET 客户端库时，我们会收到一个清晰的请求，我们可以使用 WireShark 来识别它。客户端向 SCCM 服务器注册的初始步骤如下：
此HTTP请求被发送到SCCM服务器上,由两部分组成，一个是XML编码的头条,另一个是在多部分/混合HTTP请求中发送的XML编码的认证。有趣的是，该协议还使用 CCM_POST HTTP 方法。
标题为UTF-16编码如下:
请求文本是zlib压缩和Unicode编码:
为了简化,我删除了一些较长的16位字符串,但我们在这里看到的是三个向服务器发送的16位字符串,以及一些关于我们的客户端的初始信息。
让我们转储 Signing blob：
如果我们看这个,我们实际上看到这是一个DER编码证书:
在生成此证书时,使用OID添加了两个扩展键:
这些标记证书为文本签字证书(自签字)。
因此，我们看到,客户证书被转移到SCCM服务器,供以后使用,但是SignatureValue字段呢？让我们开始dnSpy并深入研究系统.Configuration Management.Messaging.DLL程序,程序集位于安装的客户端主机上的C:WindowsCCM。
在搜索后,我们进入Interop.Crypt32。 答案在HashAndSignData中找到:
这表明，使用带有PKCSv15填充的RSA- sha256正在使用与证书关联的 RSA 私钥对 XML 请求正文进行签名。
一个奇怪的点是,当签名生成后,这些字符串被逆转,然后被编码为16位ASCII字符串,并添加到请求_(ツ)_/ ̄。
当服务器响应客户端的注册请求时,我们再次看到一个XML头条和一个正则表达式,其中正则表达式数据由zlib压缩。 您可以看到,我们被分配到ClientID,这是我们与服务器之间的通信中使用的 UUID:
在此阶段值得注意的是,此请求可以发送到未验证的SCCM URL http://SCCM01/ccm_system/request。这足够添加一个客户条目到SCCM中,但我们将处于未批准的状态。这 一 状态 将 在 将来 变得 重要 :
政策要求
客户登记后,客户执行的下一阶段是检索策略列表。 这个调用也是使用
不幸的是，这是事情变得有点复杂的地方。我们首先需要关注的是 PublicKey blob。这实际上只是客户端之前为证书生成的 RSA 公钥，但是这次它被编码为 PUBLICKEYBLOB。
接下来是 ClientIDSignature。这是我们之前看到的用于签署 ClientID 的 RSA-SHA256 签名，前面带有 GUID:，然后转换为 Unicode。例如：
最后一个是 PayloadSignature, 即压缩对象的签名.
本请求的主题是zlib压缩和Unicode编码,并提供我们的客户的信息:
对此请求的响应是XML主题中可用的策略列表:
虽然这里有很多有趣的事情,我们现在将集中讨论的领域将是网络访问帐户的共享。
秘密政策
如果您浏览我们正在寻找的策略列表,您将遇到标记“秘密”的策略。 一个策略是NAAConfig,它包括一个网络访问帐户:
你可能已经看到 @gentilkiwi 在 2021 年发布的 Mimikatz 更新中引用了这些帐户，这表明通常这些凭据是在 SCCM 客户端上使用 DPAPI 加密的：
然而,如果我们试图直接使用RequestAssignments请求返回的URL下载这个策略,我们会看到一个错误。
这样做的原因是需要对秘密策略的请求进行身份验证。但是由于这是SCCM，所以还需要进行另一种类型的身份验证。
经过一番搜寻之后，我发现了对 SCCM 服务器上名为 ccmgencert.dll 的 DLL 中使用的身份验证类型的引用：
由于我们知道使用的一些签名方法,这些头条实际上可以很容易创建。 如果你看看已经添加到SCCM平台的客户端,它们看起来是这样:
ClientToken只是我们clienttid和当前DateTime之间的连接。 ClientTokenSignature是一个使用上面相同的RSA-SHA256算法的签名。
让我们把这些标题添加到我们的请求中,看看我们得到的是什么:
这次,我们收到了不同的反应,我是说,我们犯了错误,但我们没有得到任何不良的数据。
事实证明,对于那些真正要求秘密策略的客户来说,他们需要在服务器上得到批准。
默认情况下,SCCM安装包含以下内容:
那么，计算机如何自动识别自己?另一个URL由客户端/ccm_system_windowsauth/request使用。如果先前的XML ClientRegistrationRequest被发送到此路径,并完成NTLMSP核查电脑帐户,客户端设置为核准状态:
现在，当验证此URL时,我们似乎能够使用任意的随机域名用户帐户。然而，问题在于,它似乎不足以迫使客户批准。相反，我们需要使用电脑帐户(虽然它不需要与我们试图登记的客户相符),那么,把电脑加起来吧,这里很有用。
通过将此身份验证步骤添加到我们的注册请求并强制我们的客户端进入 Approved 状态，下次我们请求 NAAConfig 策略时，我们会得到如下所示的内容：
好吧，回到 dnSpy，我们去尝试弄清楚。答案是Interop.found中的DecryptMessageFromCertificateFile方法,该方法显示了CryptDecryptMessage API调用。
参数显示,该加密策略是一个使用3DES CBC的 PKCS7编码块,其密钥源自我们面前的证书中提供的RSA公开密钥。
在解密后,我们终于看到了一些实际证据,如下面所示:
网络访问帐户混淆
起初，获取这些帐户似乎需要更多的加密货币。但是,MimiKatz已经向我们表明,这些证书最终可以访问客户,因此,我们知道我们的客户必须能够在使用DPAPI来保护这些证书之前以某种方式解密这些证书..那么密钥是什么？看看这个加密是如何完成的,我在客户端上找到了一个名为 PolicyAgent.dll 的 DLL。
最重要的是,调试字符串:
UnobfuscateString 听起来很有希望，当然听起来比 DecryptString 更好。我没有深入研究这个反汇编的所有部分，而是创建了一个快速调试工具来调用这个函数。
当运行在一个与SCCM实验室网络无关的主机上并连接到调试器来解决通过此调用方法发生的不可避免的访问冲突时,用户名和密码将被解密:
这意味着使用的加密与描述完全相同,它很混乱!我们有所有需要暗号这些证书的资料,并且我们完全可以进行オフライン!
通过重新创建unobfuscation方法的步骤，我们可以创建如下所示的解密代码。
有了计算机帐户，我们就可以在SCCM 中添加虚假客户端，下载加密的网络访问帐户凭据，并对其进行解密，而无需处理提升权限或任何 DPAPI 解密。
参考和来源: https://blog.xpnsec.com/unobfuscating-network-access-accounts