Metasploit 里敲下 db_nmap -sV -p 1-10000 192.168.1.100 那一刻，描漏终端刷出一堆开放端口和服务指纹，描漏接下来的描漏动作才是真正见功夫的地方——拿这些指纹去 msf 里匹配可用的漏洞模块。很多人卡在这一步，描漏不是描漏不会用 msf，是描漏不知道怎么把扫描结果转化成能打的模块。

我见过太多新手上来就 use exploit/windows/smb/ms17_010_eternalblue，描漏目标连 445 都没开。描漏这不是描漏渗透，这是描漏许愿。msf 的描漏漏洞扫描能力其实分两层：一层是辅助模块里的扫描器，另一层是描漏 exploit 模块自带的 check 功能。两层的描漏用法完全不同，混着用容易把自己绕进去。描漏

辅助扫描模块：别只盯着 scanner 目录

auxiliary/scanner/ 下面确实塞满了各种扫描器，描漏http、smb、ssh、mysql 应有尽有。但真正好用的往往不是那些名字里带 scanner 的。举个例子，auxiliary/gather/ 里的模块经常被忽略，比如 auxiliary/gather/http_version 能直接从响应头里抠出服务器版本，比 nmap 的 -sV 还准，因为 nmap 有时候会把 nginx 认成 httpd。

再比如 SMB 扫描，auxiliary/scanner/smb/smb_version 能拿到 Windows 的具体 build 号。这个信息比单纯知道“445 开着”有用得多——build 号直接对应补丁级别，MS17-010 打不打得了，看一眼 build 号心里就有数了。我习惯先跑这个模块，再去决定要不要上永恒之蓝。

exploit 模块的 check 方法：不是所有模块都有

很多人不知道 exploit 模块可以 check。拿 MS17-010 举例，use exploit/windows/smb/ms17_010_eternalblue 之后敲 check，msf 会发探测包判断目标是否存在漏洞，返回 The target is vulnerable 或者 The target is not exploitable。这比直接 exploit 安全得多，不会因为打错了导致目标蓝屏。

但坑在于，不是每个 exploit 模块都实现了 check。你敲下去可能返回 Check failed: The state could not be determined。这时候别硬打，换辅助扫描模块交叉验证。我一般会同时开两个终端，一个跑 auxiliary/scanner/smb/smb_ms17_010，另一个跑 exploit 的 check，两边结果对上了再动手。

数据库联动：别让扫描结果散落一地

msf 连上 PostgreSQL 之后，db_nmap 的结果会自动存进数据库。这时候 hosts 看主机列表，services 看端口和服务，vulns 看已知漏洞。关键是 vulns 这张表——只有当你跑了带漏洞检测的模块，结果才会写进去。单纯 nmap 扫描不会生成漏洞记录。

我通常的流程是：db_nmap -sV -O -p- 目标 先铺一遍，然后 services -u 看哪些端口值得深挖。比如看到 8080 上跑着 Tomcat 7.0.81，直接 search tomcat 7 找对应模块，跑完 vulns 里就会多出几条记录。hosts -R 还能把有漏洞的主机直接塞进 RHOSTS，省得手动填。

一个真实的翻车案例

去年给一家公司做内网测试，nmap 扫到一台 Windows Server 2008 R2，445 开着。我直接上了 ms17_010 的 exploit，check 返回 vulnerable，exploit 也拿到了 system shell。但客户后来反馈那台机器上有 legacy 业务系统，蓝屏了两次。问题出在哪？check 只判断了漏洞存在，没判断系统稳定性。那台机器内存占用常年 90% 以上，永恒之蓝的利用过程本身就会触发内核崩溃。

后来我改了习惯：check 通过之后，先看目标的内存和 CPU 负载。msf 里可以用 auxiliary/scanner/smb/smb_enumshares 之类的模块先摸一下系统状态，或者干脆用 post/windows/gather/ 下的模块做信息收集。漏洞扫描不只是找入口，还得评估打进去的代价。

msf 的扫描能力说到底就一句话：把 nmap 的指纹、auxiliary 的探测、exploit 的 check 串起来用，别指望一个模块解决所有问题。数据库开着，结果存着，交叉验证着，比什么都强。