面向红队的 Active Directory 枚举

Active Directory Enumeration for Red Teams

目录服务是许多组织的核心和灵魂，无论是 Active Directory、OpenLDAP 还是其他更特殊的服务，作为大量信息的来源，它在红队行动期间经常成为内部侦察和其他攻击的渠道。

考虑到这一点，蓝队通常会投入大量资源来保护和监控目录访问，无论是通过蜜罐令牌、LDAP 查询分析、遥测异常检测，还是其他类似的防御策略。

因此，这给希望利用这个知识库进行侦察或权限提升攻击的红队带来了挑战。如果不深入了解 BloodHound、StandIn、SharpView 等自动化工具在底层的工作原理就盲目使用，可能会让你在潜在的检测点雷区中毫无方向地摸索。

在本文中，我们将探讨防御者如何监控可疑的 LDAP 活动，以及红队在进行 LDAP 侦察时的操作安全方法。

监控 LDAP 活动

在我们研究 LDAP 技术在行动中可以发挥的作用之前，我们需要了解防御者如何收集我们活动的遥测数据，以及我们的工具可能产生的遥测数据。这使我们能够确定潜在的检测点并制定规避策略。这些遥测数据通常在两个区域收集，即源端（终端）和目标端（目录服务器或域控制器）；在某些情况下可能两者都有。

终端遥测

终端 LDAP 遥测数据通常通过以下两种方法之一来收集：API 级别的钩子（通常针对wldap32.dll）和使用Microsoft-Windows-LDAP-Client提供程序的 Windows 事件跟踪（ETW）。

关于通过 API 级别钩子获取的遥测数据，其内容当然取决于使用这种方法的产品，而且几乎总是可以通过取消相关用户模式 DLL 的钩子来轻易规避。因此，我们不会进一步详细讨论这种遥测数据。

对于Microsoft-Windows-LDAP-Client ETW 提供程序，我们可以订阅这些遥测数据，使用 SilkETW 等工具来深入了解 EDR 可能看到的内容：

SilkETW.exe -t user -pn Microsoft-Windows-LDAP-Client -ot eventlog

在运行 SilkETW 的情况下，让我们使用ADSearch.exe 执行一个带有 SPN 过滤器的基本自定义 LDAP 查询，例如(serviceprincipalname=*)：

如上所示，查看从 SilkETW 获取的Microsoft-Windows-LDAP-Client 提供程序的日志，我们可以看到现在有了一个丰富的数据集，其中详细记录了搜索查询过滤器、受影响的进程等信息。

从红队的角度来看，你可能会开始思考如何利用这种遥测数据来获得优势，特别是在尝试将 Active Directory 攻击技术与典型的进程行为相融合时。例如，即使只监控一个终端很短的时间，我们也能注意到像Excel.exe 这样的进程：

以及taskhostw.exe：

这些进程经常进行 LDAP 查询，可能成为我们执行 LDAP 后渗透的潜在替代进程。做出这样有依据的决策可以帮助红队成员更好地融入背景噪声中。同样，防御者也可以利用这些情报来建立通常与 LDAP 交互的进程基线，并用它来发现环境中的异常情况。

当然，SilkETW 支持 Yara，这意味着防御者可以围绕可能用于潜在攻击技术的 LDAP 过滤器构建检测逻辑，比如特权用户枚举或服务主体扫描。以我们之前的(serviceprincipalname=*) 示例为例，我们可以构建一个简单的 Yara 规则来标记任何执行此 LDAP 查询的进程：

rule spnscan {strings:  $s1 = /serviceprincipalname=\*/condition:  any of ($s*)}

使用启用了 Yara 规则选项重新运行 SilkETW，我们现在可以看到我们的spnscan规则产生了匹配：

这种遥测数据的主要缺点是，通过用户模式 ETW 补丁很容易规避，任何支持此功能的命令与控制框架都能够为在进程中执行的任何后渗透工具禁用它。例如，使用 Nighthawk 重复完全相同的 LDAP 查询，我们可以看到在 SilkETW 捕获中现在没有生成任何事件：

同样的方法也可以应用于通常会消费相同 ETW 遥测数据的 EDR。以 Microsoft Defender for Endpoint (MDE) 为例，我们可以使用类似以下的DeviceEvents表的搜索查询来识别过去一小时内从特定终端执行的任何 LDAP 搜索：

let window = 1h;DeviceEvents| where ingestion_time() >= ago(window)| where ActionType =~ "LdapSearch"| where DeviceName =~ "WS1.zone1.bossbank.local"| extend AdditionalFields=parse_json(AdditionalFields)| extend SearchFilter=tostring(AdditionalFields.SearchFilter)| project-reorder DeviceName, InitiatingProcessCommandLine, SearchFilter

为了了解 MDE 是否能够捕获这种遥测数据，我们可以同时从 beacon 进程（应用了 ETW 钩子）和命令行重复执行相同的 LDAP 搜索：

运行搜索查询时，我们注意到只收到了未应用 ETW 钩子的进程的遥测数据，这证实了我们的理解：MDE 正在使用Microsoft-Windows-LDAP-Client ETW 提供程序来捕获其 LDAP 遥测数据：

如果我们想要扩展搜索范围以查找可疑活动，类似于我们使用 SilkETW Yara 规则的方式，我们可以修改查询以包含对serviceprincipalname=* 过滤器的检测，如下所示：

let window = 1h;let dodgyfilters=dynamic([    "serviceprincipalname=*"]);DeviceEvents| where ingestion_time() >= ago(window)| where ActionType =~ "LdapSearch"| extend AdditionalFields=parse_json(AdditionalFields)|  extend SearchFilter=tostring(AdditionalFields.SearchFilter)| where SearchFilter has_any(dodgyfilters)| project-reorder DeviceName, InitiatingProcessCommandLine, SearchFilter

正如我们所见，当在没有 ETW 钩子的情况下执行 LDAP 查询时，这种方法可以快速识别出来：

目录服务器遥测

默认情况下，由于可能对生产环境造成性能影响，Windows 不会记录 LDAP 事件。当然，有许多第三方身份验证选项可以实现这一点，但让我们首先关注如何通过原生方式实现这一目标。

要启用 LDAP 日志记录，我们需要在域控制器上修改一些注册表设置。首先是HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSDiagnostics15 Field Engineering，将日志级别提高到 5 级，这将启用目录服务事件（ID 1644）的捕获：

接下来，我们需要修改昂贵和[高效查询](https://docs.microsoft.com/en-us/previous-versions/ms808539(v=msdn.10 "高效查询")?redirectedfrom=MSDN#efficientadapps_topic04)的日志记录，使满足阈值的标准足够低，以便我们能够捕获日志事件。为此，通过将以下注册表键的值设置为 1 来降低它们的值，从而有效地移除阈值：

• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParametersExpensive Search Results Threshold
• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParametersInefficient Search Results Threshold

从此时起，所有目录服务事件（ID 1644）都将被记录在域控制器的事件日志中。为了测试这一点，让我们发送一个简单的 LDAP 查询来检索域计算机：

查看域控制器的事件日志，我们现在可以看到 ID 1644 事件（目录服务）正在被捕获：

这种遥测数据当然可以在域控制器端收集，因此在从终端操作时不能轻易规避。然而，它确实让我们充分了解防御者可能从我们的工具中看到什么，进而我们可以利用这些信息来调整我们的技术。

作为替代方案，也许是收集来自域控制器的 LDAP 遥测数据的更实用方法，我们还可以转向第三方身份解决方案，如 Microsoft Defender for Identity (MDI)。

Microsoft Defender for Identity 将在[IdentityQueryEvents](https://learn.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-identityqueryevents-table?view=o365-worldwide "IdentityQueryEvents")事件表中捕获通过域控制器的 LDAP 遥测数据（大部分情况下）。我们可以使用高级搜索功能来查询此表以查看这些遥测数据，如下所示：

let timeframe = 24h;IdentityQueryEvents| where ingestion_time() >= ago(timeframe)| where ActionType =~ "LDAP query"

正如我们所见，Query 字段包含了我们的serviceprincipalname=*过滤器的完整查询详细信息：

如果深入研究这些遥测数据，你还会注意到源进程树未被填充，源信息仅限于主机（据我所知）。稍后会详细讨论这一点。

基于这些遥测数据，我们当然可以创建自定义检测和自定义搜索规则，比如以下这个来自 Defender 门户 MDI 社区查询部分的规则：

这个特定规则将检测到我们之前的 SPN 侦察活动，因为它会对serviceprincipalname=*过滤器触发：

// Detect Active Directory LDAP queries that search for Kerberoasting (SPNs) or accounts with Kerberos preauthentication not required from Azure ATP, and try to get the process initiated the LDAP query from MDATP.// Replace 389 on line 5 with LDAP port in your environment// Replace true on line 6 to false if you want to include Nt Authority process// This LDAP query cover Rubeus, Kerberoast, BloodHound tools// This query was updated from <https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/Microsoft%20365%20Defender/Discovery/Roasting.yaml>let ASREP_ROASTING = "userAccountControl:1.2.840.113556.1.4.803:=4194304";let ASREP_ROASTING1 = "userAccountControl|4194304";let ASREP_ROASTING2 = "userAccountControl&4194304";let KERBEROASTING = "serviceprincipalname=*";let LDAP_PORT = 389;let ExcludeNtAuthorityProcess = true;let AzureAtpLdap = (IdentityQueryEvents| where ActionType == "LDAP query"| parse Query with * "Search Scope: " SearchScope ", Base Object:" BaseObject ", Search Filter: " SearchFilter| where SearchFilter contains ASREP_ROASTING orSearchFilter contains ASREP_ROASTING1 orSearchFilter contains ASREP_ROASTING2 orSearchFilter contains KERBEROASTING| extend Time = bin(Timestamp, 1s)| extend DeviceNameWithoutDomain = tolower(tostring(split(DeviceName, '.')[0])));let MDAtpNetworkToProcess = (DeviceNetworkEvents| extend DeviceNameWithoutDomain = tolower(tostring(split(DeviceName, '.')[0]))| where RemotePort == LDAP_PORT| extend Time = bin(Timestamp, 1s)| extend isExclude = iff( ExcludeNtAuthorityProcess and InitiatingProcessAccountDomain == "nt authority" , true, false));AzureAtpLdap| join kind=leftouter (MDAtpNetworkToProcess ) on DeviceNameWithoutDomain, Time | where isExclude == false or isnull(isExclude)

当然，这可以在 Defender 门户中转化为定期运行的自定义检测规则。

其他可能有效检测攻击性技术的检测点可能包括：

• 通配符查询的检测；
• 敏感主体的枚举；
• 特定查询技术的签名（例如包含"description=pass"的过滤器）；
• 特定时间窗口内 LDAP 查询的数量或大小。

这些留给读者作为练习，但我们建议参考 Azure Sentinel 社区查询以获取更多想法。

现在我们已经有了足够的 LDAP 查询遥测数据源，让我们深入了解这些遥测数据如何影响红队操作。

红队工具分析

既然我们已经掌握了如何从终端和域控制器收集 LDAP 遥测数据的充分细节，让我们来关注这可能如何影响我们使用针对 Active Directory 枚举的攻击工具。

SharpHound

自动化的 Active Directory 枚举当然会产生噪音；因此，即使在其最"隐蔽"的配置下，SharpHound 也会被身份解决方案检测到，这并不令人意外。

使用有限的收集集运行 SharpHound，例如以下命令，至少会在 MDI 中触发安全主体侦察警报：

SharpHound.exe -c DCOnly -d zone1.bossbank.local --stealth --secureldap

当然，并非所有人都会使用 MDI，所以让我们深入了解 SharpHound 在这里做了什么。这不仅有助于我们为其行为建立签名，还能帮助我们理解需要改变什么来规避检测。

检索我们运行 SharpHound 期间进行的 LDAP 查询，我们可以看到以下内容：

深入研究结果，我们可以注意到一些查询，包括以下内容：

LDAP Search Scope: "WholeSubtree", Base Object: "DC=zone1,DC=bossbank,DC=local", Search Filter: " ( | (sAMAccountType=805306369) (objectClass=container) (sAMAccountType=805306368) ( | (sAMAccountType=268435456) (sAMAccountType=268435457) (sAMAccountType=536870912) (sAMAccountType=536870913) ) (objectClass=domain) (objectCategory=CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=bossbank,DC=local) ( & (objectCategory=CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=bossbank,DC=local) (flags=*) ) (primaryGroupID=*) ) "

追溯到 SharpHound 源代码，你会注意到SharpHoundCommon/src/CommonLib/LDAPQueries/LDAPFilter.cs文件中有硬编码的组件：

现在我们已经知道 SharpHound 在做什么以及为什么这样做，我们可以思考一些潜在的方法，不仅可以规避可能依赖这些过滤器的签名，还可以采取替代方法，以更加安全的方式检索相同的信息。我们将此作为读者的练习。

ADExplorer

ADExplorer 是一个优秀的工具，可用于在线和离线分析 Active Directory，已成为红队武器库中的有用工具。ADExplorer 快照对红队特别有用，因为它们可以使用c3c^[1]开发的ADExplorerSnapshot^[2]等工具转换为 BloodHound 格式。

运行ADExplorer来捕获我们域的快照在 Defender 设置中产生了一些有趣的结果；查询IdentityQueryEvents表以了解 MDI 会看到什么，结果如下：

正如你可能注意到的，IdentityQueryEvents表中没有ADExplorer执行的 LDAP 查询的结果；这可能看起来有点奇怪，我们也同意这一点，但这些查询似乎并未被 MDI 存储。

不过，深入研究DeviceEvents表确实为我们提供了更多关于正在发生的事情的信息，我们可以看到ADExplorer执行的一系列查询：

这些查询都相对简单；然而，根据我们的评估，(objectGUID=*)查询似乎相对罕见；因此，假设有足够的 ETW 遥测数据，它可以为识别ADExplorer的使用提供一个有用的检测点。

SharpView

考虑到上述情况，你可能认为更有针对性的自定义查询比自动化枚举更好，当然，你是对的。SharpView 是一些红队中流行的工具，它封装了一些这样的有针对性的查询。

例如，你可以使用Get-DomainGroupMember命令来获取指定组的成员：

这些查询会被记录在 MDI 的IdentityQueryEvents表中，但没有明确触发内置警报。然而，正如我的同事@rbmaslen^[3]指出的^[4]，我们可以基于PCRE.net^[5]库的使用创建一个高保真的 SharpView 警报，该库会在%TEMP%中的固定位置释放一个 DLL。

构建 MDE 搜索规则允许我们基于ba9ea7344a4a5f591d6e5dc32a13494b.dll的文件创建事件轻松创建 SharpView 的自定义检测；搜索可能类似于以下内容：

let window = 1h;DeviceFileEvents| where ingestion_time() >= ago(window)| where DeviceName contains "WS1"| where FolderPath contains "ba9ea7344a4a5f591d6e5dc32a13494b"

红队的战术考虑

在通过攻击技术和常用工具研究了各种检测 Active Directory 枚举的方法后，让我们来看看红队可以采取哪些方法来最小化被检测的机会。

融入环境

正如我们简要提到的，通过对通常执行 LDAP 交互的进程进行基线分析是一种潜在的检测途径。因此，在考虑执行 Active Directory 后渗透时，我们应该考虑使用合适的代理进程来融入环境的可能性。

为了找到潜在的合适代理，让我们利用蓝队的工具来对抗他们，通过构建一个 KQL 查询来查找最近执行过 LDAP 搜索的所有进程：

DeviceEvents| where ActionType =~ "LDAPSearch"| extend AdditionalFields=parse_json(AdditionalFields)| extend SearchFilter=tostring(AdditionalFields.SearchFilter)| project InitiatingProcessFolderPath, InitiatingProcessCommandLine, SearchFilter, InitiatingProcessParentFileName

这给了我们以下进程列表，以及它们的父进程，这些可能是我们 LDAP 技术融入环境的潜在有用候选者：

访问目录

希望基于我们目前看到的各种检测点，在访问目录时，我们应该倾向于使用自定义的、有针对性的查询，而不是自动化的、范围过大的目录数据检索，这是合理的。

在直接访问目录时，除了优先使用 LDAPS 等加密传输（我们假设这是理所当然的，所以在此不再赘述），我们还应该考虑两点来限制我们提取的数据量，从而避免过大的 LDAP 数据拉取：搜索基础和搜索范围。

你可以将 LDAP 视为一个层次结构，就像一棵树。这个结构由各种条目组成，每个条目代表用户、组或组织单位等对象。每个条目都由唯一的可分辨名称（DN）标识。搜索基础决定了从目录中开始搜索条目的起点。

搜索基础与搜索范围相结合，决定了在搜索过程中要考虑哪些条目。范围可以设置为不同的级别，如：

• 基础：仅搜索定义为搜索基础的条目；
• 一级：搜索搜索基础下的所有条目，但不包括基础本身；
• 子树：搜索基础条目及其下的所有条目，遍历整个子树。

虽然在 MDSec，我们几乎完全使用我们自己的内部 LDAP 工具，但有几个公共工具允许你执行自定义 LDAP 查询，我将简要考虑三个我认为最流行的工具：前 MDSecLabs 成员 Tom Carver 的 ADSearch、FuzzySec 的 StandIn 和 TrustedSec 的 ldapsearch BOF。

ADSearch 和 StandIn 都是使用.NET 开发的，使用DirectorySearcher API，该 API 使用DirectoryEntry对象来确定目录的搜索基础，默认情况下将是目录的根。在这两种情况下，这些工具都不允许操作员控制搜索基础或搜索范围。

在 ADSearch 的情况下，用作搜索基础的可分辨名称是从当前域名在此^[6]派生的：

而在 StandIn 中，这使用根域的默认DirectoryEntry上下文进行其自定义查询^[7]：

相反，ldapsearch BOF 确实为操作员提供了对搜索基础（最终作为distinguishedName传递给ExecuteLDAPQuery()）和搜索范围^[8]的控制：

事实上，ldapsearch BOF 是我能明确识别出尝试支持此功能的唯一公共工具。然而，据我所知，如果传递了搜索范围，该工具在解析参数时存在一个 bug。这与其他工具缺乏此功能相结合，意味着这可能是一些人忽视的技术领域。还值得注意的是，这个工具似乎不支持 LDAPS，所以从 OpSec 的角度来看，这是需要注意的。

如果我们想要将此功能引入 ADSearch 和 StandIn，这是一个相对简单的任务。例如，在 ADSearch 的情况下，我们可以简单地添加一个额外的命令行参数来决定是否要递归目录，如果不递归，则对DirectorySearcher对象应用相关范围（即设置为OneLevel）：

此外，为了支持任意搜索基础，我们同样可以简单地为我们的DirectoryEntry对象提供一个用户提供的可分辨名称（distinguishedName）参数：

自定义查询技术

有了关于如何以及从何处执行我们的 LDAP 后渗透的想法，让我们深入研究查询技术。

希望基于我们目前所看到的，我们对可能想要避免的潜在检测陷阱有了更好的理解；重申一些常见的可能包括：

• 范围过大的通配符查询；
• 访问敏感主体；
• 针对特定技术或工具的查询或过滤器的特征；
• 在短时间窗口内检索的数据量或大小。

那么问题就变成了：我们如何尽可能地考虑到这一点来操作？至少我的方法是，尝试通过利用小型、有针对性的查询从目录中检索包含我想要的信息的特定数据集，而不是明确请求该信息。让我们更详细地看看这一点。

我通常使用一种我称之为"OU 遍历"的技术开始我的目录侦察；本质上，这涉及慢慢地映射目录中的组织单位。希望这能提供足够的信息来识别感兴趣的对象可能驻留在哪里，假设目录结构整洁。

让我们想象我们的域根可能如下所示，有几个组织单位：

我们可以使用简单的查询如"ou>=''"从域根提取 OU 列表，该查询返回所有具有非空 OU 属性的对象的可分辨名称，且不递归：

如果任何 OU 看起来可能包含我们正在寻找的信息，我们可以重复相同的操作来查找下一级的任何有趣的 OU。例如，在这里我们可能想要展开Production OU，因为它比其他 OU 更显得潜在有趣：

如果我们的 LDAP 探索目的是识别潜在的有趣账户以进行 roasting，我们可能想要调查Accounts OU，并重复这个过程，直到找到我们可能想要完全探索其内部对象的 OU。当我们找到想要检索内容的 OU 时（在我们的测试 AD 中是OU=Database,OU=Service Accounts,OU=Accounts,OU=Production,DC=zone1,DC=bossbank,DC=local），我们可以使用适当的查询检索容器中的所有对象，避免敏感属性或通配符：

我们明确避免在过滤器中请求可疑属性，如serviceprincipalname，而是检索所有内容，允许我们在客户端解析这些信息。这种方法确实略微增加了我们检索的数据大小（尽管我们可以分页），但通过绑定到特定 OU 并防止递归的组合，这应该是有限的，同时也限制了特征的机会。

如果我们然后尝试在 MDI 内部搜索这个活动，我们会发现没有存储任何事件：

这种方法，结合其他引用的技术，已经为我服务了一段时间，希望为进一步的 LDAP 后渗透提供一个平台。

Active Directory Web Services (ADWS)

2021 年 10 月，我们正在为一个 Active Directory 欺骗供应商进行产品评估。在评估过程中，我们意识到 RSAT 的 Active Directory 模块不受蜜罐数据的影响。调查这一点让我们走上了 Active Directory Web Services 的道路，我们很快认识到这可能为红队行动带来的潜在额外好处。在取得一些成功后，我们决定当时不公开记录这种技术。然而，在 FalconForce 发布了他们关于SOAPHound^[9]的研究后，我们决定重新审视我们的资料库并重振它。

使用 ADWS 进行 LDAP 后渗透的主要好处之一是它相对未知，因此没有人监控其使用。ADWS 运行一个完全不同于 LDAP 的服务，在 TCP 端口 9389 上可用，并使用 SOAP 协议作为其接口。

在调查 ADWS 时，我们注意到，因为它是一个 SOAP Web 服务，实际的 LDAP 查询是在域控制器上执行的。这提供了一些有趣的副作用，结果证明是有利的。首先，在域控制器上分析 LDAP 查询，你可能会注意到查询在日志中来自127.0.0.1：

这在一些操作中成为蓝队发现 LDAP 查询时的困惑原因，在许多情况下导致它们被忽视或忽略。

这的第二个好处是活动不会在DeviceEvents下的LDAPSearch操作类型中显示，这意味着可用的遥测数据很少。

为了开始构建客户端并了解服务暴露的功能，我们可以在 Visual Studio 中添加服务引用：

从新的命名空间，你可以暴露可以调用的各种方法：

使用服务上可用的方法，就可以开始构建 ADWS 功能。例如，要检索组成员资格，我们可以绑定到相关组并调用GetADGroupMember方法，如下所示：

NetTcpBinding tcpBind = new NetTcpBinding();ADWSService.AccountManagementClient acm = new ADWSService.AccountManagementClient(tcpBind, new EndpointAddress("net.tcp://100.64.0.72:9389/ActiveDirectoryWebServices/Windows/AccountManagement"));acm.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;var principal = acm.GetADGroupMember("ldap:389", "CN=Domain Admins,CN=Users,DC=seth,DC=local","DC=seth,DC=local", true);foreach (var attr in principal){    Console.WriteLine(attr.DistinguishedName);    Console.WriteLine(attr.SamAccountName);
}

以域用户身份执行此操作将恢复Domain Admins组的成员：

构建一个功能完整的 ADWS 搜索客户端并不是立即就能完成的简单任务；不过，以下资源^[10]对我们来说很有帮助。

在执行 ADWS 后渗透时，我们发现在 MDE 或 MDI 中存储的操作遥测数据很少。例如，执行如下的定向 ADWS 查询，在遥测数据中几乎看不到任何内容：

事实上，我们发现能够积极检测 ADWS 后渗透存在的唯一方法是通过网络事件基线分析。MDE 中的DeviceNetworkEvents表提供了进程连接的详细信息；使用如下的搜索可以帮助识别正在连接到 ADWS 的进程：

DeviceNetworkEvents| where DeviceName contains "WS1"| where RemotePort == 9389

总的来说，我们发现这种情况在环境中相对罕见，因此它可能提供一个高保真的检测点。

本博客文章由@domchell^[11] 撰写

参考资料