企业官网建设流程全解析

1. 域环境信息采集：一次授权攻防演练的起点

我最早接触域渗透时，以为拿下域管的路径就是不停地打漏洞、弹 shell。做了几个真实的授权演练项目之后才发现，绝大多数时间花在“信息采集”上，真正用到高危漏洞的机会反而很少。说得直白一点：域环境里的信息采集做得好不好，直接决定后续利用的成与败。

这篇文章就以“域环境信息采集与利用”为主线，从前期确认、常用工具、精化 Enumeration 技巧、落地利用思路到坑点排查，把我自己趟过的一条完整链路梳理一遍。面向的读者是已经入门渗透、想系统理解域信息收集的同行，也欢迎防守侧的工程师看过来——至少知道攻击者会从哪些角度观察你的 AD 环境。

需要先打个底：以下所有内容都默认在合法授权的前提下进行，比如公司内部的攻防演练、红队评估，或者是自家的实验环境。未经授权去对任何生产系统做探测，性质就不一样了，这里不展开，但这是底线。

域渗透里的信息采集，核心目标其实非常集中：搞清楚域内到底有哪些机器、哪些用户、哪些服务、谁有高权限，以及这些元素之间怎么关联。AD（Active Directory）本身就是一台巨大的信息数据库，攻击者要做的并不是暴力破解整个数据库，而是找到正确的查询接口，以合法的身份，把里面最有价值的字段挖掘出来。

2. 信息采集前的环境确认与身份定位

2.1 站在哪一阶段，决定你采集什么

域渗透的信息采集按阶段可以分为三类：

• 初始立足点之前：此时通常只有一个普通主机权限，或者只有一个Web应用的漏洞入口，需要先判断当前机器是否在域内、域名叫什么、当前用户权限有多大。
• 获得域内普通用户权限之后：此时已经有一段相对可信的凭据，可以开始做系统性的域内枚举，包括用户、组、机器、策略、共享等。
• 获得某台服务器权限之后：此时目标从“找到普通用户”升级为“找到高权限目标”，采集重点变成管理员会话、服务账号、组策略对象，以及各种域管理相关的线索。

不同阶段，你的查询方式和工具优先级都是有差异的。上来直接跑一大圈扫描器，往往会把流量打得满天飞，反倒容易触发告警。

2.2 先回答三个基础问题

在开始任何采集动作之前，我习惯先回答三个问题：

1. 当前机器是否加入域？
2. 当前用户是不是域用户？
3. 当前主机在域内的角色是什么？

拿 Windows 环境举例，命令其实很朴素：

systeminfo # 观察“域”字段，如果显示 WORKGROUP，说明没加域 # 如果显示一个DNS域名，比如 corp.example.com，说明已加域 whoami /all # 看用户 SID，判断是本地账户还是域账户 # 域账户 SID 的格式类似 S-1-5-21-xxxxx-xxxxx-xxxxx-1000 net config workstation # 查看当前工作站所属域

这三个命令虽然老，但信息密度极高。systeminfo 还带出主机名、系统版本、补丁级别，这些是后续判断漏洞利用路径的基础信息。

如果你发现当前权限是本地管理员，但是机器加域了，那后面就能走runas /netonly或注入域凭据的路线；如果你只是普通域用户，那就老老实实从枚举和合法查询开始，不要急着去尝试高风险的漏洞利用。

2.3 身份与凭据管理：采集过程的第一纪律

这一步很多人忽略，但我要专门提醒：你在域环境里的每一次查询，都会在域控制器和客户端的日志里留下记录。

在实际攻防演练里，更多的 IDS 产品会把不正常的 LDAP 查询、批量枚举行为标成可疑事件。所以刚开始采集时，尽量用“看起来像一个正常用户”的方式去做查询，减少批量爆破和超大范围枚举，避免还没看到全貌就被踢出网络。

我自己实战中的做法是：

• 优先级从日志噪音小的操作开始：DNS 查询 > SMB 共享枚举 > LDAP 常规查询 > 事件日志查询。
• 每条命令都要想清楚“这条查询会不会产生大量日志记录”，必要的查询还是要做，但不要反复做同样的事。
• 如果手头有多个低权限账号，尽量避免一律用同一个账号频繁跨主机认证，分散认证行为，降低特征聚集。

3. 域内信息采集的核心手段与工具

3.1 用 DNS 查询把域的情况先摸一遍

很多人把 DNS 查询排在很后面，其实它的噪音很低，而且信息量被严重低估。在域环境里，DNS 记录能直接反映域内有哪些关键服务器、文件服务器、Web服务器、打印服务器等。

我用得比较顺手的方法是，先找到域控制器的地址，顺手取一次区域传输：

nslookup > set type=SOA > corp.example.com > set type=NS > corp.example.com > server 10.10.1.10 > ls -d corp.example.com

区域传输在多数配置里都是被禁止的，但如果成功了，你能直接拿到一份完整的 DNS 记录列表，效率极高。

区域传输失败也没关系，可以退一步做常规解析和字典查询，把常见的命名模式跑一遍：dc01、fileserver、sqlcls、mail、vpn等。这种做法不需要任何域凭据，只要你分配的 DNS 服务器允许普通查询就行。

3.2 SMB 空会话与匿名共享枚举

在早期的 Windows 版本或者配置不当的环境里，空会话依然可以携带少量信息回来。即便是现代的域环境，针对共享名称的匿名枚举还常常关不严。

惯用方式是结合工具做 SMB 空会话探测，比如：

smbclient -L //10.10.1.10 -N crackmapexec smb 10.10.1.0/24 -u '' -p '' --shares

这个阶段可以搞清楚几件事：

• 域内哪些机器开放了 SMB；
• 开放的共享里有没有“可读”的备份盘、软件分发目录、配置脚本；
• 主机名与 IP 的对应关系，顺带能推断出每台机器的角色。

我踩过的坑是：探测到敏感共享名，比如backup$，兴奋地扑过去，发现权限其实无关紧要，反而低估了真正开放的生产文件服务器。共享枚举只当作“外围观察”，不要指望它能直接捞到域管哈希。

3.3 LDAP 查询：域信息的“富矿”

进入域内之后，最有高价值、最连贯的信息源就是 LDAP。域内的一切对象基本都在 LDAP 里注册，查询接口开放程度通常也不低。以图形化工具 BloodHound 采集器 SharpHound 为代表，LDAP 数据收集是目前域渗透信息采集的主流方式。

我比较常用的是在自己控制的域内机器上执行：

# 用 AD 模块查询域控制器 Get-ADDomainController -Filter * # 枚举所有用户 Get-ADUser -Filter * -Properties samAccountName,description,memberOf,servicePrincipalName,lastLogonTimestamp # 枚举所有计算机 Get-ADComputer -Filter * -Properties operatingSystem,servicePrincipalName,lastLogonTimestamp # 枚举所有域管理员组成员 Get-ADGroupMember -Identity "Domain Admins" -Recursive

如果你的环境没有 AD 模块，纯 .NET 的目录服务接口也能做：

([adsi]"LDAP://corp.example.com").distinguishedName

或者直接用 C# 脚本调用System.DirectoryServices做查询，这种方式依赖更少，兼容性更好。只是写起来相对麻烦，所以通常还是建议在装了 RSAT 的机器上跑。

3.4 BloodHound：把关系画成图

我承认 BloodHound 已经成为域渗透信息采集的事实标准。它做的不是简单的“搜索一下有什么”，而是把用户、组、计算机、会话、ACL、GPO 等对象之间的关系提取出来，形成完整的关系图谱。

使用方式基本是两条线：

• 部署 SharpHound 采集器，在域内机器上执行采集；
• 把采集结果上传到 BloodHound GUI，进行分析。

SharpHound 支持多种采集模式，日常我会用：

# 采集全部信息 SharpHound.exe --CollectionMethods All --OutputDirectory .\output # 仅采集活跃会话 SharpHound.exe --CollectionMethods Session --Loop --LoopDuration 00:10:00

会话采集往往是在职权限提炼的关键，因为域内会有大量的用户会话散落在各种服务器上。你一旦拿到某一台机器的 SYSTEM 权限，就可能通过会话信息联系到高权限用户的令牌，完成横向移动。这就是“会话收割机”的价值。

BloodHound 的自定义查询值得花时间研究，比如“找到能从普通用户路径走向域管的所有路径”，这类查询在实战中的命中率远比瞎转高。

3.5 SPN 探测：Kerberos 凭据的密码学入口

服务主体名称（SPN）算是信息采集中一个比较“刃口”上的点。AD 里每个注册了 SPN 的账号，意味着这台机器或服务账号有一个可用于 Kerberos 换取服务票据的身份，而服务票据的加密方式又直接关系到离线爆破的可能。

枚举 SPN 的常见命令：

setspn -Q */*

输出结果中重点关注：

• 注册在域管理员组账号下的 SPN；
• 注册在普通服务账号下但运行权限很高的 SPN；
• SQL Server、HTTP、MSSQL、Exchange 等常用服务类型的 SPN。

SPN 的意义不在于“发现存在某种服务”，而在于为后续的 Kerberos 票据请求和离线爆破准备目标池。这一步不需要特权账号，普通域用户就可以请求所需的服务票据。

3.6 组策略与脚本中的“遗留秘密”

域环境里的 GPO 和登录脚本藏了大量信息。最常见的是管理员把脚本存放在 SYSVOL 共享中，而这些脚本对域内所有用户可读。

检查 SYSVOL 时重点关注：

\\corp.example.com\SYSVOL\corp.example.com\Policies\

里面每个 GUID 目录对应一条 GPO，我重点关注：

• 含有 “password”、“pass”、“user”、“admin”、“connect”、“copy” 等关键词的脚本；
• 开机脚本、登录脚本、组策略首选项中的 XML 文件；
• 部署相关 BAT / PS1 / VBS 文件。

当年有一个经典问题：Windows Server 2012 以前，GPP（Group Policy Preferences）会把加密后的密码直接放进 SYSVOL 的一个 XML 文件里，而解开这个加密的密钥是公开的。这就意味着任何能读取 SYSVOL 的人都能解出本地管理员密码。虽然后续版本已修复，但历史遗留的环境中仍能偶尔捞到。

3.7 共享文件中的“蓄意 / 无意”暴露

信息采集不能只盯着 AD 对象，还要关注实际的业务数据。域内文件服务器、个人主目录、部门共享中，经常会出现：

• 部署文档里记录的连接字符串（内含数据库密码）；
• 运维人员的密码本（这个真是见过太多次）；
• 用户导出的联系人列表、企业通讯录；
• 各种备份文件，包括未加密的磁盘镜像。

我一般先枚举出所有可读共享，再针对高价值关键字做一轮文件内容检索。别小看这一步，攻击链往往就是从一段连接字符串里的某个口令延展到数据库服务器，再通过数据库服务器上的任务计划把权限抬到域管。

利用工具在 SMB 上撒网浏览，实际上就是在做同一件事，只是效率更高。

4. 精准枚举：普通域用户视角下的关键信息

4.1 用户属性里那些“脏宝贝”

对普通域用户来说，AD 中几乎所有用户对象的属性都只能读不能写，但这已经足够。查询用户属性时，下面这几个字段一定要带上：

• description：很多管理员习惯在描述里写“张三-财务部主管-电话xxxx”，甚至直接写“备份管理员”，这类描述是定位高价值账号的指南针。
• memberOf：用户属于哪些组，尤其注意嵌套组，比如用户属于“财务组”，财务组又属于“域管理组”。
• servicePrincipalName：这个用户有没有注册服务。
• lastLogonTimestamp：判断账号是否活跃，优先把资源花在活跃账号上。
• msDS-AllowedToActOnBehalfOfOtherIdentity：这是一个很关键的属性，涉及基于资源的约束委派，如果配置不当，低权限用户可以拿到特定计算机的权限。

有些管理员还会把部门、职位、办公地点填得特别详细。这些字段对横向移动的价值不直接，但对钓鱼邮件构造、密码重置迷惑度提升有很大帮助。

4.2 域组的“嵌套”才是真正的权限纵深

直接看“域管理员组成员”是最简单的一句话，但真正的权限分布往往不在显眼的组里。例如：

• Account Operators组可以重置普通用户密码，也能修改组内成员；
• Server Operators组可以登录域控制器执行维护任务，在旧版本环境中还拥有部分系统权限；
• Backup Operators组能够绕过大部分 ACL 去读取文件，包括 SAM 数据库；
• Print Operators组在某些配置不佳的情况下可以加载驱动、执行系统级操作。

所以做组成员枚举时，我会递归查询，也就是不仅看直接成员，还要看成员所在的组各自属于哪些组。BloodHound 对这部分的图形化展示非常直观，但命令行查询也不能放弃，因为有时候导数据不方便。

递归查组的 PowerShell / .NET 写法很简单，可以用Get-ADGroupMember -Recursive直接拿全量结果。

4.3 关于“machine account”和自动登录凭据

域内每台计算机都有自己的机器账号，机器账号的密码由系统自动管理，通常每 30 天更新一次。但也存在不少特例：

• 某些老旧系统支持 WDigest，明文口令会以可解密的方式保存在内存里；
• 管理员手动把机器账号的密码固定下来；
• 域内允许非约束委派，机器账号和用户账号的 TGT 一起缓存在内存中。

机器账号的信息采集重点是msDS-MachineAccountQuota，这个属性决定一个普通用户能往域里加多少台机器。默认值是 10，如果配置不当，攻击者可能通过添加一个新机器账号来获得特定服务的访问能力。

4.4 会话信息：域里“谁在哪台机器上登录过”

前面提到 BloodHound 的会话采集，这里再说深一点。会话采集的本质是通过查询 NetWkstaUserEnum 和 NetSessionEnum，枚举出“当前有哪些用户在这台机器上登录”。

NetAPI 查询可能需要管理员权限，但有时候普通用户也能拿回部分信息。关键场景：

• 拿到一台文件服务器权限，查会话列表，发现域管账号的活跃会话，就可以考虑用 Token 窃取、SID 历史记录等方式尝试向该用户发起的进程注入。
• 拿到某台 Web 服务器的权限，查共享会话，可能发现运维人员正在里面做部署。

会话信息时效性极强，所以要多次采集，比如间隔 5 到 10 分钟采一次，积累时间段之后再去分析，而不是只做一次性快照。

5. 从“采集”到“利用”的精炼路线

5.1 围绕目标的反向推导

纯采集不做整理，等于白采。我习惯先设定一个目标，比如“我要从当前普通用户走到域管”，然后反向推导需要的条件：

• 域管登录过哪台机器？我的当前用户对这机器有没有写权限？
• 有没有某个域管姓名的服务账号？它的 SPN 是否可爆破？
• 当前用户能不能通过 GPO 部署任务计划？
• 有没有配置委派，可以让我冒充某个高权限用户？

把这些条件列出来，再回头在采集结果里找对应证据。这套思路比盲目用 BloodHound 跑“Shortest Path”要扎实得多，因为 BloodHound 给出的最短路径有时候并不符合现实准入规则。

5.2 SPN 爆破的落地场景

SPN 爆破是最具代表性的“采集即利用”场景。拿到 SPN 列表之后，先用普通域用户身份向 KDC 申请服务票据，拿到票据再去本地爆破。

常用的系统工具：

impacket-GetUserSPNs 域/用户:密码 -dc-ip 10.10.1.10 -request

收到 TGS 票据后本地用 Hashcat 模式 13100 进行离线跑：

hashcat -m 13100 tgs.txt wordlist.txt --rules

如果服务账号密码强度够，爆破机会不大；但域环境里很多服务账号是运维手填的，完全没有随机密码策略，爆破成功率不低。这里要提醒一点：请求票据本身是正常 Kerberos 行为，日志噪音低，但随后如果同一个账号 ID 反复请求多个不同 SPN 的票据，还是会被有心人观察到规律。

5.3 委派滥用：从信息字段跳到控制权

AD 中的 Kerberos 委派，特别是基于资源的约束委派，是信息采集成果的高价值转化点。采集阶段需要重点确认：

• 哪些账号启用了非约束委派（Unconstrained Delegation）；
• 哪些账号启用了约束委派（Constrained Delegation）；
• 普通计算机账号是否可以写入msDS-AllowedToActOnBehalfOfOtherIdentity属性。

如果一台机器是非约束委派，用户只要带着 TGT 访问这台机器，机器就能把这个 TGT 存到内存里。用提权后的 SYSTEM 权限导出内存密钥，就能继续冒充该用户获得服务。信息采集阶段要做的就是先找到这些机器，利用的价值极大。

针对约束委派，获取高价值用户列表之后，还需要确认该用户可以“代表谁访问什么服务”。两个方向都依赖采集阶段拿到准确的 SPN 与 ACL 关系。

5.4 普通用户的密码喷洒：让采集结果“转动”起来

密码喷洒是不需要太多采集成果的横向移动方式，但它和质量信息采集相互配合才有效果：

• 先采集到域内所有有效用户名（或至少一部分活跃用户）；
• 用统一的少量密码（如季节+年份，公司名+年份等）对全部用户尝试登录；
• 每次尝试间隔不要过密，防止触发账号锁定策略。

密码喷洒中用户名列表的质量很重要。比如 LDAP 查询过滤掉禁用账号后，再用同一批密码跑多轮，成功率会高不少。千万不要拿着几万个用户名去跑爆破，那样只是自爆流量特征。

5.5 组策略对象与 ACL 的“隐形控制面”

GPO 不只藏脚本，GPO 的 ACL 配置本身就是权限面。攻击者一旦能对某条 GPO 做修改，就能通过组策略下发任务计划、启动脚本，进而控制范围内所有计算机。

采集阶段把每条 GPO 的链接顺序、安全筛选、委派情况梳理出来，再对比当前用户的写权限，就可以判断有没有 GPO 劫持的可能。

ACL 找路径时，简单的做法是枚举关键对象（域管组、域管用户、域控制器 OU、GPO 对象）的nTSecurityDescriptor，看当前用户是否拥有GenericWrite、GenericAll、WriteDACL之类的权限。用 BloodHound 输出 ACL 路径时，尽量把 edge filter 调到只显示可利用边，避免图形杂乱。

6. 常见问题与排查技巧实录

6.1 LDAP 查询返回结果为空怎么办

最典型的坑是凭据格式不对，或者 AD 模块未加载。排查顺序：

• whoami /upn确认当前凭据的 UPN 是否和域匹配；
• Get-ADDomain是否可以正常拿到域信息，如果这里就报“找不到域控制器”，检查网络连通和 DNS 优先级；
• 用nltest /dsgetdc:corp.example.com确认域控制器的定位是否正常。

LDAP 空结果也可能是过滤语法错误。我习惯先在 PowerShell 里临时绑定一个用户显式跑一次：

$cred = New-Object System.Management.Automation.PSCredential("corp\user", $pass) Get-ADUser -Credential $cred -Filter *

这样可以快速把问题锁定在“认证”还是“查询”上。

6.2 BloodHound 采集一半断连或数据缺失

SharpHound 采集目标机的健康状态差异很大。经常看到的情况是：左侧会话列表一大堆，但右侧很多机器标记为“未采集”。处理方案：

• 检查防火墙是否放行RPC、SMB、LDAP端口；
• 使用-Stealth采集模式，少一点噪音；
• 多次循环采集，再做合并，而不是一次性开高吞吐采集。

如果你拿到的是已经存在几年的老环境，可能还夹杂着 IPv6 和旧 SID 的兼容问题。优先确认当前域功能级别，老环境通常会多一些意外小插曲。

6.3 SPN 爆破跑的密码出不来

爆破不出密码的原因不一定就是密码强度高，也可能是：

• 忽略了 Kerberoasting 需要的是 TGS-REP 的加密数据段，而不是整个 TGS 包；
• Hashcat 的 mode 没匹配对（AES 加密和 RC4 加密类型不一样）；
• 服务账号同时开启了多重加密类型，抓包时拿到的是 AES 加密票据，目标工具不支持。

实操里建议先把抓到的票据文件格式检查一遍，看是$krb5tgs$23$*还是$krb5tgs$17$，依据加密类型选择对应的模式和参数，再重新跑。

6.4 账号锁定策略的“翻车现场”

踩过的最惨烈的坑：连续喷了一百多次密码，目标账号直接锁定，触发了域控上的告警，接下来的半天都在处理应急响应。

经验提醒：

• 先查询域的锁定阈值，比如：

net accounts /domain

• 每次尝试间隔至少控制在 15 分钟以上，或者直接使用时间间隔可调的工具；
• 优先针对不常检查的账号（如服务账号、测试账号）做喷洒，降低对真实员工账号的打扰；

如果命中锁定阈值，也没有侥幸，只能等锁定策略超时结束，或者申请管理员解除锁定。所以密码喷洒前务必评估对可用性的影响。

6.5 会话枚举拿不到数据

会话枚举拿不到数据的概率挺高，尤其是目标机器开了防火墙或账号权限不够时。NetAPI 枚举需要一定权限，很多项目环境里的普通域用户只能看到有限会话。

这时候不要死扛，改动策略：

• 换一个角色视角，比如用本机管理员账号再去枚举；
• 用改进版工具或上下文传入凭据，把枚举行为伪装成正常管理操作；
• 将枚举改为“会话收集”模式，运行多次以后再合并结果。

6.6 工具执行被 AMSI / Defender 干掉

这个年代跑免杀件似乎成了基本功，但我的建议是：域信息采集阶段尽量不要一上来就追求免杀绕过，因为采集动作本身并不算高危攻击载荷，系统对信息查询的敏感度低于明晃晃的注入工具。

如果某些工具确实被拦截，考虑：

• 使用原生 Windows 命令和 PowerShell 组合（例如Get-ADUser、dsquery、net group）；
• 使用 .NET 在线编译的方式加载关键代码；
• 分拆成多个小任务，避免一个大文件集中弹出风险判定。

重点关注工具落盘的位置和执行方式，能显著减少与终端防护“硬碰硬”的频率。

6.7 采集数据太多反而迷失

我见过很多同行把 BloodHound 采集的数据导出来，结果条目太多，不知道从哪里下手。处理思路是用“过滤-排序-锁定”三步骤：

• 过滤掉禁用账号、过期账号、非活跃 90 天以上的账号；
• 按组成员数、SPN 注册条数、最近登录时间排序；
• 锁定排名前 20 的目标做深入查询，初始范围就定在这些人身上。

任何一个大型 AD 环境里都可能有几千个账号，高质量信息采集不是把表全部拉出来，而是在尽可能少打扰的前提下，找到“能最快拿到权限”的关键少数。

7. 防守侧视角：信息采集给我们的启发

这套信息收集和利用过程并不是攻击者专属，蓝队同样可以沿相同线索做自检。我在做内部防御评估的时候，通常会从信息采集视角反向做一遍：

• 检查 SPN 列表，把所有可以 Kerberoast 的可控对象清理或改密；
• 检查域管组成员，特别是嵌套组，把长期不用的高权限成员移除；
• 检查 GPO 的 ACL，确保没有普通用户可以修改管理组的 GPO；
• 检查机器账号的数量与新增情况，看是否有人悄悄加机器；
• 对域内“敏感属性”的读取行为配置告警；
• 定期/不定时用 BloodHound 的方式自查路径，找到可控路径再针对路径做改造。

信息采集对防守方来说同样是一面镜子。与其坐等攻击者交报告，不如先站在同一视角跑一遍，把明显敞开的口袋先缝上。

实战里我经常说一句话：**在一个域环境里，认清自己比认出敌人更重要。**所有高级攻击的第一步都不是砸门，而是观察。你也一样，拿到一台机器，先不急着提权，多看、多问、多记，弄清楚这个域的脾气，后面的事情会顺很多。

我个人在实际操作中的体会是：域渗透里的信息采集没有一招制敌的“神器”，无非是几千条 LDAP 查询、几十个会话枚举、几百条 SPN 记录里，找到那么一两个被忽略的细节，然后顺着它走到终点。耐心，永远是这一行的基本功。