企业官网建设流程全解析

接到一个授权范围内的内网测试任务，拿到一台Windows主机的初步权限之后，我做的第一件事不是急着往域控冲，而是把这台机器上上下下摸一遍。信息收集做到位，后面少走三天弯路。这句话我在带新人的时候反复讲，它是很多测试流程的分水岭。这篇就聊聊Windows系统下目标信息收集这件事，从命令到思路，从细节到坑，都是实际测试中踩过的、验证过的经验。

信息收集这个词听起来宽泛，但在Windows内网场景下，它是有明确边界的：系统信息、用户信息、网络信息、凭据信息、敏感文件，就这几大类。把这些维度摸清楚，你对这台主机的画像就基本完整了。反过来，如果跳过这一步直接去提权、去横移，大概率会卡壳，甚至惊动防御体系。

1. 信息收集在内网渗透中的定位与价值

1.1 信息收集为什么决定测试成败

内网渗透测试里有一个不成文的经验：前期信息收集的质量，直接决定后期作战路径的顺畅程度。拿到主机权限后，如果盲目尝试提权、盲目跑漏洞脚本，最常见的结果是浪费大量时间在一些无关紧要的漏洞上，甚至因为频繁触发异常行为，被EDR记入告警。

我自己经历过一个典型的对比案例。某项目里，我们拿到一台Windows Server的普通用户权限，一开始团队里有人建议直接跑公开提权脚本。我没急着做，先花了一个晚上做信息收集。结果发现这台机器上安装了某业务软件，其服务是以LocalSystem权限运行的，而且服务指向的目录对普通用户可写。这比找系统漏洞提权简单太多了——直接替换服务启动路径，重启服务，权限到手。整个过程没有用任何公开exp，防御设备基本没有触发任何敏感规则。

这件事后来成了我给团队培训的经典案例。信息收集不只是“多看几条命令”，而是把系统当成一个整体去理解：它的角色是什么？谁在上面跑东西？它能触达到哪些资源？这些问题想清楚了，技术方案往往自己就浮出来了。

1.2 信息收集的两个层次：被动与主动

信息收集按交互方式可以分两个层次。被动层次不依赖与目标系统的直接交互，比如通过公开信息、已有日志、历史漏洞报告来推断目标可能的情况。主动层次则是真正在目标系统上执行查询、读取配置、枚举用户等操作。我们的目标是：先用被动信息建立初步判断，再通过主动信息去验证和补充。

实操中我见过太多人一拿到shell就狂敲命令，这实际上是在放大暴露面。正确做法是每执行一条命令前，心里先过一遍：这条命令能帮我验证什么假设？它能带来哪些不可替代的信息？如果答案是“可执行可不执行”，那就不要执行。“主动动作越少、越精准”是我给自己定的原则。

当然，被动与主动不是非此即彼。很多时候你通过被动信息锁定了几个关键问题，再通过主动信息精准验证，两条腿走路。这就是整个信息收集阶段的核心节奏。

2. Windows系统基础信息收集

2.1 系统版本与补丁情况

拿到shell后的第一条命令，我几乎永远是 systeminfo。它能一次性输出操作系统版本、系统类型、补丁号、硬件信息、网卡配置，是Windows信息收集的“开场白”。

systeminfo 输出里有一个容易被新手忽略的字段：“系统类型”，它标明了系统是x86还是x64。这个信息直接决定你后续携带的利用工具、注入DLL、Payload需要编译成哪种架构。如果你在一个x64系统上跑32位的提权模块，很多情况下会直接失败，而且还浪费一次暴露机会。

补丁信息同样关键。systeminfo 会把已安装的补丁一一罗列出来，这些KB编号和漏洞数据库比对，能快速圈定可能存在的已知漏洞。我习惯先把输出存到一个文件里，回头结合掌握的漏洞情报做筛查，而不是现场一条条看。

除了 systeminfo，还可以用 ver 命令快速确认系统版本号。但 ver 输出太简陋，只能当辅助。如果是在PowerShell环境，可以用 Get-ComputerInfo，它输出结构化对象，字段层级清晰，方便后续自动化处理。不过这条命令执行较慢，在低配服务器上有时会卡上几十秒。我的习惯是：先 systeminfo 拿基础信息，需要深挖版本细节的时候再上 Get-ComputerInfo。

2.2 环境变量与注册表配置解读

环境变量看起来不起眼，里面信息密度却很高。输入 set 或 Get-ChildItem Env: 就能看到当前进程的环境变量列表。重点看几个：

• COMPUTERNAME：当前机器名称
• USERNAME：当前登录用户名
• LOGONSERVER：登录服务器地址，如果它指向一个域名而非本机名，说明这台机器很可能是域环境的一部分
• TEMP / TMP：临时文件目录，有时候可以在这里发现其他用户遗留的临时文件

举个例子，一次测试中我在环境变量里看到了 LOGONSERVER 指向某内部域控主机名，Unexpectedly，这台机器看起来只是个普通业务服务器，实际却已经加入了域。顺着这条线，我优先去摸域信任关系，而不是纠结于本机提权。这就是环境变量带来的思路转折。

注册表则是另一座富矿。重点路径包括：

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion：确认精确的系统版本、Build号、安装日期
• HKLM\SYSTEM\CurrentControlSet\Services：列出系统服务，结合服务对应的ImagePath，可以判断哪些服务运行在高权限下
• HKCU\Software：当前用户安装的第三方软件配置，偶尔能找到硬编码的数据库口令或Token

注册表查询的命令不复杂，reg query "路径"。但注意一点：无差别扫注册表不仅慢，还容易触发安全产品的敏感操作告警。我通常只对已知有价值的关键路径做定点查询，带着问题去查，而不是漫无目的地翻。

3. 用户与权限信息收集

3.1 本地用户、组与当前权限

用户信息收集主要围绕 net 命令族展开。net user 能列出本地用户账户，net user 用户名 能查看指定用户的详细信息，net localgroup 列出用户组，net localgroup Administrators 查看管理员组成员。

这些输出能告诉你几个关键事实：系统上有哪些账户？哪些属于高权限组？有没有不属于常规命名规范的陌生账号？后者的重要性经常被忽视——如果发现一个你不认识的用户，需要高度警惕，它有可能是其他攻击者留下的后门账号，也有可能是很久之前的运维人员创建的残留账号。在报告中把这个现象标记出来，本身就是一项有价值的安全发现。

whoami /all 是我每台机器必跑的一条命令，它输出当前用户的完整SID、所属组列表、特权字符串。输出里有几个关键点要读明白：

• “组列表”里的 Mandatory Label 字段，High Mandatory Level 表示高完整性级别，说明当前进程是管理员权限；Medium Mandatory Level 说明是普通用户权限。这直接决定后续操作是走提权还是直接开展横向。
• “特权”列表里有 SeImpersonatePrivilege、SeAssignPrimaryTokenPrivilege 等条目。如果有 SeImpersonatePrivilege，即使只是普通用户，也意味着存在利用土豆类漏洞提权的可能。

读懂了这两个字段，主机当前的安全上下文就清晰了。很多新手把 whoami /all 的输出存在文件里就不管了，其实里面的MIL和特权信息才是真正的宝藏。

3.2 域环境下的信任关系与用户结构

如果主机已经加入域，用户枚举的重心就要从本地账户转向域账户和信任关系。net group "Domain Admins" /domain 能查询域管理员组成员；net group 用户名 /domain 能查看指定域用户的组关系。这些命令依赖当前会话对域控的查询权限，通常在工作组环境或本地权限不足时执行会报错，报错本身就是一种情报——说明当前主机与域控的通信可能有障碍。

域信任关系是另一个容易被忽略的点。nltest /domain_trusts 能列出当前域信任的其他域以及信任类型。如果存在跨域信任且信任方向可利用，这就是一条潜在的横向迁移路径。我见过一些企业内网，非核心业务域和核心业务域之间建立了双向信任，安全防护在边界上做得很足，但在内部信任关系上存在很大的利用空间。

做域信息收集时要注意节奏。很多查询会经由LDAP协议到达域控，而域控上的安全审计日志会记录这类查询。如果是红队场景，我会评估每次查询的情报密度，高价值的查询集中做完，低价值的查询直接砍掉；如果是防御规避能力较弱的授权渗透测试场景，则相对宽松一些。核心原则始终不变：用尽可能少的动作拿到尽可能多的关键情报。

4. 网络与连接信息收集

4.1 网络配置、路由与ARP缓存

网络信息收集要回答的核心问题只有一个：这台机器能触达哪些网段，正在和谁通信。

ipconfig /all 能列出全部网卡的IP、网关、DNS配置。一个常见发现是多网卡环境：业务网卡、备份网卡、带外管理网卡共存，不同网卡连接不同的安全域。如果某台机器配置了多个网段的网关，说明它可能在多个网络平面之间扮演桥梁角色。这种机器往往是横向移动的重要跳板。

route print 能看当前路由表，确认主机能触达哪些网段。它比单纯看网卡配置更实在，因为即使没有配置某网段的IP，只要存在路由条目，就说明该网段是可路由的。结合端口扫描、代理隧道的搭建判断，路由表是底层依据。

arp -a 查看ARP缓存，能列出最近与当前主机通信过的IP和MAC地址。MAC地址的前三字节对应OUI厂商编码，如果发现大量非网卡厂商的设备MAC，比如某交换机厂商的MAC频繁出现在内网段里，大概率意味着那是一台网络设备。这类信息对于绘制内网拓扑、定位核心交换机位置非常有帮助。

4.2 开放端口与进程对应分析

netstat -ano 能列出当前所有的TCP/UDP连接以及本机监听端口。配合 tasklist /svc 或 Get-Process 的PID信息，可以做端口到进程的映射。

分析监听端口时，我关注的优先级是这样的：

• 只有本机监听（0.0.0.0）还是仅本机回环（127.0.0.1），后者通常意味着服务只对本机开放，需要通过端口转发或隧道才能访问
• 端口对应的进程是不是常见的业务进程，比如数据库、中间件、RDP服务
• 有没有非标准的高端口在对外监听，这类端口背后可能藏着自定义服务，也可能是之前测试留下的后门

ESTABLISHED状态的连接信息同样重要。当前主机正在与哪些IP通信、走的是哪些端口，能够反映业务流量的走向。比如一台普通业务服务器频繁与某个IP的445端口建立连接，这可能意味着它挂载了远程共享，甚至可能存在SMB相关漏洞的可利用性。这些连接关系会在后续横向移动中成为重要线索。

5. 凭据与敏感文件收集

5.1 系统凭据位置与提取思路

Windows系统里积累了大量的凭据，它们分布在各种不同的位置。cmdkey /list 能列出当前用户保存的Windows凭据，包括远程桌面凭据、共享文件夹凭据等。很多运维为了方便，会把常用服务器的管理员密码保存在本机凭据管理器里，这对我们来说等于直接拿到了目标系统的钥匙。cmdkey /list 的执行不需要高权限，普通用户也行，而且很多安全产品不会对它产生高敏感告警。

计划任务和服务配置里也可能藏着秘密。schtasks /query /fo LIST /v 输出的计划任务定义中，如果任务运行账户不是系统账户，可能包含已配置的账户密码（虽然新版Windows会遮蔽部分字段，但历史版本的输出仍然可读）。系统服务的注册表项 ImagePath 字段，除了能确认服务对应的程序路径，还可以判断服务是否以 LocalSystem 权限运行——如果服务文件所在目录允许普通用户写入，替换文件即可实现提权。

浏览器存储的密码也是信息收集目标之一。Chrome和Edge的用户数据目录里都有Login Data文件，这是一个SQLite数据库，但密码字段经过DPAPI加密。在管理员权限下可以尝试调用DPAPI解密，获得明文口令。不过低权限下的收益不大，加上现代浏览器增加了更多防护，这一项我放在优先级靠后的位置。

5.2 文件系统搜索与配置信息挖掘

文件搜索是信息收集的重头戏，但也是最容易做过头的一步。无差别全盘搜索既浪费时间又放大暴露面，我的做法是“定向搜索、按需匹配”。

先划定几个高价值目录：用户桌面、下载目录、文档目录、管理员目录、各个Web站点根目录。再通过扩展名缩小范围：.txt、.docx、.xlsx、.ini、.conf、.config、.bak、.sql，后三类往往是配置和备份文件的重点。最后通过关键词精确匹配：password、passwd、pwd、token、secret、api_key、connectionstring 这些词。

IIS的 web.config、Apache的 httpd.conf、Nginx的 nginx.conf，这些配置文件里有时直接包含数据库连接字符串，账号口令写得很明白。TeamViewer 的配置文件中保存了机器ID和加密后的密码哈希，如果目标环境中大量使用TeamViewer运维，这类配置文件的发现价值就很高。各类中间件、消息队列的管理后台配置文件，也偶尔能看到明文口令。

搜索动作的“度”需要刻意控制。我一直强调：文件搜索的目的是找到真正影响安全态势的关键信息，而不是把目标机器上的所有文件都翻一遍。在结果中筛选高价值文件并聚焦分析，比扩大搜索范围更重要。

6. 工具链选择与实操组合演示

6.1 Windows自带命令组合实战

信息收集阶段，我优先使用Windows自带命令，而不是一上来就上各种扫描器和工具。原因很简单：自带命令免上传、免配置、特征少，而且大多数情况下足够完成信息收集的核心任务。

一次完整的信息收集命令序列，我的习惯是这样：

1. systeminfo，拿系统版本、补丁和基础配置
2. whoami /all，拿当前用户权限和特权信息
3. net user、net localgroup、net group /domain，拿用户和组关系
4. ipconfig /all、route print、arp -a，拿网络基础信息
5. netstat -ano，拿当前连接和监听端口
6. tasklist /svc，拿进程与服务对应关系
7. reg query，按需查询关键注册表路径
8. schtasks /query /fo LIST /v，检查计划任务

这套组合执行完，主机的系统、用户、网络、进程四个维度都有了比较完整的快照。我把每类输出保存到独立文件，作为后续分析的基础材料。执行顺序有时候也需要根据实际情况调整：比如发现系统极不稳定时，先跑网络连接和进程列表，如果系统崩了还能保留关键的横向线索；之后再慢慢补系统信息。

6.2 从原始输出到结构化情报

命令输出是原始信息，离情报还有一段距离。我在团队里一直推一套信息整理的规范：为每台目标主机建立一个独立的笔记目录，按类别存放输出文件，再附加半结构化的分析记录。

目录组织大致是这样：

• system.log：系统信息输出
• user.log：用户与权限输出
• network.log：网络信息输出
• process.log：进程与服务输出
• secret/：敏感文件和凭据相关发现的存放位置
• notes.md：分析记录，写清楚哪些是确证信息、哪些是待验证推断

“确证与推断分开标注”是我特别强调的一点。系统版本来自 systeminfo 输出，这是确证；通过主机名带业务标识字符推断它是域控，这是推断。之后要主动验证推断并更新标注。这个习惯能有效避免报告里出现“猜测当成事实”的毛病。

把原始输出整理成结构化情报还有一个额外的好处：如果测试周期长达一两周，中间换人接手或者隔几天再回看，这些笔记能让你快速恢复上下文。否则到时候面对一堆零散的命令输出，和没做信息收集没什么区别。

7. 常见问题、避坑指南与红队视角的平衡

7.1 权限不足下的信息收集变通

信息收集阶段最常见的困境是：当前权限很低，很多命令执行失败或输出不全。但低权限不等于什么都干不了，有几个变通思路值得掌握。

wmic 是低权限场景的利器。在很多默认配置里，wmic process list full 能被普通用户执行，它能列出所有进程的完整命令行参数。偶尔你会在这里看到意外收获——某个排障人员在命令行里带上了数据库密码，或者某个服务启动参数里写了Token。wmic 还可以查询用户列表、系统信息、补丁列表，能覆盖自带命令无法完成的大量信息收集任务。

另一个思路是查目录ACL。即使当前用户不是管理员，并不代表所有目录都对当前用户关闭。很多系统目录、应用目录的NTFS权限配置是松的，允许普通用户读取配置。手动检查几个常见目录的权限，往往能找到系统配置信息之外的额外收获。

还有一点经验：当你权限不足时，先不要急着提权。先把当前会话能读到的信息全部摸一遍，因为低权限会话本身也是“普通员工视角”，它的可读范围反而更接近业务真实情况。

7.2 降低暴露面的实操习惯

信息收集阶段虽然不像漏洞利用阶段那样会触发高敏告警，但在严密的防护体系里，大量高频命令仍然会被安全设备记录。几个实操习惯能明显降低暴露面：

• 命令执行的频率要控制。批量查询中间人为加几秒延迟，避免节奏太均匀，防止被识别为自动化脚本。
• 优先用系统自带命令，减少已知渗透工具带来的特征风险。很多安全产品对 mimikatz、psexec 这类工具的特征早已深度覆盖，能不落地就不落地。
• 关键信息拿到手后立刻分析，不要把同一个查询翻来覆去地跑。一次查询能解决的问题，绝不查第二次。
• 网络层面的主动扫描更要控制速率，避免触发流量检测设备的告警。

我发现很多新手在这个环节会下意识地“想多收集一些”，结果动作膨胀，暴露面变大。这个平衡感很重要：信息收集的目的是支撑决策，而不是把目标系统上的每一种信息都复制一份。每次执行命令前都在心里问一句“我要验证什么”，时间久了，动作自然就精准了。

7.3 信息收集结果的整理与报告输出

搞安全测试不只是技术活，交付质量也很重要。信息收集阶段的成果，后期会成为报告的重要组成部分。我自己习惯在信息收集阶段就同步做“痕迹记录”：哪条命令在哪个时间点执行、输出了什么关键信息、初步判断是什么、后续是否验证。

这份痕迹记录在写报告时价值巨大。它能支撑起目标系统的资产画像、攻击路径分析、风险点描述。比如，报告中写“该主机存在存储明文凭据的风险”，这句话需要足够的证据支撑——哪个文件、哪个进程、哪个注册表项，甚至恢复出来的明文片段。没有信息收集阶段的扎实记录，报告就缺乏说服力。

另外，报告里哪些信息属于“需要修复的高危问题”，哪些只是“被动的环境特征”，要分清楚。比如一个以LocalSystem运行的第三方服务目录可写，这是可修复的高危问题；主机恰好处于某个域信任关系中，这是需要从整体网络结构考量的问题。分类准确，客户才能有针对性的整改。

我自己在信息收集实践中最大的体会是：越是在容易兴奋的技术环节，越要保持流程上的克制。信息收集是信息的累积，更是忽略冗余信息、提炼关键情报的过程。把命令背后的“为什么”想明白了，执行的每一句才有意义。内网渗透这条路，基本功往往体现在信息收集这种看起来不炫技的环节上。希望这篇经验拆解能帮你少踩几个坑。