发现对抗性LDAP Tradecraft

TrustedSec 研究主管Carlos Perez和 Binary Defense 研究主管Jonathan Johnson撰写的文章。最初发布在Binary Defense 页面上。

介绍

虽然发现新的技术手段很重要，但探索成熟且广泛使用的技术也同样重要。Binary Defense 研究团队与TrustedSec研究团队合作，深入研究对抗性轻量级目录访问协议 (LDAP) 技术手段。本博客概述了我们的研究结果，提供了用于公开 LDAP 遥测的工具，并提供了检测恶意 LDAP 活动的指导。

背景

随着 Windows 2000 的推出，微软发布了 Active Directory (AD)，它充当处理 Windows 域单点登录的中央目录，并作为管理解决方案提供组策略。组策略的易用性和配置管理功能巩固了其在所有企业环境中的使用。作为此堆栈的一部分，AD 中使用的一项关键技术是 LDAP，它提供目录信息以查找配置信息、设备、用户和服务。20 多年来，它一直是攻击者在后期利用中的主要枚举目标之一，攻击者希望了解他们的环境并利用它来实现他们的目标。

大多数环境中的 LDAP 服务都在域控制器 (DC) 上运行。主机和主机上的用户从机器启动的那一刻起就利用 LDAP，服务也被利用，主机关闭时事件也会在关闭前更新其信息。

在深入探讨之前，我们想指出一些关于红队如何在交战中使用 LDAP 的现有精彩文章：

• LDAP Queries for Offensive and Defensive Operations by Erica Zelic

https://www.politoinc.com/post/ldap-queries-for-offensive-and-defensive-operations

• ADExplorer on Engagements by Oddvar Moe

https://twitter.com/Oddvarmoe

正常行为

根据您组织中的活动，LDAP 搜索可能非常正常。我们发现在大多数情况下，LDAP 查询将来自 SYSTEM、Network Service 和 Local Service 等用户。这并不是说只有合法查询来自这些帐户，或者恶意查询只来自非 SYSTEM 帐户。攻击者可以升级到 SYSTEM 并查询 LDAP。

该研究的目的是在攻击者获得访问权限后的早期阶段识别攻击者，并希望了解目标网络并识别可利用的攻击路径。

说到常见的 LDAP 查询，我们发现在测试环境中，7 天内有 13,963 个 LDAP 查询。大多数（如果不是全部）查询都与主机或用户对特定服务的访问以及主机的组策略处理有关。其中带有 objectClass=* 的 LDAP 查询占 12,577 个，大约占 90%。请记住，这包括所有用户。我们提到这一点是因为下面我们将提到我们从对手和红队那里看到的常见情况，但 objectClass=* 是其中的一部分，因为当使用ADExplorer等工具获取所有 AD 的快照时。在检测部分，我们有办法识别此活动，所以不用担心。

对抗行为

我们发现，如果对手和红队没有针对特定容器或对象类（稍后我们将讨论），他们会尝试抓取目标环境之外的所有东西以加快速度。一个很好的例子是攻击者利用 Sysinternals 的 ADExplorer 等工具。当这种情况发生时，LDAP 查询通常会包含 objectClass=* 或 objectGuid=*。这不一定是理想的，因为根据组织的规模，可能需要提取大量数据，并且可能会中断 C2 与代理正在运行的工作站之间的通信。我们想指出，这是一种可能性，攻击者行为与这些 LDAP 搜索之间存在关联，但我们希望专注于排除我们已识别的查询的恶意活动。

下面我们将给出一些值得注意的 LDAP 搜索示例，我们认为本文的读者应该最了解并会感兴趣，但请记住，这只是攻击者在环境中运行的查询的一小部分。许多攻击者使用 PowerShell 和 .NET 中现有的工具集自动执行的查询的数量和种类会让恶意行为更加引人注目。

Adversarial Behavior

我们不会深入讨论 Kerberoasting 是什么，但需要注意的是，如果攻击者首先不知道服务帐户，他们想要获取服务票证，那么他们将首先在 AD 中查询服务帐户。以下是使用Rubeus kerberoast标志的一些示例：

所有服务帐户：

(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

如您所见，LDAP 查询是独一无二的，很容易发现。但是，如果攻击者以特定服务主体名称 (SPN) 为目标，则不会发生 LDAP 搜索。如果对手请求特定加密类型的服务票证，您可以看到搜索也会略有变化。以下内容不包括AES票证。

非 AES 支持的服务帐户：

(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(!msds-supportedencryptiontypes:1.2.840.113556.1.4.804:=24))

只有AES支持的服务帐户：

(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(msds-supportedencryptiontypes:1.2.840.113556.1.4.804:=24))

侦察：

我们看到的LDAP的最常见用途之一是用于列举各种用户，组，密码到期时间等。以下示例。它们并不是有人可以运行的纯LDAP查询，而是查询中可能存在的内容以获取某些信息的示例。

基本用户：

(objectCategory=Person) or (objectclass=user)

域管理员组：

(&(objectclass=group)(samaccountname=*domain admins*))

圈密码：

(ms-MCS-AdmPwd=*)

PKI注册（从Lee和Will获得认证）：

(objectCategory=pKIEnrollmentService)

 认证机构：

(objectCategory=certificationAuthority

众所周知，还有很多已知的LDAP查询可以返回对手的宝贵信息，这些信息仅举几例。可以在这里找到更全面的列表。这里的重点是要知道LDAP可以并且被攻击者使用以获取信息，并用于设置和修改信息。

作为防御者的优势之一是，在典型的Windows域环境中，常规操作中执行的查询类型是标准配置，使得可以轻松制定一种策略，以使正常行为被过滤掉且仅登录异常值。使其成为一个更精确的规则集，它将使对手尝试混合更难，就是将其他元数据（如过程和用户）混合在一起。

涉及可用于 LDAP 的遥测时，真正的价值来自 Windows-LDAP-Client ETW 提供程序。该提供程序将获取客户端活动——即发出请求的进程。这个 ETW 提供商很好，但确实有一些限制，我们稍后会谈到。有几个提供 LDAP 遥测的供应商正在使用此 ETW 提供商。Microsoft Defender for Endpoint (MDE) 通过 DeviceEvents:LdapSearch 表公开 LDAP 数据。如果您持有像 Sysmon 这样的遥测传感器怎么办？Sysmon 不收集 LDAP 遥测数据，因此我们希望创建一些可以与 Sysmon 并行工作的东西。

LDAPMon + Sysmon

LDAPMon是 Jonny Johnson 创建的一个工具，旨在深入了解 LDAP 客户端活动。目前，这是一个研究概念验证，它收集 Windows-LDAP-Client ETW 提供程序，旨在与具有某种类型的进程创建事件（例如 Sysmon）的传感器结合。未来，卡洛斯和乔尼计划发布一个带有配置文件的更适合生产的版本，以便人们可以直接使用他们的机器并将其用作全职收集传感器。以下是可使用 LDAPMon 来获取活动的活动示例。所有示例都将具有相关查询，可以在此处找到。

Execute-Assembly + Rubeus

我们想要公开这种类型的活动，因为对于像 Cobalt Strike 这样的 C2 来说，生成一个进程、执行一些活动，然后终止该进程是很常见的。该查询背后的伪逻辑如下：

1. 处理A执行LDAP查询。

2. A 的父进程有一个正在回调的 TCP 或命名管道连接。

TCP：

Named Pipe:

InlineExecute-Assembly + Rubeus

多年来，越来越多的探测器将活动（例如执行组装）所吸引。要解决此问题，Shawn（ @anthemtotheego ）创建了一种将.NET加载到您当前过程并执行该活动的方法。这改变了检测策略：

1. 处理A执行LDAP查询。

2. 进程A具有TCP（不是端口389或636）或命名的管道连接到C2。

请记住，如果您要明确删除636之类的端口，这确实允许对手在雷达下运行。如果您不使用LDAP，则寻找636个连接可能很有价值。我们希望防止攻击者的任何逻辑逃避机会。

TCP：

Named Pipe: 

不幸的是，Windows-ldap-client ETW不会显示何时通过LDAP设置值。但是，我们想指出的是，当设置一个值时，仍然可以进行LDAP查询，并且我们可以在该活动上拾取该活动。

这些都是如何发现这些数据的示例。最终，在寻找LDAP活动时，我们建议从以下内容开始：

1. 删除系统，本地服务和网络服务帐户。

2. 提出请求的基线流程以及他们来自哪个父映像及其命令行。

3. 在执行底线时，利用用户，进程，父进程，命令行，ldapquery计数。

4. 寻找异常值。

5. 检查来自发出LDAP请求的过程（而不是端口389或636）或父母具有任何网络连接的过程。这将有助于使用执行组件或InlineExecute组装进行的活动。

6. 使用目标方法观察活动，但缓慢移动更广泛。

注意：当涉及基础线时，请确保不要删除VSCODE进程，因为VSCODE中有一个称为LDAP Explorer的扩展程序，可用于进行LDAP查询。

当依靠LDAP遥测时，很高兴注意到，不幸的是，LDAP客户端etw提供商可以通过ntdll.dll中的etweventwrite进行修补。这是因为持有LDAP功能（wldap32.dll）的DLL都会在每个发出LDAP请求的过程中加载。当登录活动的调用时，将信息传递给EtweventWrite函数。乔尼·约翰逊（Jonny Johnson）创建的POC可以在这里找到。一种替代方法是在InlineExecute组装中使用–ETW标志，该标志还修补了etweventwrite函数。详细介绍此发现的博客将在稍后出现，稍后将出现其他一些发现。

结论

随着我们继续识别对抗性贸易，最好看一下虽然可能不是“最新和最出色的”技术，但在功能上很长一段时间内都听起来很长。LDAP查询正是这种类型的Tradecraft。它是可靠的，很少有人在寻找恶意用法。我们想揭露一些贸易克罗夫特和我们用来识别这项活动的策略。我们希望读者能发现这个博客有帮助，如果有任何疑问，请伸出援手。

资源

• https://qa.social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

• https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api

• https://trustedsec.com/blog/adexplorer-on-engagements

• https://www.politoinc.com/post/ldap-queries-for-offensive-and-defensive-operations

原文始发于微信公众号（Ots安全）：发现对抗性LDAP Tradecraft