内网凭据收集实战：从翻配置文件到策略性爆破的方法论

干了这么多年内网安全评估和应急响应，我见过太多人一拿到内网权限就掏出爆破工具开跑。结果往往很尴尬：账号被锁定、日志翻飞、目标设备还没摸清，人已经被防守方盯上了。真正让我觉得“凭据满天飞”的，从来不是爆破出来的，而是老老实实“翻”出来的。这篇文章想聊的就是内网里凭据密码收集的方法论，从终端文件、内存缓存、协议流量到策略性爆破，把我这些年攒下来的思路、步骤、坑和排查经验一次说清楚。

这篇文章适合三类人看：一是做授权渗透测试和红队评估的朋友，二是企业安全建设者，想搞明白内网到底哪里在泄露凭据，三是刚入门、想系统了解内网安全问题的新人。我尽量少讲虚的，多给能落地的检查思路和防护建议。先强调一句：所有方法都只能在获得授权的前提下使用，靶场、企业内部评估、红蓝对抗演习都是合理的场景，未授权环境下用这些手段，后果只能自己承担。

1. 先想清楚一件事：爆破不是你进入内网后的首选

1.1 为什么“瞎爆破”是最低效的选择

先说个很直观的现象：很多朋友把“内网渗透”等同于“爆破”。拿到一个目标内网 IP，第一反应就是架起 hydra、超级弱口令检查工具，把常见用户名字典和密码字典往上一灌，然后开始漫长等待。但真实的内网环境里，爆破的代价非常高。

第一是账户锁定策略。Windows 域环境默认或者经过安全加固后，往往配置了账户锁定阈值，比如 5 次失败锁定 30 分钟。一旦你对着某个账号连续尝试，账号被锁，防守方很快就会从安全日志里看到大量 4625 事件，等于直接暴露了自己。第二是告警问题。现在稍微正规一点的企业，都会在域控、核心交换机、EDR 上做登录失败告警。你跑一万次字典，可能十秒钟内告警就传到安全团队手机上了。第三是效率问题。爆破是典型的“用时间换概率”，对着未知密码试错，命中率其实低得感人。

我见过一次挺典型的授权评估，客户给了几台内网服务器的账号权限，结果测试人员一上来就对全 C 段跑 SSH 爆破，跑了一个通宵，一个弱口令都没跑出来。后来我们换了个思路，先去翻那几台服务器上的运维脚本和配置文件，半小时内就拿到了 3 组明文口令。这个对比很直观：爆破是“逐把试钥匙”，凭据收集则是“先检查门垫下面、花盆底下、口袋里面有没有备用钥匙”。后者的成功率比前者高一个数量级。

1.2 内网凭据收集的两条主线

我把内网凭据密码收集分成两条主线。第一条叫“主机侧存储形态”，意思是凭据以文件、数据库、内存、配置项等形式存在于终端和服务器上。比如 Web 配置文件里的数据库连接串、运维脚本里的 FTP 密码、远程桌面保存的凭据缓存、浏览器表单里保存的登录信息。第二条叫“协议侧传输形态”，意思是凭据在网络上传输的过程中被截获或重放。比如 HTTP Basic 认证的明文口令、FTP/Telnet 这类明文协议里的密码、SMB 协议中的 NTLM 认证数据。

这两条线的优先级是不一样的。我的经验是：先做主机侧的“翻垃圾”，再做协议侧的流量分析。因为主机侧的信息通常静态、稳定、不会突然消失，而且一旦找到就是明文口令，直接就能用。流量侧则需要你已经在目标网络中占据一定观察位置，而且很多内网流量已经加密或启用签名，能拿到的东西有限，但它的好处是“被动、安静、不容易被察觉”。

所以整套方法论的核心其实是“降低爆破的必要性”。凭据收集做得越充分，你越不需要靠试错去撞口令。就算最后必须做口令测试，也应该是精准的、有策略的，而不是一把梭。

1.3 授权与合规：这篇内容适用的场景

我必须把这条单独拎出来说。内网里的凭据收集，本质上是围绕口令展开的安全测试。它的合法场景很明确：你对自己企业的系统做安全自查，你所在的团队与目标单位签署了渗透测试授权书，或者你是在靶场、实验环境里做技术验证。除此之外，任何未授权的尝试都可能触犯法律。

写这篇文章的目的不是教人去打真实系统，恰恰相反，是希望大家理解内网口令是怎么“漏”出来的，从而在防守端做好自查和加固。我在后面每个小节里，能写防守建议的地方都会尽量写上。红队视角和蓝队视角本来就是一枚硬币的两面，理解了攻击者怎么收集凭据，才知道该把力气花在哪里堵漏。

2. 内网凭据的第一大来源：终端与服务器上的“翻垃圾”环节

2.1 配置文件：一个口令串就能让你少跑一万次字典

“翻垃圾”听上去不高级，但它是内网凭据收集里性价比最高的动作。企业内网里最不缺的就是各种配置文件，它们散落在 Web 服务器、应用服务器、数据库服务器上，里面几乎都硬编码着敏感口令。

最常见的几类配置目标：

• Web 站点配置：config.php、application.yml、web.config、.env 等文件里，大概率有数据库连接串、Redis 密码、加密 key。
• 中间件配置：Tomcat 的 tomcat-users.xml、WebLogic 的 config.xml、Nginx 的 nginx.conf 里如果配置了反向代理和上游认证，也可能存在口令。
• 运维平台配置：Jenkins 的 credentials.xml、GitLab Runner 配置、Ansible 的 inventory 文件，里面保存的凭据数量往往比想象中多得多。
• 云环境配置：企业上云之后，~/.aws/credentials、阿里云 CLI 的配置文件、腾讯云 API 密钥，经常以明文形式摆在服务器上。

查找方式不复杂。在拿到授权的 Linux 主机上，用 grep 快速扫关键字即可。我常用的命令大概是：

bash复制grep -r -E "password|passwd|pwd|secret|token|api_key|access_key" /etc /opt /home /var/www 2>/dev/null

当然，全盘 grep 在文件量大的服务器上会很慢，建议先按目录缩小范围，优先看 /opt、/home、/var/www 这类业务目录。Windows 服务器上也可以做类似的文本检索，用 PowerShell 在指定目录下遍历文件内容。搜索的时候不要只搜 password，pwd、passwd、connectionString、jdbc:mysql、mongodb:// 这些关键字命中率更高。

还有一个很容易忽略的点：内网很多系统之间做了单点登录或者接口对接，配置里存的往往是“服务账号”的密码，这个账号权限可能比普通运维账号还高。我之前在一台测试服务器上翻到一个 .env 文件，里面是某支付网关的私钥和回调验签密钥，这个信息的价值远超一个弱口令账号。

2.2 历史命令、计划任务与运维脚本

配置之外，第二个容易漏出口令的地方是历史命令和自动化脚本。Linux 用户的 ~/.bash_history 里经常能看到 mysql -u root -p'xxx'、scp 带密码、curl -u username:password 这类操作记录。Windows 上 PowerShell 的历史记录 ConsoleHost_history.txt 同理，还有 %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ 下面的文件。

运维脚本就更好理解了。很多企业会写一批自动备份、定时同步、批量部署的脚本。用户习惯用 #!/bin/bash 写完后直接在里面写 ftp -n、smbclient //server/share -U user%password、mysqldump -p'xxx'。这些脚本往往放在 /opt/scripts、/root/scripts、/data/backup 这类目录，而且为了保证长期可用，密码很少定期更换。

我的检查顺序是这样的：

1. 先看当前用户的 history 和 .bash_history。
2. find / -name "*.sh" -o -name "*.py" 2>/dev/null 找脚本目录。
3. 重点看 cron 任务和 Windows 计划任务，因为任务定义里偶尔会直接带参数。
4. 最后再看备份目录里的压缩包，解压后里面的配置文件往往是“暗藏惊喜”。

从防御角度看，这份清单其实就是企业自查的口令泄漏点：运维脚本中是否还保留明文口令、构建日志中是否打印了环境变量里的密码、备份文件是否被不相关的人访问。很多企业做等级保护时只关注系统漏洞，却忽略了脚本和配置里的大面积泄露。

2.3 内存和缓存：LSASS、浏览器与 SSH Agent

如果说配置文件和脚本属于“明面的垃圾”，那内存里的凭据就是“暗面的宝贝”。Windows 系统的 LSASS 进程会缓存登录用户的凭据，包括密码哈希和部分明文。在授权的内网评估里，这是非常关键的一环，因为它能让测试人员从一台已经被攻陷的主机上提取出域用户的凭据，进而横向移动到其他机器。

我不打算在这里展开完整的内存提取步骤，因为那属于纯攻击操作了。但原理值得说清楚：Windows 为了支持单点登录和快速认证，设计上会把凭据缓存到内存里。这不是系统漏洞，而是功能设计，但它带来的风险是：一旦你拿到了本机管理员权限，你就可能拿到这台机器上曾经登录过的所有用户的内存凭据。

浏览器和 SSH Agent 同理。Chrome、Edge 里保存的网站密码，虽然经过了系统级加密，但只要是在用户已登录的会话里，工具可以直接调用解密接口。SSH Agent 保存的私钥也一样，它在代理进程里以明文形式驻留。这些凭据在企业内网里经常被忽视，但它们恰恰是横向移动的关键燃料。

防守侧的思路就两条：一是减少凭据在内网环境中的驻留时间，比如启用 Windows Credential Guard，把凭据保护交给虚拟化安全进程；二是限制本地管理员权限，别让普通运维人员随便在一台机器上拥有管理员权限。域环境里还要特别注意“本机管理员密码统一”的问题，这个问题我会在后面单独讲。

2.4 域环境中的高价值凭据源

内网里如果存在 Active Directory 域，那么凭据收集的重头戏就在域环境里。几个地方需要重点关注。

第一个是域控上的 NTDS.dit 文件。它是整个域内所有账号的哈希数据库，拿到它等于拿到了整个域的口令全集。所以在红队评估里，“域控失守”基本就意味着内网彻底失守。第二个是 SYSVOL 共享目录。早期很多企业会把组策略首选项（GPP）里配置的本地管理员密码放在 SYSVOL 下，而且经过加密的 cpassword 可以被公开工具直接还原。虽然微软后来发布了补丁禁止在 GPP 里写密码，但老环境里未清除的配置仍然存在。第三个是 Kerberos 票据。TGT 和 ST 票据在特定条件下可以被离线破解或者重放，尤其是如果使用弱加密算法（RC4），破解成本更低。

从防御角度看，企业应该重点监控域控上的目录复制请求、SYSVOL 文件的异常读取、以及 Kerberos 服务票据的批量请求。对于已经发现的 GPP 密码，要做的不是简单删除配置文件，而是确认相关本地管理员密码是否已经被修改过，否则攻击者早就把密码抄走了，你删文件没任何意义。

3. 更安静的收集方式：流量和协议中的“送上门”凭据

3.1 内网协议的“裸奔”现象

我在做内网评估的时候经常感叹：很多企业在边界防御上花了大量预算，但内网流量基本都是明文裸奔。这不是夸张，而是很常见的情况。企业内部的老旧系统、打印机、摄像头、门禁管理平台，很多还在跑 HTTP、Telnet、FTP、SNMP。这些协议的问题在于，口令在网络上传输时没有有效加密，只要有人在同一网络路径上做流量捕获，就能直接看到用户名和密码。

举几个典型的场景。某台内网交换机的 Web 管理页面用 HTTP Basic 认证，管理员每次登录时，Authorization: Basic base64(username:password) 这个头会直接出现在网络上。虽然 Base64 只是编码，不是加密，但很多人误以为它安全。FTP 就更直接了，用户名、密码在控制连接里完全是明文。内网里大量老旧系统还在跑 FTP，而且为了方便，很多都是同一个密码到处用。

我自己做授权评估时，会在拿到一个内网接入点之后，先对目标网段做流量画像，看看哪些协议在跑、哪些主机之间存在高频认证交互。常用手段是抓包做协议统计，重点关注 21、23、25、80、443、445、3389 这些端口。抓到流量后优先检索关键字，比如 Authorization、pass=、user=。这类流量分析工作属于被动收集，不容易被检测到，所以它比爆破要安静得多。

但防守方也别慌，这类问题并非无解。对内网流量做加密改造是长期工程，但短期的缓解措施包括：设立 VLAN 隔离，把不同业务划到不同广播域；关键管理端口（SSH、RDP、HTTPS）只允许通过跳板机访问；对核心交换机关闭不必要的端口镜像。顺带提醒一句，在做网络改造的时候，不要只盯着业务系统，打印机、门禁、摄像头这些物联网设备往往是内网明文口令的重灾区。

3.2 链路本地协议响应：LLMNR/NBT-NS 带来的凭据“赠品”

内网里有另一类凭据获取方式，不靠抓包，靠“等等看谁发错请求”。链路本地协议 LLMNR 和 NBT-NS 是 Windows 系统在 DNS 解析失败时用来做名称解析的“兜底方案”。正常情况下，当用户访问一个不存在的名称或者输入一个有拼写错误的主机名时，系统会向本地网络广播查询，询问“谁是这台机器”。

在同一个二层网络里，攻击者可以运行工具，假装自己就是那台被询问的机器。这时用户机器会尝试与“伪主机”建立会话，最常见的就是 SMB 会话。在建立会话时，用户机器会主动提交自己的用户名和 NTLM 认证数据。攻击者不需要知道密码，只需要把这个认证数据抓下来，然后做离线破解，或者直接用于后续的认证重放。这就是内网里所谓的“凭据赠品”。

说句实在话，这类攻击在大型企业内网里成功率并不低。因为用户每天都会因为拼错主机名、访问已下线服务器、输入错误 UNC 路径而触发链路本地解析。很多时候，用户自己都不知道自己的口令已经被别人拿到了。

防守措施也比较明确：组策略层面禁用 LLMNR 和 NBT-NS，启用 SMB 签名，把所有机器加入域并启用 Kerberos 认证。在网络侧，限制二层广播域的规模，重要部门之间做 VLAN 隔离。还有一个很容易被忽略的地方：不要在你的 DNS 后缀搜索列表里放太多无意义的后缀，否则系统会频繁触发链路本地解析，给攻击者送更多“赠品”。

3.3 用交换机和主机日志做检测

刚才一直在说攻击者怎么用流量侧做收集，但我更想强调的是防守方怎么发现。流量侧的信任前提是“网络路径上有人”，只要防守方在交换机和关键网段部署了检测手段，被动收集也会变成高风险动作。

具体检测思路有这么几条。第一，在核心交换机上做端口镜像，把关键链路的流量复制给入侵检测系统，重点检测 SMB 会话中的异常认证行为、NTLM 挑战响应数量突增、DHCP 地址请求异常。第二，关注主机事件日志中的特定事件 ID，比如 Windows 事件 ID 4624、4625 之外的“网络登录”类型，以及账户登录异常时段。第三，DNS 日志也很关键。链路本地解析的触发频率如果异常升高，往往说明有人在伪装名称解析响应。

我知道很多中小企业没有安全运营团队，那至少做到一点：把关键服务器的安全日志统一收集起来，开启审计策略，设置针对登录失败和特殊权限使用的告警。别把日志只存在本机上，否则攻击者清理日志之后，你连事故现场都看不到。

4. 当必须“撞库”时：策略性爆破与字典构造

4.1 先摸策略，再定节奏

讲了这么多“翻垃圾”和流量收集，但有些场景下你还是得做口令测试。比如你拿到了某个业务的登录入口，想验证是否存在弱口令；或者你已经从配置文件里收集了一批账号，想确认这些账号在别的系统上是否复用了口令。这时候你要做的就不是瞎爆破，而是有策略的“撞库”。

第一件事永远是摸策略。摸清楚了再动手，摸不清楚就小步试探。具体摸什么？目标系统有没有账户锁定策略，锁定阈值是多少，锁定时间多长，是否有关键接口验证码或频率限制，登录失败后会不会给管理员发告警。这些信息有一部分能从系统配置或历史行为中推断，有一部分只能靠“试探一点点”来感知。

我的经验是：宁可慢，不可莽。内网测试和互联网测试不一样，内网里一旦触发锁定策略，很容易让业务人员发现异常，整个项目都会变得被动。所以我通常先把字典控制在低位，比如每个账号最多试 3 到 5 次，并且分多个时间段执行，避免在一分钟内连打几十次。这样即使触发阈值，影响也可控。

4.2 字典不是越大越好，而是越“像”越好

很多新人喜欢下载几个上百 GB 的“全网通用字典”，恨不得把几亿条密码都试一遍。但实际效果很差，因为通用字典根本不了解你的目标企业。内网口令测试真正有价值的字典，一定是从目标的业务场景里长出来的。

怎么构造？先收集目标企业的公开信息，比如企业简称、域名、员工姓名、分支机构所在城市。然后按常见的口令习惯组合。中国人常用的口令习惯是姓名拼音加数字，数字又以手机号后四位、工号、生日、年份为主。密码结构通常是“首字母大写 + 姓名拼音 + 特殊字符 + 数字”，比如 Zhangwei@123、Liqiang2024、Admin@123。企业如果上了统一认证系统，大概率还会强制口令复杂度，所以“强密码”和“可记忆”之间的平衡会导致大量员工选择相似的结构。

我习惯用脚本生成“定向字典”，而不是手工敲。思路是：

1. 收集员工姓名拼音，包括全拼、首字母缩写。
2. 拼接常见年份：2020、2021、2022、2023、2024。
3. 拼接常见数字：123、123456、888、666、工号。
4. 拼接特殊符号前缀或后缀：@、#、!、_。
5. 再混入企业缩写、业务系统名称、部门名称。

这样生成的字典可能只有几千条到几万条，但命中率比几百万条的通用字典高得多。记住一个原则：字典的本质是“猜人心的规则”，而不是“穷举所有可能”。

4.3 常见工具的参数细节

内网口令测试常用的工具，我还是提几个大家接触较多的。Burp Suite 的 Intruder 模块适合测 Web 登录接口，它能精确控制请求模板、字典变量位置和线程数。Yakit 的爆破模块也很适合测 Web 应用，它对国内常见系统的登录接口兼容性做得不错，还能直接对接字典和验证码识别接口（验证码识别一定要在授权场景下使用）。如果目标是 SSH、RDP、SMB 这类协议，hydra 和 medusa 是老牌选手，胜在稳定。

这里想重点说参数设置，因为同样的工具，参数设错了，结果天差地别。线程数不要往高了调。Burp 或 Yakit 的线程数越高，目标系统的响应速度就越快被打满，但相应的，触发 WAF 和账户锁定的概率也越高。我一般把线程控制在 5 到 10 之间，HTTP 请求之间加一个随机延迟。Hydra 的 -t 参数同理，别一上来就是 64 线程。另外，超时时间也要合理设置。内网链路质量参差不齐，超时设得太短，大量请求会误报为失败；设得太长，速度又太慢。通常 10 到 15 秒是一个比较稳妥的区间。

还有一个细节：如果目标是 Web 登录接口，一定要先分析清楚登录流程。很多系统的登录接口不只是一个 POST 请求，它可能前面还有一个获取 Token 的请求，或者表单里藏着一个动态加密参数。直接用固定的字典去爆破，往往全是“用户名或密码错误”，因为在请求层面就已经不对了。先花半小时把登录请求的每个参数都搞清楚，再用 Intruder 做变量替换，效果会好得多。

4.4 爆破完工之后：凭据复用性验证

爆破出来一个密码，不等于任务结束。内网环境里最让人兴奋的发现，不是某个系统存在弱口令，而是这个弱口令在其他系统上也通用。我见过很多企业的真实情况：运维人员为了省事，用同一套密码管理服务器、数据库、堡垒机、Wi-Fi 管理系统。攻破一个点，等于攻破一整条链。

所以拿到一批“账号 + 口令”之后，不要急着去找下一个爆破目标，先做复用性验证。步骤大概是：

1. 把收集到的口令按账号类型归类，区分域账号、本地账号、应用账号。
2. 先在同网段的可达主机上测试口令复用情况，优先测 SSH、RDP、SMB 这类远程管理服务。
3. 如果目标启用了账户锁定策略，验证次数同样要控制。
4. 记录复用结果，形成“账号 - 口令 - 可用主机”的对应清单。

复用性验证也要有边界意识。我在授权测试里会先和客户确认好测试范围，哪些主机可以测、哪些系统不允许动。内网里有些系统的业务连续性要求极高，哪怕只试错一次，都可能造成服务中断或者账号被锁定，这类目标是绝对不能碰的。

5. 凭据收集之外的“台账思维”和复盘闭环

5.1 建立账号、主机、权限、口令来源的台账

凭据收集做得好不好，很大程度上取决于你会不会整理。很多项目搞到后面一片混乱，不是因为信息不够，是因为信息太杂，没有结构化。我的做法是每收一笔凭据，就同步更新台账。

台账的核心字段大概是：

不要小看这个台账。它不仅能让你在写报告的时候有据可查，还能帮你快速判断下一步往哪走。比如说，你发现某个 svc_backup 账号能登录 20 台主机，那这个账号就是整个内网里的“关键路径”。你后面所有的横向移动和权限提升，都可以围绕这类账号展开。对于防守方来说，这种台账思维同样有用——你可以用它来做“最危险账号”的盘点，看看哪些服务账号的权限过大、哪些账号长期没有改密。

5.2 为什么本地管理员口令复用一个内网最大的坑

内网里还有一个绕不开的话题，就是本地管理员口令复用。很多企业在批量部署Windows服务器时，会把同一份镜像或同一个本地管理员密码灌到所有机器上。偶尔做一次安全评估，就会发现几百台机器共用同一个 Administrator 密码。

这种情况有多危险？只要有一台机器被攻破，攻击者提取出本地管理员口令，就能用同一套口令登录内网里的所有机器。这就是典型的“一把钥匙开所有锁”。红队评估里，拿到第一台 Windows 主机之后，我第一件事就是看它能不能用相同密码登录同网段的其它机器。如果答案是“能”，那基本等于整个网段已经失守。

防守侧的建议也很直白：本地管理员密码必须随机化，并且定期轮换。Windows 下有 LAPS（Local Administrator Password Solution）这样的方案，可以把每台机器的本地管理员密码独立管理、定期变更。企业如果还没部署这类方案，至少先做一轮排查，看看你的服务器镜像里是不是还藏着同一个默认密码。

5.3 从一次授权评估的闭环来看凭据价值

讲一个典型的授权评估复盘，能帮你把这些方法串起来。某次测试中，客户给了一个普通域账号和一台内网跳板机的权限。我没有急着去跑爆破，先在那台跳板机上翻了半小时的配置文件和历史命令，很快找到一份运维脚本，里面写着一个数据库账号的明文密码。用这个数据库账号连上数据库服务器之后，我在数据库的配置表里又发现了应用系统的管理员后台口令。

后面的事情就顺理成章了。用管理员口令登录应用后台，找到一处文件上传功能，上传一个授权范围内的测试脚本，拿到应用服务器权限。接着检查应用服务器内存，发现域管理员账号的缓存凭据。再用这个凭据登录域控，整个域环境的权限就到手了。整个过程里，爆破只占很小一部分。大部分时间都花在“顺着凭据链条往下走”。

这个案例里，值得反思的地方有很多。第一，运维脚本里的明文口令是整个链条的开端，防守方如果能把运维脚本里的口令改成从密钥管理系统动态获取，这个链条就断了一半。第二，应用服务器上不应该缓存域管理员凭据，管理员登录业务系统应该使用独立的低权限账号。第三，数据库配置表和后台口令放在一起，等于把钥匙插在了锁上。这些点都不是什么高深技术，但很多企业就是做不到。

6. 我踩过的坑与常见问题排查清单

6.1 常见问题速查表

凭据收集这个方向，说难也难，说简单也简单，但实际操作中总是会遇到各种奇怪的问题。我把这些年踩过的坑整理成了一张速查表，希望你能少走弯路。

6.2 两个容易忽略的实战细节

第一个细节是时间同步。这个问题在内网里非常常见，而且危害很大。Windows 域环境下，Kerberos 认证对时间偏差极其敏感，默认允许的最大偏差只有 5 分钟。如果你的主机没有同步域控时间，即使账号密码完全正确，认证也会失败。很多人遇到“密码明明是对的，但就是登不上”的情况，第一反应是怀疑密码问题，花了很多时间在字典和工具上，最后发现是时间差了 8 分钟。

第二个细节是日志时区。做安全分析和事件复盘的时候，很多工具的默认时区是 UTC，而国内系统记录的是东八区时间。如果你不把时区换算统一，比对日志的时候很容易差出 8 个小时，导致把无关事件当成同一波攻击，或者错过真实攻击链。这个细节在排查“凭据到底是从哪个入口泄露的”时特别关键。

6.3 一些自己的真实体会

技术聊到最后，还是想说点实际的。我在真实项目里养成了一个习惯：不管拿到多大的内网权限，第一件事永远是花至少 30 分钟梳理“凭据来源清单”。清单上写清楚哪些地方已经查过、哪些地方还没查、哪些口令是从配置文件里拿到的、哪些是从流量里嗅到的。这个习惯帮我省了很多无用功。

关于爆破，我的态度一直是：它应该是最后的手段，而不是第一选择。先把配置文件翻干净，把历史命令扫一遍，把内存缓存和协议流量过一遍，再决定要不要动用字典工具。就算最后必须测口令，也要控制节奏、控制风险、控制影响范围。内网渗透不是比谁的字典大，而是比谁更懂口令在真实环境里的存在方式。

另外给防守方朋友一个建议：定期用红队的视角检查自己的内网，不需要做多复杂的渗透，先把自己的配置文件、运维脚本、服务账号权限、本地管理员密码复用情况盘一遍。你会发现，真正需要防的往往不是那些高端漏洞，而是我们自己的运维习惯。把明文口令清干净、把服务账号权限收敛好、把日志审计做起来，内网的安全性会提升一个量级。