红队工具集体裸奔之后，有人用20年前的API做了件狠事

当你在自己的内网扫描漏洞时，EDR（端点检测与响应）报警比真正的攻击者来得还快——这不是段子，是AD（活动目录）安全圈的日常尴尬。

为什么所有工具都在"自曝"

BloodHound 几乎是 AD 安全领域的标配。攻击路径可视化、委托链分析、ACL 边关系，功能层面无可挑剔。

问题出在"怎么跑"。

SharpHound 是 .NET 程序集。它向网络倾泻的 LDAP 流量模式，零台合法工作站会产生。EDR 秒级检出，不是因为利用了多稀有的漏洞，而是行为签名本身就是块霓虹灯牌。

ADRecon、PowerView、Python 替代品，换汤不换药。运行时环境就是指纹。

内部红队和防御者被困在荒诞处境：必须枚举自己的域来提前发现配置错误，但手头所有工具都在尖叫"我在这里"。不可接受。

解法藏在 Windows 2000

答案其实一直都在。Active Directory Service Interfaces（ADSI），COM 架构的 LDAP 抽象层，Windows 自身持续调用。组策略用它，MMC 管理单元用它，net user /domain 也用它。

它产生的流量与正常域活动无法区分。因为它就是正常域活动。

这就是 Kestrel 的全部根基。

纯原生 C，无托管运行时，无包装层。直接 COM 虚表调用，没有 .NET、没有 PowerShell、没有你和网络之间的任何抽象：

代码层面，就是标准的认证 LDAP 绑定、分页搜索请求。每台域控每分钟从每台域工作站看到的常规流量。默认隐身。

v0.1 的五个被动模块

ADWS 端点检测：对每个域控的 9389 端口发起原始 TCP 连接。一个 SYN，无 WCF 握手，无 ADWS 帧结构。只问：端口开不开。

计算机拓扑：完整计算机清单，通过服务类别表解码 SPN（服务主体名称）。MSSQLSvc 映射 SQL Server，WSMAN 映射 WinRM，TERMSRV 映射 RDP。一次 LDAP 查询，零个发往目标主机的数据包。

委托风险：真正区分了多数工具混为一谈的三类：

无约束委托（非域控对象上的 TRUSTED_FOR_DELEGATION）——Kerberos 票据携带转发的 TGT，高危。

约束委托（msDS-AllowedToDelegateTo）——精确枚举目标 SPN。

协议转换/S4U2Self（UAC & 0x1000000）——服务可在无用户凭据的情况下获取任意域用户票据，风险画像不同，单独报告。多数工具完全漏掉这个区分。

LAPS 覆盖：同时检测旧版 LAPS（ms-Mcs-AdmPwdExpirationTime）和 Windows LAPS 2023+（msLAPS-EncryptedPasswordHistory）。将计算机按托管/未托管分类并给出百分比。本地管理员暴露面一目了然。

正方：这是防御者需要的"不对称"

支持者的核心论点很直接：攻防本就信息不对称，攻击者可以花数周潜伏、慢慢枚举，防御者却必须在被发现前完成扫描。Kestrel 把天平往回扳了一点。

技术实现上，它剥离了所有"方便"带来的代价。.NET 的反射、PowerShell 的脚本块、Python 的解释器——这些现代开发者的舒适区，在网络层都是可追踪的异常。回到 COM 和 C，等于回到操作系统自身的噪声基底。

五个模块的选择也有讲究：全是"只读"操作。ADWS 探测是 TCP 握手，计算机拓扑和委托分析是 LDAP 查询，LAPS 检测是属性读取。没有写入，没有凭证操作，没有横向移动痕迹。这意味着即使在最高敏感度的生产环境，触发审计警报的概率也极低。

更深层的好处是"行为对齐"。当防御团队用与业务系统相同的 API 做安全检查时，他们实际上在验证"攻击者能否完美伪装成正常业务流量"。这是一种更真实的威胁建模。

反方：隐身本身成为新的风险

批评者的担忧同样尖锐。如果防御工具能完美隐身，攻击者为何不能？Kestrel 的代码是公开的，技术原理是文档化的。今天它帮红队躲 EDR，明天就能帮真正的 APT 躲 SOC。

这触及一个更古老的悖论：安全工具的"双重用途"困境。漏洞扫描器、密码破解工具、流量分析套件，历史上所有强大的安全工具都面临同样的质疑。Kestrel 的特殊之处在于，它的"隐蔽性"是架构层面的，而非配置层面的——你无法通过调整参数让它变得更"可见"以区分善意使用。

另一个问题是"检测逃逸"的伦理边界。EDR 厂商投入大量资源识别 SharpHound 等工具，正是因为这些模式与真实攻击高度相关。Kestrel 通过"看起来像正常流量"绕过检测，本质上是在训练防御体系忽略某些信号。长期来看，这是否削弱了整体安全态势？

还有运维层面的质疑：纯 C + COM 的开发门槛显著高于 .NET 或 Python。安全团队是否愿意为了隐蔽性牺牲可维护性？当原始作者停止更新，组织内部是否有能力接手？

我的判断：这不是工具问题，是检测哲学问题

Kestrel 的真正价值不在于"让红队更隐蔽"，而在于暴露了一个被忽视的真相：我们对"正常"的定义过于粗糙。

EDR 把 .NET LDAP 查询标记为可疑，不是因为查询本身有问题，而是因为"用 .NET 做这件事的人不多"。这是一种基于"稀有性"的启发式，而非基于"恶意性"的判定。Kestrel 证明，当攻击者愿意放弃现代开发便利、回到系统原生接口时，这种启发式立即失效。

这迫使防御者回答一个不舒服的问题：如果我们无法区分"恶意的 LDAP 查询"和"正常的 LDAP 查询"，我们应该把检测重心放在哪里？

可能的答案包括：关注查询后的行为（数据去了哪）、关注身份上下文（谁在非工作时间查询）、关注查询模式（是否遍历全量对象）。这些方向都比"标记 .NET 程序"更困难，但也更鲁棒。

Kestrel 的五个模块设计也暗示了一种更务实的风险评估策略：不追求"全面扫描"，而是针对高杠杆配置点（委托、LAPS、暴露服务）做精准检查。在无法做到"全可见"的环境中，"高信噪比"可能是更可持续的选择。

最后，关于"双重用途"的担忧——它真实存在，但不应成为拒绝改进的借口。攻击者已经会写 C，已经懂 COM。Kestrel 的存在只是让防御者获得了对等的知识。真正的防线不在于隐藏技术细节，而在于缩短"攻击者知道"到"防御者知道"的时间差。

当内部团队能用与攻击者相同的技术手段验证控制有效性时，安全才真正从"合规检查"变成"对抗演练"。

如果 EDR 无法区分你的安全扫描和正常业务流量，问题究竟出在扫描工具太隐蔽，还是检测逻辑太懒惰？