红队的 Active Directory 枚举

目录服务是许多组织的核心和灵魂，无论是 Active Directory、OpenLDAP 还是其他更奇特的东西，作为大量知识的来源，它通常充当红队行动期间内部侦察和其他攻击的渠道。

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

因此，这对希望利用此知识库进行侦察或特权升级攻击的红队来说是一个挑战。如果只是运行 BloodHound、StandIn、SharpView 等自动化工具，而没有深入了解它们在后台执行的操作，您可能会盲目地穿越潜在的检测点雷区。

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

监控 LDAP 活动

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

端点遥测

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

对于通过 API 级别挂钩获得的遥测数据，其内容当然取决于使用此方法的产品，并且几乎总是可以通过解除相关用户模式 DLL 的挂钩来轻松规避。因此，我们不会进一步详细介绍此遥测数据。

就 ETW 提供商而言Microsoft-Windows-LDAP-Client，我们可以订阅此遥测数据，以使用 SilkETW 等工具进一步了解 EDR 可能看到的内容：

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

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

正如我们上面提到的，查看从 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 是否能够捕获此遥测数据，我们可以从信标进程（应用了 ETW 钩子）和命令行重复相同的 LDAP 搜索：

行搜索查询后，我们注意到，我们仅收到未应用 ETW 挂钩的进程的遥测数据，这证实了我们的理解，即 MDE 正在使用Microsoft-Windows-LDAP-ClientETW 提供程序来捕获其 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) 的捕获：

接下来，我们需要修改昂贵且高效的查询的日志记录，以使满足阈值的标准足够低，以便我们能够捕获日志事件。为此，通过将值设置为 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 将在事件表中捕获通过域控制器传递的 LDAP 遥测数据（大多数情况下）IdentityQueryEvents。我们可以使用高级搜索功能查询此表以查看此遥测数据，如下所示：

let timeframe = 24h;IdentityQueryEvents| where ingestion_time() >= ago(timeframe)| where ActionType =~ "LDAP 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 是一款出色的工具，可用于离线和在线分析 Active Directory，已成为红队武器库中的有用武器。ADExplorer 快照对红队特别有用，因为可以使用c3c的ADExplorerSnapshot等工具将其转换为 BloodHound 。

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

您可能已经注意到，表中没有执行的IdentityQueryEventsLDAP 查询的结果ADExplorer；这可能看起来有点奇怪，我们当然同意，但这些查询似乎没有由 MDI 存储。

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

这些查询都相对简单；但是，至少从我们的评估来看，在本质上似乎有些罕见；因此，假设有足够的 ETW 遥测数据，(objectGUID=*)它可以提供一个有用的检测点来识别的使用。ADExplorer

锐视

考虑到以上情况，您可能会认为更有针对性的自定义查询是实现自动枚举的更好方法，当然，您是对的。一些红队中流行的工具是 SharpView，它可以包装一些更有针对性的查询。

举例来说，您可以利用该Get-DomainGroupMember命令来恢复给定组的组成员：

这些查询将记录在 MDI 的IdentityQueryEvents表中，但没有明确发出内置警报。但是，正如我的同事@rbmaslen 指出的那样，我们可以基于PCRE.net库的使用为 SharpView 的使用创建高保真警报，该库会将 DLL 放入磁盘中的固定位置%TEMP%。

构建 MDE 搜索规则使我们能够根据文件创建事件轻松地为 SharpView 创建自定义检测ba9ea7344a4a5f591d6e5dc32a13494b.dll；搜索可能类似于以下内容：

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

访问目录

希望基于我们迄今为止所研究的各种检测点，可以推断出，当访问目录时，我们应该优先选择自定义的、有针对性的查询，而不是自动的、范围过广的目录数据检索。

直接访问目录时，除了选择 LDAPS 等加密传输（我们假设这是给定的，因此在这里忽略）之外，我们还应该记住两件事，以限制我们提取的数据量，从而避免过大的 LDAP 数据提取：搜索基础和搜索范围。

您可以将 LDAP 视为具有层次结构，就像一棵树。此结构由各种条目组成，每个条目代表用户、组或组织单位等对象。每个条目都由唯一的专有名称 (DN) 标识。搜索基础确定目录中开始搜索条目的起点。

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

• 基础：仅搜索定义为搜索基础的条目；

• 一个级别：搜索搜索库直接下的所有条目，但不包括搜索库本身；

• 子树：搜索基本条目及其下的所有条目，遍历整个子树。

虽然在 MDSec 我们几乎只使用我们自己的内部 LDAP 工具，但也有一些公共工具允许您执行自定义 LDAP 查询，我将简要介绍其中三种我认为最受欢迎的工具：前 @MDSecLabs'er Tom Carver 的 ADSearch、FuzzySec 的 StandIn 和 TrustedSec 的 ldapsearch BOF。

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

对于 ADSearch 来说，用作搜索基础的可分辨名称是从此处的当前域名派生而来的：

DirectoryEntry而在 StandIn 中，它使用根域的默认上下文进行自定义查询：

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

事实上，ldapsearchBOF 是我能明确识别出的唯一一款试图支持此功能的公共工具。但是，据我所知，如果传递了搜索范围，该工具在解析参数时会出现错误。这一点，再加上其他工具中没有此功能，意味着这可能是一些人忽视的一个技术领域。还值得注意的是，此工具似乎不支持 LDAPS，因此从 OpSec 的角度来看，这是需要注意的一点。

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

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

了解了如何以及在何处执行 LDAP 后利用的方法后，让我们更深入地研究查询它的技术。

希望基于我们迄今为止所研究的一些内容，我们能够更好地了解我们可能想要避免的潜在检测陷阱；重申一些常见的陷阱可能包括：

• 范围过大的通配符查询；

• 接触敏感主体；

• 针对技术或工具的特定查询或过滤器的签名；

• 在短时间窗口内检索的数据量或大小。

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

我通常使用一种我称之为“OU 遍历”的技术来开始目录侦察；本质上，这涉及慢慢地绘制目录中的组织单元。假设目录结构整齐，这有望提供足够的信息来识别感兴趣的对象可能位于何处。

假设我们的域根目录如下所示，包含一些组织单元：

我们可以使用一个简单的查询来提取 OU 列表，例如，“ou>=’’”,该查询从域根开始且不进行递归，返回具有非空 OU 属性的所有对象的可分辨名称：

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

如果我们的 LDAP 探索的目的是识别可能有趣的账户以进行跟踪，我们可能需要调查 OU Accounts，然后反复进行此过程，直到找到一个我们可能想要完全探索其内部对象的 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 服务 (ADWS)

2021 年 10 月，我们为一家 Active Directory 欺骗供应商进行了产品评估。在评估过程中，我们意识到 RSAT 的 Active Directory 模块不受蜜罐数据的影响。调查此事让我们走上了 Active Directory Web 服务的道路，我们很快意识到这可能会给红队活动带来潜在的额外好处。在取得一些成功后，我们决定当时公开记录这种技术不符合我们的利益。然而，在 FalconForce 发布了他们对SOAPHound的研究后，我们决定深入研究我们的保险库并重新激活它。

使用 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 搜索客户端并非易事；然而，以下资源对我们很有用。

在执行 ADWS 后利用时，我们发现 MDE 或 MDI 中存储的有关正在执行的操作的遥测数据很少。例如，执行如下有针对性的 ADWS 查询，导致遥测中几乎看不到任何内容：

事实上，我们发现唯一能够准确检测出 ADWS 后漏洞利用的方法就是通过对网络事件进行基准测试。MDEDeviceNetworkEvents中的表格提供了有关进程连接的详细信息；使用如下搜索将有助于识别连接到 ADWS 的进程：

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

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

Active Directory Enumeration for Red Teamshttps://www.mdsec.co.uk/2024/02/active-directory-enumeration-for-red-teams/