1. 项目概述从“信息收集”到“权限维持”的攻防博弈在任何一个稍具规模的企业内网环境中安全攻防的焦点往往不在于边界防火墙被瞬间击穿而在于攻击者一旦获得一个初始立足点后如何在内网中悄无声息地横向移动、权限提升直至掌控整个域。这个过程我们称之为内网渗透。它不像电影里演的那样充满炫酷的代码瀑布更多时候是枯燥但至关重要的信息收集、关系梳理和权限滥用。而Active DirectoryAD作为Windows域环境的核心自然成了这场博弈的主战场。AD里存储了所有用户、计算机、组策略等关键信息就像一个企业的“人员与资产花名册”。攻击者的目标就是拿到这本花名册并搞清楚谁有权限访问哪些重要资产比如域控服务器。AdFind正是这样一款在渗透测试人员和红队手中流传已久的“瑞士军刀”。它不是一个图形化工具而是一个命令行工具能让你以极低的权限、极静默的方式从AD中查询出海量信息。很多人觉得命令行工具门槛高但恰恰是这种“不友好”让它具备了极强的隐蔽性和灵活性可以轻松集成到自动化脚本中。那么攻击者用AdFind找什么呢绝不是漫无目的。一个经典的攻击路径是寻找“委派”配置不当的账户或计算机。你可以把“委派”理解为一种“权限委托”A账户信任B账户允许B“代表”A去访问某个服务。这本是AD中实现单点登录等便利功能的设计但一旦配置错误比如过度的“无约束委派”或“基于资源的约束委派”它就会变成一个危险的“后门”让攻击者实现权限飞跃从一台普通办公电脑直接获取域控制器的最高权限。因此理解AdFind的用法不仅是攻击方需要掌握的技能更是防御方必须看清的“攻击者视角”。只有知道攻击者如何窥视你的内网你才能有效地布防。本文将从实战出发详解AdFind的核心命令并深入剖析如何利用它发现委派漏洞以及作为防御者该如何构建检测与防御体系。2. AdFind核心命令全解析你的内网“侦察机”AdFind的强大在于它能够使用轻量级的LDAP查询几乎触及AD中的所有对象。它的基础语法很简单AdFind -h [域控地址] -b [搜索基础] [过滤条件] [输出选项]。在实际内网中我们往往已经通过某种方式如钓鱼、漏洞利用获得了一台域内主机的普通权限并抓取到了当前用户的哈希或密码。此时我们不需要直接连接域控AdFind可以默认使用当前用户的上下文进行认证查询这非常隐蔽。2.1 基础信息收集摸清家底刚进入内网首要任务是绘制地图。以下命令是信息收集的起点查询域基础信息# 查询域的名称、SID、域控主机名等 AdFind -schema -s base -b objectclass* # 更直接地获取域信息 AdFind -rootdse第一条命令从根开始查询架构信息-s base表示只搜索基础对象本身。-rootdse则能快速列出域控制器的支持功能、命名上下文等这是了解AD环境的快捷方式。枚举所有域用户# 列出所有用户显示姓名和登录名 AdFind -f objectcategoryperson -dn # 获取更详细的信息如最后登录时间、描述描述里常有密码 AdFind -f objectcategoryperson name samaccountname lastlogon description-f后面跟的是LDAP过滤条件。objectcategoryperson和objectclassuser通常可以互换但person更精确。显示description字段至关重要因为很多管理员习惯把密码写在用户描述里这是低垂的果实。枚举所有域计算机# 列出所有计算机账户 AdFind -f objectcategorycomputer name dnshostname operatingsystem了解内网有哪些机器它们的操作系统是什么是横向移动的基础。dnshostname字段能给出完整的DNS名称方便后续扫描。枚举所有域组# 列出所有组 AdFind -f objectcategorygroup name # 重点查询高权限组如域管理员组 AdFind -f ((objectcategorygroup)(nameDomain Admins)) member直接查询“Domain Admins”组的成员可以让你一眼看清谁拥有域内最高权限。但聪明的攻击者不会只盯着这一个组“Enterprise Admins”、“Schema Admins”、“Domain Controllers”组同样重要。注意默认查询可能会返回成千上万条结果。使用-gc参数可以查询全局编录速度更快但信息可能不完整。在大型企业中建议总是结合-list或-csv参数将结果输出到文件方便分析。2.2 深度信息挖掘寻找攻击路径基础信息只是目录深度信息才能找到门。攻击者关注的是关系与属性。查询用户SPN服务主体名称# 查找所有注册了SPN的用户账户可能是服务账户 AdFind -f (objectcategoryperson)(servicePrincipalName*) servicePrincipalName samaccountnameSPN是Kerberos协议中用于标识服务实例的唯一名称。如果一个用户账户而非常见的计算机账户注册了SPN它很可能是一个服务账户。服务账户的密码往往强度高且很少更改是Kerberoasting攻击的理想目标——我们可以尝试破解其票据哈希来获取密码。查询敏感用户属性# 查找设置了“密码永不过期”的用户 AdFind -f (objectcategoryperson)(userAccountControl:AND:65536) samaccountname # 查找被禁用的账户 AdFind -f (objectcategoryperson)(userAccountControl:AND:2) samaccountname # 查找不需要预认证的账户易受AS-REP Roasting攻击 AdFind -f (objectcategoryperson)(userAccountControl:AND:4194304) samaccountnameuserAccountControl是一个位掩码属性包含了账户的大量控制标志。AdFind使用AND语法进行位运算过滤。这些属性直接关联到账户的安全配置弱点。信任关系与跨域查询# 查询当前域的信任域 AdFind -f objectclasstrustedDomain name # 如果有信任关系可以尝试查询信任域的用户 AdFind -h 信任域域控IP -b dcchild,dccom -f objectcategoryperson在拥有多域林的企业中域间信任关系可能成为横向移动的跳板。查询信任域是拓展攻击面的关键一步。2.3 输出控制与隐蔽技巧侦察不仅要全面更要隐蔽。控制输出范围# 只显示特定属性减少网络流量和日志量 AdFind -f objectcategorycomputer name operatingsystem -list # 将结果以CSV格式输出便于导入Excel或脚本处理 AdFind -f objectcategoryperson samaccountname department title -csv-list参数让输出更简洁-csv格式则便于后续数据处理。避免使用默认的宽格式输出大量不必要的信息。使用延迟和随机化在自动化脚本中在AdFind命令之间插入随机的sleep时间如3-10秒可以模拟正常用户行为规避基于请求频率的简单检测。虽然AdFind本身很安静但大量、快速的LDAP查询仍然可能在域控的日志中形成异常模式。实操心得不要在一次渗透测试中运行一个“万能”命令来收集所有信息。这会产生巨大的、异常的LDAP查询流量。应该分阶段、分目标进行。例如第一天只收集用户和组列表第二天再针对特定的高价值组或OU组织单位进行深度查询。这种“低慢小”的策略能极大提升隐蔽性。3. 委派攻击原理深度剖析滥用信任链理解了信息收集我们进入更危险的领域委派攻击。这是AD中高阶且常见的提权手法。要防御必须先透彻理解其原理。3.1 委派的核心概念与类型在Kerberos认证协议中当用户访问一个服务时服务通常只能以用户身份访问自身。但如果服务需要“代表”用户去访问另一个后端服务比如Web服务器代表用户去访问数据库就需要“委派”功能。AD中有三种主要委派类型无约束委派这是最古老、最危险的类型。配置了无约束委派的账户通常是计算机账户因为早期IIS等应用运行在机器账户下收到用户的TGT票据授予票据后可以缓存它并用这个TGT去代表用户访问域内任何其他服务。这相当于把用户的万能钥匙交给了服务。约束委派微软为了修复无约束委派的风险而引入。它允许管理员明确指定服务A可以代表用户去访问哪些特定的服务B通过SPN指定。这需要服务A拥有一个特殊的属性msDS-AllowedToDelegateTo。攻击面缩小了但风险依然存在。基于资源的约束委派这是Windows Server 2012后引入的更安全模型。权限配置在资源后端服务B身上而不是前端服务A身上。资源B的msDS-AllowedToActOnBehalfOfOtherIdentity属性决定了谁可以代表其他用户来访问自己。这种模型在错误配置时同样可被利用且利用门槛更高。3.2 利用AdFind狩猎委派配置攻击者的首要任务是找到配置了委派的账户。AdFind是完成这项任务的利器。查找无约束委派账户# 查找所有配置了无约束委派的计算机账户 AdFind -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name dnshostname # 查找所有配置了无约束委派的用户账户较少见但更危险 AdFind -f ((objectcategoryperson)(userAccountControl:AND:524288)) samaccountnameuserAccountControl中的5242880x80000位就是“TRUSTED_FOR_DELEGATION”标志即无约束委派。查找约束委派账户# 查找配置了约束委派的服务账户用户或计算机 AdFind -f ((objectcategoryperson)(msDS-AllowedToDelegateTo*)) samaccountname msDS-AllowedToDelegateTo AdFind -f ((objectcategorycomputer)(msDS-AllowedToDelegateTo*)) name msDS-AllowedToDelegateTomsDS-AllowedToDelegateTo属性列出了该账户被允许委派到的服务SPN列表。看到这个属性非空就要提高警惕。查找基于资源的约束委派配置# 查找所有计算机账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性 AdFind -f objectcategorycomputer name msDS-AllowedToActOnBehalfOfOtherIdentity这个属性存储的是安全描述符直接查看可能是一串SID。需要进一步解析才能知道具体是哪个账户被授权。3.3 攻击链模拟从发现到利用假设我们通过AdFind发现一台名为WEB-SRV的服务器配置了无约束委派。信息确认AdFind -f ((objectcategorycomputer)(nameWEB-SRV)) userAccountControl确认其userAccountControl值包含524288。定位与访问我们需要获得WEB-SRV上的一个Shell。这可能通过漏洞利用、密码喷洒如果知道本地管理员密码或利用其他服务漏洞实现。等待与捕获一旦在WEB-SRV上立足我们可以使用Mimikatz的sekurlsa::tickets命令或Rubeus等工具监控并导出缓存的所有Kerberos票据。由于是无约束委派任何域用户包括域管理员访问WEB-SRV上的任何服务时其TGT都可能被缓存。权限飞跃如果我们捕获到了域管理员的TGT就可以在WEB-SRV上使用这个TGT向域控制器申请访问任何其他服务的票据从而完全控制整个域。对于约束委派攻击链更复杂一些。我们需要控制一个配置了约束委派的账户S并且知道其密码或哈希。然后我们可以使用该账户的权限代表任意用户甚至是我们不知道密码的用户去访问其被允许委派到的特定服务T。这通常需要用到像getSTImpacket套件或Rubeus这样的工具来伪造票据。注意事项委派攻击的成功极度依赖环境。无约束委派需要攻击者能控制委派主机并等待高权限用户连接。约束委派需要攻击者已拥有委派账户的凭据。在实际测试中这些条件并非总能满足因此信息收集阶段发现的委派配置需要结合其他漏洞如权限提升到本地管理员才能成功利用。切勿将“发现漏洞”等同于“可以直接利用”。4. 防御指南构建基于检测与加固的纵深防线知道了攻击者如何寻找和利用委派防御思路就清晰了清理不当配置、监控异常行为、实施最小权限原则。4.1 主动发现与清理加固阶段定期使用AdFind进行自我审计但要以防御者视角。你可以在一台加入域的、权限足够的管理员工作站上运行。审计脚本示例PowerShell集成AdFind# 1. 查找无约束委派计算机 $unconstrainedComputers .\AdFind.exe -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name -list if ($unconstrainedComputers) { Write-Host [高危] 发现无约束委派计算机 -ForegroundColor Red $unconstrainedComputers # 建议评估这些计算机是否真的需要无约束委派。对于Web服务器、SQL Server等应优先使用约束委派或基于资源的约束委派。 } # 2. 查找无约束委派用户应极少见 $unconstrainedUsers .\AdFind.exe -f ((objectcategoryperson)(userAccountControl:AND:524288)) samaccountname -list if ($unconstrainedUsers) { Write-Host [紧急] 发现无约束委派用户账户风险极高 -ForegroundColor Red $unconstrainedUsers # 建议立即审查并清除这些账户的委派标志或删除不必要的账户。 } # 3. 查找约束委派配置 $constrainedAccounts .\AdFind.exe -f (msDS-AllowedToDelegateTo*) samaccountname msDS-AllowedToDelegateTo -list if ($constrainedAccounts) { Write-Host [中危] 发现约束委派配置请审查 -ForegroundColor Yellow $constrainedAccounts | Format-List # 建议审查每个账户的msDS-AllowedToDelegateTo列表确保只包含必要且最低权限的服务。 }运行此类审计脚本应成为季度或半年安全巡检的固定动作。对于发现的异常配置需联合业务部门确认必要性并遵循“最小权限”原则进行整改。4.2 实时监控与告警检测阶段攻击者的AdFind查询和委派利用行为会在AD和主机上留下日志。关键在于正确启用并解读这些日志。关键监控点域控制器安全日志事件ID4662对AD对象的操作。需要关注Object Type是%{bf967aa5-0de6-11d0-a285-00aa003049e2}即domainDNS对象或特定OU的访问。攻击者大规模枚举用户/计算机时会触发大量此类日志。但正常管理操作也会产生需建立基线。5145网络共享对象被检查。AdFind查询可能会触发。4672分配特殊权限。与权限提升相关。4769Kerberos服务票据请求。关注Ticket Options包含0x40810000无约束委派的请求以及来自非常规客户端的Service NameSPN请求。Sysmon日志如果已部署事件ID 1进程创建。监控AdFind.exe进程的创建其父进程可能是cmd、powershell或渗透测试框架。事件ID 10进程访问。如果攻击者尝试读取lsass进程内存用Mimikatz抓取委派缓存的TGT会触发此事件。事件ID 22DNS查询。AdFind查询可能会产生对域控的DNS查询。SIEM规则示例在SIEM如Splunk, Elastic SIEM中可以构建如下关联规则规则1异常LDAP查询在短时间内如5分钟来自同一源IP非域控、非IT管理终端的4662事件数量超过阈值如1000次且操作类型为“读取属性”。规则2可疑进程链进程创建事件中出现AdFind.exe且其父进程是powershell.exe或cmd.exe而该powershell/cmd又来自一个非常规路径或由非管理员用户启动。规则3委派票据异常安全日志中4769事件Ticket Options包含0x40810000无约束委派标志且Client Address不是已知的服务器IP。实操心得纯粹的日志监控很容易产生误报。最有效的方法是结合“资产清册”和“行为基线”。例如事先记录哪些管理终端有权限进行AD查询哪些服务器应该配置了委派。任何偏离这个“白名单”或“已知正常模式”的行为都值得高优先级调查。同时在关键服务器尤其是域控和疑似配置委派的服务器上部署EDR/AV监控对lsass进程的访问尝试这是捕捉凭证窃取和票据转储的最后一道防线。4.3 架构与权限最佳实践预防阶段淘汰无约束委派这是最高优先级的行动。对所有已发现的无约束委派账户进行评估。对于Windows Server 2003以后的应用应使用约束委派或基于资源的约束委派替代。如果业务上确实无法更改则必须将这些主机视为“Tier 0”资产最高安全等级进行严格隔离和监控。最小化约束委派审查所有msDS-AllowedToDelegateTo列表确保只包含业务绝对必需的后端服务SPN且这些服务本身也进行了安全加固。服务账户管理为需要委派的服务使用独立的、强密码的服务账户gMSA-组托管服务账户是更佳选择并确保这些账户不属于任何高权限组。定期轮换其密码。实施网络分段将域控制器、配置了委派的服务、高价值服务器划分到不同的网络区域限制它们之间的直接通信强制通过跳板机进行管理。这可以增加攻击者横向移动的难度。启用Protected Users组对于所有高权限账户尤其是域管理员将其加入“Protected Users”安全组。这会强制使用Kerberos AES加密并阻止使用NTLM认证、无约束/约束委派等较弱的特性能从源头上防御多种委派攻击和凭证盗窃。5. 实战演练与问题排查实录理论结合实战才能融会贯通。这里模拟一个从发现到防御的完整场景。场景在一次授权的内部渗透测试中我们获得了一个域普通用户john.doe的权限。步骤1初始侦察我们登录到一台已加入域的跳板机上传AdFind。# 快速摸清域结构 AdFind -rootdse # 发现域名为corp.com域控为DC01.corp.com # 枚举高权限组用户 AdFind -f ((objectcategorygroup)(nameDomain Admins)) member # 发现域管理员是admin.administrator # 枚举所有计算机寻找可能的初始目标 AdFind -f objectcategorycomputer name operatingsystem | findstr /i server # 发现一台名为IIS01的服务器运行Windows Server 2019步骤2狩猎委派# 查找无约束委派计算机 AdFind -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name # 输出IIS01太好了IIS01配置了无约束委派。这是一个典型的旧版IIS服务器配置。步骤3获取IIS01的访问权我们尝试对IIS01进行端口扫描用PowerShell或上传的轻量工具发现开放了80Web、5985WinRM端口。通过Web漏洞比如一个简单的文件上传或对已知的本地管理员密码进行喷洒假设内网存在密码复用我们成功在IIS01上获得了命令执行权限。步骤4捕获票据在IIS01上我们运行Mimikatz或更隐蔽的Rubeus来监控票据。# 使用Rubeus监控需要管理员权限 Rubeus.exe monitor /interval:5 /filteruser:DC01$我们等待域管理员或其他高权限账户访问IIS01上的服务可能是Web应用也可能是管理员进行维护。一旦捕获到域控制器计算机账户DC01$或其他高权限用户的TGT攻击就成功了。步骤5权限提升与防御响应模拟假设我们捕获到了DC01$的TGT。现在我们可以用这个TGT向域控制器请求任何服务的票据从而完全控制域。但在真实的蓝队演练中此时防御体系应该已经告警。蓝队视角的问题排查告警触发SIEM规则“异常LDAP查询”可能早在步骤1就告警因为john.doe这个销售部门的账户突然进行了大量的AD枚举。但此时可能是误报需要调查。深度调查安全分析师查看相关日志。发现来自john.doe账户的LDAP查询使用了AdFind工具特征。发现IIS01服务器上出现了异常进程如Mimikatz或Rubeus触发了EDR告警。发现从IIS01向域控制器发起的、使用了无约束委派标志的Kerberos请求事件ID 4769且请求用户是DC01$。响应与遏制立即隔离将IIS01服务器从网络中断开并冻结john.doe的账户。取证分析对IIS01进行内存和磁盘取证确认攻击者使用的工具、留下的后门和窃取的凭证。根源修复审查并清除IIS01计算机账户的无约束委派标志。检查IIS01上存在的漏洞文件上传、弱密码并进行修补。审查john.doe账户的失陷原因可能是钓鱼邮件并开展全员安全意识培训。考虑将域管理员账户加入“Protected Users”组并实施LAPS本地管理员密码解决方案来管理服务器本地管理员密码防止密码喷洒。常见问题速查表问题现象可能原因排查步骤与解决方案AdFind查询返回空或错误1. 当前用户权限不足。2. 网络不通或防火墙阻止LDAP端口389/636。3. 工具路径或语法错误。1. 使用whoami /all确认权限尝试获取更高权限。2. 使用telnet DC_IP 389测试连通性。3. 使用AdFind -h查看帮助检查命令语法尤其是-b基础DN是否正确。发现大量无约束委派计算机历史遗留配置或旧版应用要求。1. 建立清单联系业务负责人确认必要性。2. 制定迁移计划改用约束委派或基于资源的约束委派。3. 对无法迁移的主机实施严格网络隔离和增强监控。SIEM中LDAP查询告警泛滥正常的管理活动如账号同步、监控软件也会产生大量查询。1. 建立行为基线识别并白名单合法的管理终端、监控服务器IP和用于查询的服务账户。2. 优化规则将告警阈值与基线结合或增加过滤条件如排除特定OU的查询。3. 关联其他可疑事件如告警前后有漏洞利用或异常登录尝试。无法确定委派是否被利用日志不清晰或攻击者使用了加密/混淆技术。1. 检查疑似被利用主机如IIS01上的Kerberos票据缓存需在攻击发生不久后取证。2. 检查域控制器上来自该主机的4769事件寻找可疑的Service Name或来自高权限账户的请求。3. 回顾网络流量记录寻找主机间非常规的Kerberos或SMB流量。内网安全是一场持续的猫鼠游戏。工具本身无善恶AdFind在管理员手中是审计利器在攻击者手中则是侦察尖刀。防御的核心不在于封禁某一个工具而在于构建一个基于“零信任”和“最小权限”的纵深防御体系并配以有效的监控和响应能力。定期用攻击者的视角审视自己的AD环境使用像AdFind这样的工具进行自我攻击面评估及时清理像无约束委派这样的“历史债务”才能让内网真正固若金汤。
AdFind工具实战：从LDAP信息收集到Active Directory委派攻击检测
发布时间：2026/6/29 8:13:25
1. 项目概述从“信息收集”到“权限维持”的攻防博弈在任何一个稍具规模的企业内网环境中安全攻防的焦点往往不在于边界防火墙被瞬间击穿而在于攻击者一旦获得一个初始立足点后如何在内网中悄无声息地横向移动、权限提升直至掌控整个域。这个过程我们称之为内网渗透。它不像电影里演的那样充满炫酷的代码瀑布更多时候是枯燥但至关重要的信息收集、关系梳理和权限滥用。而Active DirectoryAD作为Windows域环境的核心自然成了这场博弈的主战场。AD里存储了所有用户、计算机、组策略等关键信息就像一个企业的“人员与资产花名册”。攻击者的目标就是拿到这本花名册并搞清楚谁有权限访问哪些重要资产比如域控服务器。AdFind正是这样一款在渗透测试人员和红队手中流传已久的“瑞士军刀”。它不是一个图形化工具而是一个命令行工具能让你以极低的权限、极静默的方式从AD中查询出海量信息。很多人觉得命令行工具门槛高但恰恰是这种“不友好”让它具备了极强的隐蔽性和灵活性可以轻松集成到自动化脚本中。那么攻击者用AdFind找什么呢绝不是漫无目的。一个经典的攻击路径是寻找“委派”配置不当的账户或计算机。你可以把“委派”理解为一种“权限委托”A账户信任B账户允许B“代表”A去访问某个服务。这本是AD中实现单点登录等便利功能的设计但一旦配置错误比如过度的“无约束委派”或“基于资源的约束委派”它就会变成一个危险的“后门”让攻击者实现权限飞跃从一台普通办公电脑直接获取域控制器的最高权限。因此理解AdFind的用法不仅是攻击方需要掌握的技能更是防御方必须看清的“攻击者视角”。只有知道攻击者如何窥视你的内网你才能有效地布防。本文将从实战出发详解AdFind的核心命令并深入剖析如何利用它发现委派漏洞以及作为防御者该如何构建检测与防御体系。2. AdFind核心命令全解析你的内网“侦察机”AdFind的强大在于它能够使用轻量级的LDAP查询几乎触及AD中的所有对象。它的基础语法很简单AdFind -h [域控地址] -b [搜索基础] [过滤条件] [输出选项]。在实际内网中我们往往已经通过某种方式如钓鱼、漏洞利用获得了一台域内主机的普通权限并抓取到了当前用户的哈希或密码。此时我们不需要直接连接域控AdFind可以默认使用当前用户的上下文进行认证查询这非常隐蔽。2.1 基础信息收集摸清家底刚进入内网首要任务是绘制地图。以下命令是信息收集的起点查询域基础信息# 查询域的名称、SID、域控主机名等 AdFind -schema -s base -b objectclass* # 更直接地获取域信息 AdFind -rootdse第一条命令从根开始查询架构信息-s base表示只搜索基础对象本身。-rootdse则能快速列出域控制器的支持功能、命名上下文等这是了解AD环境的快捷方式。枚举所有域用户# 列出所有用户显示姓名和登录名 AdFind -f objectcategoryperson -dn # 获取更详细的信息如最后登录时间、描述描述里常有密码 AdFind -f objectcategoryperson name samaccountname lastlogon description-f后面跟的是LDAP过滤条件。objectcategoryperson和objectclassuser通常可以互换但person更精确。显示description字段至关重要因为很多管理员习惯把密码写在用户描述里这是低垂的果实。枚举所有域计算机# 列出所有计算机账户 AdFind -f objectcategorycomputer name dnshostname operatingsystem了解内网有哪些机器它们的操作系统是什么是横向移动的基础。dnshostname字段能给出完整的DNS名称方便后续扫描。枚举所有域组# 列出所有组 AdFind -f objectcategorygroup name # 重点查询高权限组如域管理员组 AdFind -f ((objectcategorygroup)(nameDomain Admins)) member直接查询“Domain Admins”组的成员可以让你一眼看清谁拥有域内最高权限。但聪明的攻击者不会只盯着这一个组“Enterprise Admins”、“Schema Admins”、“Domain Controllers”组同样重要。注意默认查询可能会返回成千上万条结果。使用-gc参数可以查询全局编录速度更快但信息可能不完整。在大型企业中建议总是结合-list或-csv参数将结果输出到文件方便分析。2.2 深度信息挖掘寻找攻击路径基础信息只是目录深度信息才能找到门。攻击者关注的是关系与属性。查询用户SPN服务主体名称# 查找所有注册了SPN的用户账户可能是服务账户 AdFind -f (objectcategoryperson)(servicePrincipalName*) servicePrincipalName samaccountnameSPN是Kerberos协议中用于标识服务实例的唯一名称。如果一个用户账户而非常见的计算机账户注册了SPN它很可能是一个服务账户。服务账户的密码往往强度高且很少更改是Kerberoasting攻击的理想目标——我们可以尝试破解其票据哈希来获取密码。查询敏感用户属性# 查找设置了“密码永不过期”的用户 AdFind -f (objectcategoryperson)(userAccountControl:AND:65536) samaccountname # 查找被禁用的账户 AdFind -f (objectcategoryperson)(userAccountControl:AND:2) samaccountname # 查找不需要预认证的账户易受AS-REP Roasting攻击 AdFind -f (objectcategoryperson)(userAccountControl:AND:4194304) samaccountnameuserAccountControl是一个位掩码属性包含了账户的大量控制标志。AdFind使用AND语法进行位运算过滤。这些属性直接关联到账户的安全配置弱点。信任关系与跨域查询# 查询当前域的信任域 AdFind -f objectclasstrustedDomain name # 如果有信任关系可以尝试查询信任域的用户 AdFind -h 信任域域控IP -b dcchild,dccom -f objectcategoryperson在拥有多域林的企业中域间信任关系可能成为横向移动的跳板。查询信任域是拓展攻击面的关键一步。2.3 输出控制与隐蔽技巧侦察不仅要全面更要隐蔽。控制输出范围# 只显示特定属性减少网络流量和日志量 AdFind -f objectcategorycomputer name operatingsystem -list # 将结果以CSV格式输出便于导入Excel或脚本处理 AdFind -f objectcategoryperson samaccountname department title -csv-list参数让输出更简洁-csv格式则便于后续数据处理。避免使用默认的宽格式输出大量不必要的信息。使用延迟和随机化在自动化脚本中在AdFind命令之间插入随机的sleep时间如3-10秒可以模拟正常用户行为规避基于请求频率的简单检测。虽然AdFind本身很安静但大量、快速的LDAP查询仍然可能在域控的日志中形成异常模式。实操心得不要在一次渗透测试中运行一个“万能”命令来收集所有信息。这会产生巨大的、异常的LDAP查询流量。应该分阶段、分目标进行。例如第一天只收集用户和组列表第二天再针对特定的高价值组或OU组织单位进行深度查询。这种“低慢小”的策略能极大提升隐蔽性。3. 委派攻击原理深度剖析滥用信任链理解了信息收集我们进入更危险的领域委派攻击。这是AD中高阶且常见的提权手法。要防御必须先透彻理解其原理。3.1 委派的核心概念与类型在Kerberos认证协议中当用户访问一个服务时服务通常只能以用户身份访问自身。但如果服务需要“代表”用户去访问另一个后端服务比如Web服务器代表用户去访问数据库就需要“委派”功能。AD中有三种主要委派类型无约束委派这是最古老、最危险的类型。配置了无约束委派的账户通常是计算机账户因为早期IIS等应用运行在机器账户下收到用户的TGT票据授予票据后可以缓存它并用这个TGT去代表用户访问域内任何其他服务。这相当于把用户的万能钥匙交给了服务。约束委派微软为了修复无约束委派的风险而引入。它允许管理员明确指定服务A可以代表用户去访问哪些特定的服务B通过SPN指定。这需要服务A拥有一个特殊的属性msDS-AllowedToDelegateTo。攻击面缩小了但风险依然存在。基于资源的约束委派这是Windows Server 2012后引入的更安全模型。权限配置在资源后端服务B身上而不是前端服务A身上。资源B的msDS-AllowedToActOnBehalfOfOtherIdentity属性决定了谁可以代表其他用户来访问自己。这种模型在错误配置时同样可被利用且利用门槛更高。3.2 利用AdFind狩猎委派配置攻击者的首要任务是找到配置了委派的账户。AdFind是完成这项任务的利器。查找无约束委派账户# 查找所有配置了无约束委派的计算机账户 AdFind -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name dnshostname # 查找所有配置了无约束委派的用户账户较少见但更危险 AdFind -f ((objectcategoryperson)(userAccountControl:AND:524288)) samaccountnameuserAccountControl中的5242880x80000位就是“TRUSTED_FOR_DELEGATION”标志即无约束委派。查找约束委派账户# 查找配置了约束委派的服务账户用户或计算机 AdFind -f ((objectcategoryperson)(msDS-AllowedToDelegateTo*)) samaccountname msDS-AllowedToDelegateTo AdFind -f ((objectcategorycomputer)(msDS-AllowedToDelegateTo*)) name msDS-AllowedToDelegateTomsDS-AllowedToDelegateTo属性列出了该账户被允许委派到的服务SPN列表。看到这个属性非空就要提高警惕。查找基于资源的约束委派配置# 查找所有计算机账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性 AdFind -f objectcategorycomputer name msDS-AllowedToActOnBehalfOfOtherIdentity这个属性存储的是安全描述符直接查看可能是一串SID。需要进一步解析才能知道具体是哪个账户被授权。3.3 攻击链模拟从发现到利用假设我们通过AdFind发现一台名为WEB-SRV的服务器配置了无约束委派。信息确认AdFind -f ((objectcategorycomputer)(nameWEB-SRV)) userAccountControl确认其userAccountControl值包含524288。定位与访问我们需要获得WEB-SRV上的一个Shell。这可能通过漏洞利用、密码喷洒如果知道本地管理员密码或利用其他服务漏洞实现。等待与捕获一旦在WEB-SRV上立足我们可以使用Mimikatz的sekurlsa::tickets命令或Rubeus等工具监控并导出缓存的所有Kerberos票据。由于是无约束委派任何域用户包括域管理员访问WEB-SRV上的任何服务时其TGT都可能被缓存。权限飞跃如果我们捕获到了域管理员的TGT就可以在WEB-SRV上使用这个TGT向域控制器申请访问任何其他服务的票据从而完全控制整个域。对于约束委派攻击链更复杂一些。我们需要控制一个配置了约束委派的账户S并且知道其密码或哈希。然后我们可以使用该账户的权限代表任意用户甚至是我们不知道密码的用户去访问其被允许委派到的特定服务T。这通常需要用到像getSTImpacket套件或Rubeus这样的工具来伪造票据。注意事项委派攻击的成功极度依赖环境。无约束委派需要攻击者能控制委派主机并等待高权限用户连接。约束委派需要攻击者已拥有委派账户的凭据。在实际测试中这些条件并非总能满足因此信息收集阶段发现的委派配置需要结合其他漏洞如权限提升到本地管理员才能成功利用。切勿将“发现漏洞”等同于“可以直接利用”。4. 防御指南构建基于检测与加固的纵深防线知道了攻击者如何寻找和利用委派防御思路就清晰了清理不当配置、监控异常行为、实施最小权限原则。4.1 主动发现与清理加固阶段定期使用AdFind进行自我审计但要以防御者视角。你可以在一台加入域的、权限足够的管理员工作站上运行。审计脚本示例PowerShell集成AdFind# 1. 查找无约束委派计算机 $unconstrainedComputers .\AdFind.exe -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name -list if ($unconstrainedComputers) { Write-Host [高危] 发现无约束委派计算机 -ForegroundColor Red $unconstrainedComputers # 建议评估这些计算机是否真的需要无约束委派。对于Web服务器、SQL Server等应优先使用约束委派或基于资源的约束委派。 } # 2. 查找无约束委派用户应极少见 $unconstrainedUsers .\AdFind.exe -f ((objectcategoryperson)(userAccountControl:AND:524288)) samaccountname -list if ($unconstrainedUsers) { Write-Host [紧急] 发现无约束委派用户账户风险极高 -ForegroundColor Red $unconstrainedUsers # 建议立即审查并清除这些账户的委派标志或删除不必要的账户。 } # 3. 查找约束委派配置 $constrainedAccounts .\AdFind.exe -f (msDS-AllowedToDelegateTo*) samaccountname msDS-AllowedToDelegateTo -list if ($constrainedAccounts) { Write-Host [中危] 发现约束委派配置请审查 -ForegroundColor Yellow $constrainedAccounts | Format-List # 建议审查每个账户的msDS-AllowedToDelegateTo列表确保只包含必要且最低权限的服务。 }运行此类审计脚本应成为季度或半年安全巡检的固定动作。对于发现的异常配置需联合业务部门确认必要性并遵循“最小权限”原则进行整改。4.2 实时监控与告警检测阶段攻击者的AdFind查询和委派利用行为会在AD和主机上留下日志。关键在于正确启用并解读这些日志。关键监控点域控制器安全日志事件ID4662对AD对象的操作。需要关注Object Type是%{bf967aa5-0de6-11d0-a285-00aa003049e2}即domainDNS对象或特定OU的访问。攻击者大规模枚举用户/计算机时会触发大量此类日志。但正常管理操作也会产生需建立基线。5145网络共享对象被检查。AdFind查询可能会触发。4672分配特殊权限。与权限提升相关。4769Kerberos服务票据请求。关注Ticket Options包含0x40810000无约束委派的请求以及来自非常规客户端的Service NameSPN请求。Sysmon日志如果已部署事件ID 1进程创建。监控AdFind.exe进程的创建其父进程可能是cmd、powershell或渗透测试框架。事件ID 10进程访问。如果攻击者尝试读取lsass进程内存用Mimikatz抓取委派缓存的TGT会触发此事件。事件ID 22DNS查询。AdFind查询可能会产生对域控的DNS查询。SIEM规则示例在SIEM如Splunk, Elastic SIEM中可以构建如下关联规则规则1异常LDAP查询在短时间内如5分钟来自同一源IP非域控、非IT管理终端的4662事件数量超过阈值如1000次且操作类型为“读取属性”。规则2可疑进程链进程创建事件中出现AdFind.exe且其父进程是powershell.exe或cmd.exe而该powershell/cmd又来自一个非常规路径或由非管理员用户启动。规则3委派票据异常安全日志中4769事件Ticket Options包含0x40810000无约束委派标志且Client Address不是已知的服务器IP。实操心得纯粹的日志监控很容易产生误报。最有效的方法是结合“资产清册”和“行为基线”。例如事先记录哪些管理终端有权限进行AD查询哪些服务器应该配置了委派。任何偏离这个“白名单”或“已知正常模式”的行为都值得高优先级调查。同时在关键服务器尤其是域控和疑似配置委派的服务器上部署EDR/AV监控对lsass进程的访问尝试这是捕捉凭证窃取和票据转储的最后一道防线。4.3 架构与权限最佳实践预防阶段淘汰无约束委派这是最高优先级的行动。对所有已发现的无约束委派账户进行评估。对于Windows Server 2003以后的应用应使用约束委派或基于资源的约束委派替代。如果业务上确实无法更改则必须将这些主机视为“Tier 0”资产最高安全等级进行严格隔离和监控。最小化约束委派审查所有msDS-AllowedToDelegateTo列表确保只包含业务绝对必需的后端服务SPN且这些服务本身也进行了安全加固。服务账户管理为需要委派的服务使用独立的、强密码的服务账户gMSA-组托管服务账户是更佳选择并确保这些账户不属于任何高权限组。定期轮换其密码。实施网络分段将域控制器、配置了委派的服务、高价值服务器划分到不同的网络区域限制它们之间的直接通信强制通过跳板机进行管理。这可以增加攻击者横向移动的难度。启用Protected Users组对于所有高权限账户尤其是域管理员将其加入“Protected Users”安全组。这会强制使用Kerberos AES加密并阻止使用NTLM认证、无约束/约束委派等较弱的特性能从源头上防御多种委派攻击和凭证盗窃。5. 实战演练与问题排查实录理论结合实战才能融会贯通。这里模拟一个从发现到防御的完整场景。场景在一次授权的内部渗透测试中我们获得了一个域普通用户john.doe的权限。步骤1初始侦察我们登录到一台已加入域的跳板机上传AdFind。# 快速摸清域结构 AdFind -rootdse # 发现域名为corp.com域控为DC01.corp.com # 枚举高权限组用户 AdFind -f ((objectcategorygroup)(nameDomain Admins)) member # 发现域管理员是admin.administrator # 枚举所有计算机寻找可能的初始目标 AdFind -f objectcategorycomputer name operatingsystem | findstr /i server # 发现一台名为IIS01的服务器运行Windows Server 2019步骤2狩猎委派# 查找无约束委派计算机 AdFind -f ((objectcategorycomputer)(userAccountControl:AND:524288)) name # 输出IIS01太好了IIS01配置了无约束委派。这是一个典型的旧版IIS服务器配置。步骤3获取IIS01的访问权我们尝试对IIS01进行端口扫描用PowerShell或上传的轻量工具发现开放了80Web、5985WinRM端口。通过Web漏洞比如一个简单的文件上传或对已知的本地管理员密码进行喷洒假设内网存在密码复用我们成功在IIS01上获得了命令执行权限。步骤4捕获票据在IIS01上我们运行Mimikatz或更隐蔽的Rubeus来监控票据。# 使用Rubeus监控需要管理员权限 Rubeus.exe monitor /interval:5 /filteruser:DC01$我们等待域管理员或其他高权限账户访问IIS01上的服务可能是Web应用也可能是管理员进行维护。一旦捕获到域控制器计算机账户DC01$或其他高权限用户的TGT攻击就成功了。步骤5权限提升与防御响应模拟假设我们捕获到了DC01$的TGT。现在我们可以用这个TGT向域控制器请求任何服务的票据从而完全控制域。但在真实的蓝队演练中此时防御体系应该已经告警。蓝队视角的问题排查告警触发SIEM规则“异常LDAP查询”可能早在步骤1就告警因为john.doe这个销售部门的账户突然进行了大量的AD枚举。但此时可能是误报需要调查。深度调查安全分析师查看相关日志。发现来自john.doe账户的LDAP查询使用了AdFind工具特征。发现IIS01服务器上出现了异常进程如Mimikatz或Rubeus触发了EDR告警。发现从IIS01向域控制器发起的、使用了无约束委派标志的Kerberos请求事件ID 4769且请求用户是DC01$。响应与遏制立即隔离将IIS01服务器从网络中断开并冻结john.doe的账户。取证分析对IIS01进行内存和磁盘取证确认攻击者使用的工具、留下的后门和窃取的凭证。根源修复审查并清除IIS01计算机账户的无约束委派标志。检查IIS01上存在的漏洞文件上传、弱密码并进行修补。审查john.doe账户的失陷原因可能是钓鱼邮件并开展全员安全意识培训。考虑将域管理员账户加入“Protected Users”组并实施LAPS本地管理员密码解决方案来管理服务器本地管理员密码防止密码喷洒。常见问题速查表问题现象可能原因排查步骤与解决方案AdFind查询返回空或错误1. 当前用户权限不足。2. 网络不通或防火墙阻止LDAP端口389/636。3. 工具路径或语法错误。1. 使用whoami /all确认权限尝试获取更高权限。2. 使用telnet DC_IP 389测试连通性。3. 使用AdFind -h查看帮助检查命令语法尤其是-b基础DN是否正确。发现大量无约束委派计算机历史遗留配置或旧版应用要求。1. 建立清单联系业务负责人确认必要性。2. 制定迁移计划改用约束委派或基于资源的约束委派。3. 对无法迁移的主机实施严格网络隔离和增强监控。SIEM中LDAP查询告警泛滥正常的管理活动如账号同步、监控软件也会产生大量查询。1. 建立行为基线识别并白名单合法的管理终端、监控服务器IP和用于查询的服务账户。2. 优化规则将告警阈值与基线结合或增加过滤条件如排除特定OU的查询。3. 关联其他可疑事件如告警前后有漏洞利用或异常登录尝试。无法确定委派是否被利用日志不清晰或攻击者使用了加密/混淆技术。1. 检查疑似被利用主机如IIS01上的Kerberos票据缓存需在攻击发生不久后取证。2. 检查域控制器上来自该主机的4769事件寻找可疑的Service Name或来自高权限账户的请求。3. 回顾网络流量记录寻找主机间非常规的Kerberos或SMB流量。内网安全是一场持续的猫鼠游戏。工具本身无善恶AdFind在管理员手中是审计利器在攻击者手中则是侦察尖刀。防御的核心不在于封禁某一个工具而在于构建一个基于“零信任”和“最小权限”的纵深防御体系并配以有效的监控和响应能力。定期用攻击者的视角审视自己的AD环境使用像AdFind这样的工具进行自我攻击面评估及时清理像无约束委派这样的“历史债务”才能让内网真正固若金汤。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
