Windows主机信息收集实战指南：从外围探测到凭据提取的完整流程

做安全测试这几年，我越来越觉得“信息收集”四个字被严重低估了。很多人以为拿个扫描器扫一圈就是信息收集了，但真到了内网、真到了Windows主机上，决定你后续是顺利推进还是卡死半路的，往往是前期有没有把信息收全、收准。尤其是Windows主机信息收集，它不像打点那样刺激，但一套完整的收集思路，能让你少走好几个弯路。

这篇东西我不会讲怎么用某个商业软件点按钮，而是站在我自己实操的角度，把主机侧信息收集相关的知识点重新捋一遍。内容包括收集的整体思路、外围信息探查、主机内部核心配置读取、凭据与日志处理，以及最后的自动化整理和常见坑点。适合刚入门、想系统建立信息收集框架的安全测试人员，也适合做基线核查、应急响应的运维同学参考。内容全部基于授权测试环境下的常见实践，务必在合规前提下使用。

1. 信息收集的整体设计思路

1.1 先把收集范围分层，别一头扎进主机里

信息收集不是一个动作，而是一套流程。我习惯把它分成四个层次：目标确认、外围探测、入口分析与主机留存。

目标确认是搞清楚授权范围，哪些IP段能碰，哪些域名归属明确，这一步看似废话，但最容易被忽略。很多人上来就跑扫描器，结果扫到未授权的资产，后面全都是问题。我在每次测试前会先画一张简单的目标清单，标明IP、域名、责任人，再谈下一步。

外围探测是看目标的公网暴露面，比如开放端口、Web服务、证书信息、子域名等。这个过程可以借助搜索引擎、证书透明度日志、DNS记录等公开渠道完成，不需要触碰目标系统。主机信息收集则是在拿到内网权限或者明确授权的前提下，对Windows主机本身做系统层面的信息提取。最后是留存，把收集到的信息按资产、按用途归档，方便后续利用和报告输出。

这样分层的意义在于，每一层都有明确的产出物，不会乱。而且遇到问题时能快速定位是哪一层掉了链子，是DNS信息没查全，还是主机账户枚举漏了。

1.2 不同场景下的收集侧重点完全不同

同样叫信息收集，不同任务的侧重点差异很大。

红队攻防演练里，信息收集的目标是找最短路径。此时更关注的是入口服务、弱口令可能性、暴露的敏感文件、内网可达范围。合规基线核查则完全反过来，重点是补丁状态、账户策略、共享权限、审计策略是否开启，每一台机器都要能追溯到责任人。应急响应场景下，主机信息收集主要围绕“发生了什么”，需要看登录日志、进程启动时间、计划任务、自启动项、最近修改的文件，甚至要分析内存中的痕迹。

我遇到过不少朋友，不管什么场景都套同一套命令，结果在应急场景下被海量日志淹没，在红队场景下又因为没有重点而漏掉关键入口。所以我建议，动手之前先问自己三个问题：这次任务的核心目标是什么？拿到主机后最想确认的事情是什么？哪些信息是可以直接帮助下一步决策的？想清楚了再决定收集哪些数据。

1.3 信息收集的黄金原则：先宽后窄，先易后难

我实操时有个习惯，叫“先宽后窄，先易后难”。

先宽后窄的意思是，第一次收集尽量覆盖系统全貌，比如所有本地用户、所有服务、所有启动项、所有网络连接，哪怕有些信息暂时用不上，也要先记录下来。因为很多线索是串起来的，比如某个服务对应某个端口，某个端口对应某个进程，某个进程又对应某个启动项，单看任何一个都发现不了问题，串起来才能还原真实情况。

先易后难指的是优先收集无需特殊权限就能获取的信息。普通用户权限能查环境变量、当前用户信息、网络配置，管理员权限则能读SAM文件、抓Lsass进程内存、查看完整的事件日志。从低挂高，能拿到多少算多少，每一步都不白做。

这套原则最大的好处是不会漏东西。尤其是Windows主机信息收集，信息点非常碎，靠记忆很容易丢项，靠流程才能兜住。

2. 主机定位与外围端口探查

2.1 确认主机在网络中的身份：IP、域名、系统版本

拿到一台Windows主机，我第一步永远是确认它在网络中的身份。

先看IP配置。内网环境的IP能透露很多信息，比如10.10.x.x和192.168.x.x往往代表不同的网段归属，DNS后缀有时会直接暴露域名的内部命名规则。命令是 ipconfig /all，加 all 参数才能看到DNS服务器、DHCP服务器、主机名等完整信息。这里有个细节，多网卡机器一定要看全，有些机器同时连着办公网、服务器网、存储网，每块网卡都是一个潜在的攻击面。

然后是系统版本。直接输 systeminfo 能看到完整的操作系统版本、补丁编号、系统启动时间。这里有个小技巧：系统启动时间可以帮你判断这台机器是不是刚重启过。如果一台机器启动时间很近，说明可能刚打过补丁，已知漏洞利用的窗口变小了，后面的思路要相应调整。

主机名也能看出不少东西。虽然很多管理员会做主机名混淆，但仍有大量内网机器的主机名直接暴露了用途，比如FileServer-01、DC-02这类命名。收集主机名的同时，建议把所在域信息也记下来，echo %USERDOMAIN% 可以看到当前登录用户所在域名，判断机器是域成员还是独立主机。这一步决定后续是走域渗透思路还是本地提权思路。

2.2 端口与服务是主机的“门面”

端口扫描我习惯放在主机身份确认之后。刚进入内网的机器，最忌讳盲扫C段，动静大，还容易被发现。正确姿势是先扫目标主机的全端口，服务识别到位后再决定是否需要端口上的进一步操作。

Windows主机上常见的端口有135（RPC）、139（NetBIOS）、445（SMB）、3389（RDP）、5985/5986（WinRM），这些都是管理类和文件共享类服务。一旦这些端口暴露，基本等于告诉你可以尝试远程管理或者横向移动。Web类端口如80、443、8080也不能放过，很多内网系统喜欢把Web管理后台直接开在主机上。

扫描时我优先用Nmap的版本探测，nmap -sV -p- 目标IP 虽然慢，但对单台主机很值得。拿到服务版本后，端口背后的产品类型和已知漏洞倾向性就基本清晰了。扫描参数也有讲究，-sV是版本探测，-sC可以跑默认脚本，但脚本会发送大量探测报文，在敏感网络里慎用。

实操过程中要注意，Windows防火墙默认会拦截很多探测包，但135、139、445、3389这类端口在域环境中往往是放行的。如果你的扫描结果里这些端口全部关闭，先停下来想想是不是防火墙在干扰，别急着换工具，很多情况下换工具解决不了问题。

2.3 从NetBIOS和SMB信息看主机角色

Windows系统有几个独有的信息暴露渠道，最典型的是NetBIOS和SMB。

nbtstat -A 目标IP 可以通过NetBIOS名称服务获取机器名、所在工作组/域、已登录用户等信息。这是早期内网信息收集中非常经典的手法，即使到今天，很多Windows机器仍然默认开启137端口响应这类查询。

SMB方面，enum4linux 这个工具可以枚举共享资源、用户列表、组信息、密码策略等。它本质上是调用SMB协议的各种查询接口，不需要登录就能获得相当多信息。不过新版系统逐步禁止了匿名枚举，实测下来成功率不算高，但值得一试。

我通常会把这一步获取的信息和后续主机内部的账户列表做交叉比对。比如枚举出的用户名和主机内的本地账户能否对应上，如果出现差异，就要留意是不是存在隐藏账户或者域账户混用的情况。别小看这个比对过程，很多横向移动的路径就是从这里发现的。

3. Windows主机内部核心信息收集

3.1 账户、用户组与会话信息

拿到主机权限后，第一件事是看系统里有哪些账户。

net user 列出本地用户列表，net localgroup administrators 看管理员组。管理员组成员里如果出现了陌生账户，或者每个用户名的尾部都带 $ 符号，那就要引起注意，可能是隐藏账户或机器账户。隐藏账户通常以 $ 结尾，net user 默认不显示，需要用 reg query 查看SAM注册表项才能发现，这个后面细说。

再看当前会话和在线用户。query user 可以直接查看当前登录到这台机器的所有用户会话，包括远程桌面会话和本地控制台会话。如果在企业服务器上看到多个活动会话，而且用户来自非本机管理员创建的来源，很可能有人已经在横向移动了。whoami /all 则能看清楚当前进程的完整令牌信息，包括所属组、特权列表。这里特别要检查是否有 SeDebugPrivilege 这类特权，有它就能注入更高权限的进程，是提权路上的重要Flag。

域环境还要额外跑一句 net user /domain 和 net group "domain admins" /domain，确认当前主机是否能直接查询域信息。如果普通权限能查到域管理员组成员，意味着域的ACL配置存在问题，后续利用空间会大很多。

3.2 补丁、系统更新与Quick Fix Engineering

和账户信息并列重要的，是补丁情况。

systeminfo 输出的补丁列表非常长，人工看效率太低。我的做法是先把整个输出保存到文件，再使用 PowerShell 下的 Get-HotFix 或者借助工具 Windows-Exploit-Suggester、wesng 这一类工具做补丁对比。

原理很简单，工具把补丁号和已知漏洞做对应，空缺的补丁号对应的漏洞就可以尝试利用。比如系统没有安装某个编号的安全更新，而这个更新恰好修复了某个提权漏洞，那么这条漏洞利用链路就通了。实操时要特别注意，32位和64位的补丁列表不能混用，服务器的补丁策略和客户端也不同，用错参照样本会得出完全错误的结论。

还有一点，补丁信息要结合系统版本来判断。比如Windows Server 2012、Windows Server 2016、Windows Server 2019，它们的EOL时间不同，补丁覆盖程度也不同。老系统能利用的已知漏洞多，但也要警惕目标系统的实际加固情况，不能只看补丁，不看防护。

补丁收集是非常典型的“信息驱动后续动作”的环节，少了这一步，后续的漏洞利用就是在碰运气。

3.3 共享资源、网络连接与路由信息

Windows的共享资源是最容易被忽视的信息点之一。

net share 可以查看本机共享列表。共享名的后缀隐藏着用途，比如C$是默认管理共享，IPC$是进程间通信共享，print$是打印机驱动共享。共享权限设置不当的话，往往可以直接读取或者写入敏感文件。实际操作中，我会单独记录每个共享的路径，以及是否有Everyone/Users的写权限，这是内网中非常常见的错误配置。

网络连接方面，netstat -ano 看所有TCP/UDP连接及对应进程PID。列出连接之后，再用 tasklist /svc /fi "PID eq 进程号" 把PID映射到具体进程和服务，就能还原出这台机器正在和哪些主机通信，通信端口是什么。这是一张现成的网络拓扑图。比如某台机器持续连接着数据库服务器的3306端口，说明它是应用服务器；如果大量连接指向外部地址，那么这台机器可能已经被当作跳板了。

路由信息也不能漏。route print 可以看到本机的路由表，确认能到达哪些网段。加上 arp -a 查看当前ARP缓存，能列出最近通信过的主机IP和MAC地址。这些信息放在一起，基本能画出主机所在网络区域的通信关系，对后续横向移动很有参考价值。

3.4 进程、服务、启动项与计划任务

进程信息是动态影像，记录的是“当前正在发生什么”。

tasklist /svc 列出所有进程及其关联服务。这里重点找几类进程：杀毒软件进程（比如MsMpEng.exe、360tray.exe这类）、监控软件进程、数据库进程、Web服务进程。杀软进程决定了后续工具投递和命令执行的方式，数据库进程则暗示了本机可能存在高价值数据文件。在应急场景中，还要多看有没有异常的进程名，比如常见的挖矿进程、反弹Shell进程，虽然进程名经常伪造，但出现拼写错误或者路径异常就很可疑。

服务方面，wmic service list full 可以列出所有服务的名称、路径、启动类型和状态。这里关键看服务启动类型的配置，很多提权漏洞就是服务路径或权限配置不当造成的。如果某个普通用户可写的目录下有服务程序，而服务以系统权限运行，这就是典型的服务权限提权点。

启动项是持久化分析的核心。reg query 查看注册表Run项，schtasks /query /fo LIST /v 查看计划任务。计划任务特别要看任务名称是否伪装成系统名称，以及触发器、运行账户、运行内容。我在一次排查中发现过计划任务名为空格的案例，任务运行时执行了一个路径很长的脚本，这种隐藏手法不仔细看根本发现不了。

3.5 环境变量、最近文件、浏览器痕迹与剪贴板

这些信息看起来零碎，关键时刻反而是突破口。

环境变量里，PATH 路径可以暴露安装位置，TEMP 路径有时能用来做DLL劫持。更实用的是查看当前用户的数据目录，比如 dir C:\Users\<用户名>\Desktop 和 dir C:\Users\<用户名>\Documents，桌面和文档里经常躺着密码本、运维手册、拓扑图之类的文件，这些可是比漏洞利用更高效的“后门”。

浏览器痕迹在拿下浏览器数据后可以导出Cookie、保存的密码、历史记录，用于接管目标人员的Web会话。不过这个操作已经比较深入，要严格遵守授权范围。剪贴板里的内容也值得记录，很多运维会把密码临时复制在剪贴板里，一复制就是大半天。

还有PowerShell的历史记录，Get-History 只能看当前会话，但控制台历史文件 ConsoleHost_history.txt 可以翻到之前会话执行过的命令，里面同样可能包含密码和敏感路径。这些内容不占磁盘空间，却包含了很真实的业务数据和用户习惯，收的时候多留一份心眼。

4. 敏感信息与凭据数据的专项收集

4.1 注册表、SAM文件与系统配置里的密码痕迹

Windows系统的凭据存储是个经典话题。

SAM文件保存了本地账户的密码哈希，路径在 C:\Windows\System32\config\SAM，但系统运行时该文件被锁定，需要借助卷影拷贝或者从备份中提取。注册表里也有对应信息，可以用 reg save HKLM\SAM 导出。拿到SAM后，配合 secretsdump.py 这类工具可以离线提取本地账户哈希，结合哈希破解或哈希传递进行下一步操作。这一步需要管理员权限，普通用户只能看到账户是否存在，读不到哈希。

注册表里还能搜到不少明文密码。比如某些软件会把数据库密码、FTP密码、Web服务密码写在配置项里，最常见的是VNC密码、RDP凭据，以及计划任务里保存的凭据。用 reg query 搜索关键字能把范围缩小，比如搜包含“password”“passwd”“pwd”的键值。这个操作在真实环境中成功率很高，因为开发人员倾向于把连接字符串硬编码。

系统配置方面，IIS的 applicationHost.config、Apache的 httpd.conf、Tomcat的 tomcat-users.xml 都是常见的密码存放位置。还有 unattend.xml 这类无人值守安装文件，里面经常包含本地管理员密码，这些问题文件即使部署完成后也不一定会被删除。

4.2 数据库连接信息与Web配置文件

数据库连接信息是敏感信息收集的重头戏。

内网系统的数据库连接方式通常写在配置文件里，Web应用常见的是 web.config、appsettings.json、.env 文件。拿到这些文件以后，重点关注连接字符串，里面包含了数据库地址、端口、库名、账号和密码。有时密码是明文，有时做了加密，加密时可以顺着代码找解密逻辑。

配置文件还有一层价值：它们能反映应用的架构。一个配置文件里如果同时写了Redis、MongoDB、RabbitMQ的连接信息，说明这台主机所在的业务系统架构并不简单，后续可以把这些中间件也纳入测试范围。

这里要给一个明确提醒：读取数据库配置后，如果授权范围内允许，可以尝试连接数据库确认信息可用性。但如果授权范围不包含数据库的进一步操作，就到此为止，把连接信息记录下来，在报告中注明风险点即可。越界操作会给你带来麻烦，这一点务必控制好。

4.3 避开杀软与EDR，让收集动作更安静

信息收集不单是读取数据，更是要“低调地”读取数据。

Windows主机上常驻的杀毒软件和EDR会监控敏感命令的执行。比如 cmd.exe 里跑 net user 这类的常规命令可能会触发低危告警，而直接复制SAM文件、导出Lsass进程内存这类动作几乎是必被拦截的。所以我的习惯是优先使用系统自带的标准管理方式，比如PowerShell的 Get-* 系列命令、WMI查询，这些调用路径和正常管理动作一致，不容易引起注意。

如果确实需要使用第三方工具，先把工具上传到目标机器这个行为本身就容易触发监控。我的做法是尽量用一些体积小、签名正常的工具，或者直接把对方的PowerShell环境作为执行平台，规避可执行文件落地。还有一点，执行完的命令行参数会写入审计日志，如果环境开启了详细审计，最好在收集完信息后和负责人确认是否需要做日志清理，切不可自作主张删除日志，这在授权测试中属于越界动作。

5. 自动化收集与输出整理

5.1 把常用命令织成一张收集网

单条命令跑着太零散，我会把它们织成一张网。

在授权测试中，我习惯写一个批处理脚本收集常规信息，输出到指定目录，再一次性打包拉走。脚本内容通常包括系统信息、账户列表、共享列表、网络连接、进程列表、计划任务、启动项等。下面是一个简化版的示例：

batch复制@echo off
set OUTDIR=%TEMP%\hostinfo
mkdir %OUTDIR% 2>nul

systeminfo > %OUTDIR%\systeminfo.txt
ipconfig /all > %OUTDIR%\ipconfig.txt
net user > %OUTDIR%\netuser.txt
net localgroup administrators >> %OUTDIR%\netuser.txt
net share >> %OUTDIR%\shares.txt
netstat -ano >> %OUTDIR%\netstat.txt
tasklist /svc >> %OUTDIR%\tasksvc.txt
schtasks /query /fo LIST /v >> %OUTDIR%\scheduled_tasks.txt

reg export HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run %OUTDIR%\run.reg /y
reg export HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run %OUTDIR%\run_current.reg /y

dir /s /b C:\Users\%USERNAME%\Desktop\ *.txt *.rdp *.ps1 *.bat > %OUTDIR%\desktop_files.txt

exit

上面脚本里 .rdp 文件很值得单独关注，远程桌面配置文件里偶尔会残留服务器地址和用户名。 *.ps1 和 *.bat 则是脚本类文件，多翻翻没坏处。

脚本组织上我有几个习惯。第一，输出文件名和内容一一对应，方便后期找文件。第二，每个输出文件第一行加时间戳，避免同一台机器多次收集时混淆。第三，脚本跑完以后立即用WinRAR压缩加密码，减少传输途中被截获的敏感信息泄露风险。

5.2 用循环批量收集多台主机的信息

单机脚本有了，多台机器就要考虑循环执行。

在已经拿到域内账号的前提下，可以利用PsExec或WinRM批量执行收集脚本，把结果回传到统一目录。我的做法是准备一个主机列表文件，然后写一个循环脚本，逐个机器执行。这里几个细节要特别注意。

第一，账号权限要提前确认，普通域用户能收集到的信息有限，建议用具备本地管理员权限的账号批量执行。第二，回传目录按IP或主机名建子目录，避免文件互相覆盖。第三，整个过程要控制并发数，一次同时对几十台机器执行远程命令会产生明显流量特征，容易触发内部的异常行为检测。

我实测比较好用的是PowerShell远程会话：在Source机器上用 Invoke-Command 配合主机列表数组，每台机器执行一组命令，结果会以对象形式返回，方便直接导出CSV。这种方式比批处理脚本自适应强，但要求目标机器开启WinRM并且防火墙放行5985/5986端口，域环境通常默认放行，工作组环境要看具体情况。

5.3 建立一份“信息资产台账”

收集到的信息要整理成台账，不然就是一堆死文件。

我的台账字段包括：主机IP、主机名、操作系统版本、管理员组成员、开放端口、运行服务、数据库连接串（如有）、共享列表、启动项列表、计划任务列表、网络连接要点、补丁缺口摘要、备注。这样一个表格拉下来，主机的全貌就清楚了。后续写报告也不会东翻西找。

台账整理我有一个技巧：用Markdown建一个目录索引，每个主机一个文件，文件顶部是摘要表，下面按信息类别分节记录原始输出和我的标注。这样既保留了原始证据，又方便快速浏览。报告阶段需要什么证据，按图索骥即可。

5.4 工具选型与参数速查表

不是所有信息都需要手敲命令，有些工具能帮你大幅提效。我常用的组合是：

这里单独说下BloodHound，它采集域内主机、用户、组、会话等信息，并用图数据库展示权限路径，已经是我做域环境信息收集的标配。不过它产生的采集流量不小，在敏感环境使用前要确认授权范围。mimikatz则必须重点强调，它直接读取Lsass进程内存中的明文密码和哈希，触发检测概率极高，务必在明确授权并且业务方知情的情况下使用，否则会有很大麻烦。

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

6.1 命令执行不了，先排查权限再排查策略

我在实战里遇到最多的问题就是命令被拒绝。

第一类是权限不足。secretsdump 读不到SAM、mimikatz 抓不到密码、reg save 提示拒绝访问，这些基本都是权限问题，换成管理员权限执行即可。如果当前用户不在管理员组，又必须获取敏感信息，就要先走一遍提权流程，这属于另一个话题了。

第二类是执行策略受限。PowerShell默认的 Restricted 策略会阻止脚本执行，但不会阻止单条命令。用 powershell -ExecutionPolicy Bypass -File xxx.ps1 或者 Set-ExecutionPolicy -Scope Process Bypass 就能规避当前会话的限制。这个方法不改变系统全局策略，重启后恢复原状，不会给目标系统留下持久修改。

第三类是AppLocker/WDAC限制。应用白名单会阻止非白名单程序运行，这时优先考虑用系统中已有的合法程序做信息收集，比如 rundll32、mshta、regsvr32，或者直接用PowerShell、WMI，这些组件默认在白名单内。注意，调用系统组件也要谨慎，因为EDR同样监控这些调用链路的异常行为。

6.2 信息对不上号？核对视图差异和语言环境

经常有朋友反馈，同一个信息，用不同命令查出来的结果不一样。这不是机器出问题了，很可能是Windows的视图差异。

最典型的是系统版本。ver 的显示和 systeminfo 的显示有时会不一样，比如部分Server系统 cmd 窗口里的版本号显示旧版本，而 systeminfo 显示实际版本。另外，多语言环境中 net user 输出的字段名不同，如果脚本按中文字段名做解析就会出错。我的建议是以 PowerShell 的 Get-ComputerInfo 和 Get-LocalUser 为准，对象化输出更适合程序处理。

组信息也容易出现类似问题。本地组的 Administrators 和域组的 Domain Admins 是两个概念，很多新手看到管理员组里有域账户就以为是本机账户，结果在横向移动时用错了凭据。收信息时建议把SID、组名、类型都记下来，方便后续核对。

6.3 遇到杀软拦截怎么调整收集方式

杀软是信息收集的最大变数。

如果目标机器安装了卡巴斯基、赛门铁克这类商业产品，你刚跑完 systeminfo 它可能没反应，但一旦尝试读取SAM或者抓Lsass，告警马上就来。我的经验是，要读取这些敏感数据，优先考虑通过合法备份通道去拿，比如卷影拷贝服务 vssadmin create shadow 再复制文件。这种方法通常不在杀软的常规拦截名单里，而且不修改系统文件，相对隐蔽。

进程和网络层面的监控更隐蔽。如果你执行了常规命令，却发现网络连接突然断掉或者进程被结束，大概率是触发了行为检测。此时不要再折腾，停下来确认授权文件里是否覆盖了这类操作。如果确认有授权，再考虑用更慢、更分步的方式执行。记住，信息收集重要，但合规更重要，宁可少收集几个点，也不能把自己搭进去。

6.4 日志与时间线：别搞丢Root Cause

应急响应的信息收集中，时间线是命脉。

Windows事件日志里，安全日志的登录类型字段区分本地登录和网络登录，类型10是远程交互登录，类型3是网络共享访问，类型4是计划任务启用。看到大量类型3的失败日志，可能有人在尝试爆破SMB；看到非常规时间的类型10成功日志，就要排查远程桌面暴力破解或者账户泄露。

时间线整理时建议把系统启动时间、最近登录时间、计划任务创建时间、文件创建/修改时间放在一起对齐。有时候系统补丁安装记录和进程启动时间能帮你还原“问题是什么时候进来的”。这一步本来可以用自动化工具，但真实业务环境里系统日志常常被裁剪过，手动核对反而更可靠。

6.5 常见问题速查表

7. 信息收集的合规边界与个人体会

信息收集在很多场景里就是一层窗户纸，捅破之后能看到很大的世界。但也是因为这样，它更需要明确的边界。没拿到授权就动手，不管初衷如何，本质都是越界访问，这个底线我不止一次在培训和带新人时强调过。即使拿了授权，也要严格限定在授权范围和授权时间内，收集到的敏感信息更不要随意留存和传播。

根据我自己的经验，信息收集阶段最容易犯的错是“贪多”。看到什么都想收集，结果信息一多反而不知道从哪里下手。我现在更倾向于以任务目标为圆心，先收跟目标直接相关的信息，再逐步外扩。真正值钱的信息不是最全的，而是最能帮助判断的那一小撮。

另外，Windows主机的信息收集不是一次性动作，而是一个反复迭代的过程。早期拿到的基础信息，可能在后续漏洞利用失败后需要重新回看，换一个角度反而能发现新线索。所以我每次收完信息都会花时间过一遍台账，问自己有没有更好的利用路径，有没有遗漏的关联点，这个复盘习惯帮我找到了不少原本会错过的攻击面。

8. 最后再分享一个小技巧

如果不愿意写脚本，又想让收集的信息够全，可以先把常用的查询命令分类整理成一个个短小的 .ps1 文件，比如 network.ps1、account.ps1、service.ps1，放到一个固定的移动介质里。到目标机器后只需要按顺序执行，再把结果复制出来。这套东西可以反复使用，而且你可以根据平时踩坑的情况持续往里面补充命令。

我最开始是查一条命令抄一条，后来慢慢形成自己的信息收集工具箱，现在每次测试都会从这套流程开始，稳定、省心、不丢项。信息收集本身不复杂，但只要肯在这个环节多花点心思，后续利用阶段你会感谢现在的自己。希望这篇东西能帮你把基础打牢。