tcpdump -XX 可抓取明文账密，适用于HTTP、旧MySQL、Telnet等未加密协议，但对HTTPS/TLS无效；需配合-s0、指定端口及关键词过滤定位敏感信息。
直接用 tcpdump -XX 抓包看明文账密，本质是利用网络协议未加密的漏洞。它不适用于 HTTPS、TLS 加密或数据库启用了 SSL 的场景，但对 HTTP、MySQL 4.1 以下旧协议、Telnet、FTP（非 FTPS）、未加密的 Redis 连接等仍有效——这些协议在传输过程中会以明文形式暴露用户名、密码甚至 SQL 内容。
关键不是“能不能看到”，而是“在哪看、怎么看、看什么”。
用 -XX 捕获并定位明文凭证的实操要点
-XX 是 -X 的增强版：它不仅显示十六进制+ASCII（类似 Wireshark 的“Hex + ASCII”视图），还会额外打印数据链路层帧头（如 MAC 地址）和 IP/TCP 头的原始字节，这对确认协议栈层级、排除干扰包很有帮助。
但裸眼识别敏感信息，依赖三个条件：
- 流量本身未加密（明文协议）
- 抓包位置能覆盖通信路径（如在 DB 客户端、DB 服务端、或中间网关）
- 输出内容足够完整（需
-s0配合，否则截断导致看不到密码字段）
所以标准安全审计命令通常是：
sudo tcpdump -i eth0 -s0 -XX -n port 3306 or port 5432 or port 6379 or port 21 or port 23
注：
-n防止 DNS 解析拖慢输出；-s0确保抓全载荷；-XX提供完整帧视角；端口按目标服务选（MySQL=3306，PostgreSQL=5432，Redis=6379，FTP=21，Telnet=23）
明文账密在 -XX 输出中的典型特征
不同协议结构不同，但共性是：认证阶段的凭据常出现在 TCP 载荷起始段，且 ASCII 可读部分连续、语义明确
-
MySQL（旧协议，无 SSL）
登录握手包中，客户端发送的Handshake Response包含明文密码（经 scramble 加密但非不可逆，且用户名直接可见）。在-XX输出里，你会看到类似：0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 6164 6d69 6e00 0800 0000 0000 0000 0000 admin...........
→
6164 6d69 6e对应 ASCIIadmin（用户名），后面紧邻的可能是 scrambled 密码字节（不可读），但若协议版本极老（MySQL < 4.1），密码可能直接明文出现。 -
PostgreSQL（未启用
password_encryption = scram-sha-256或md5）StartupMessage后跟PasswordMessage，类型字节为'p'，其后紧跟明文密码字符串（ASCII 可见）：0x0040: 7000 0000 1575 7365 723d 7067 7573 6572 p....user=pguser 0x0050: 0070 6173 7377 6f72 643d 6d79 7365 6372 .password=mysecr 0x0060: 6574 0000 et..
→
user=pguser和password=mysecret直接可读。 -
Redis（未启用 AUTH 或 ACL）
AUTH命令后跟空格+密码，纯文本：0x0020: 2a31 0d0a 2434 0d0a 4155 5448 0d0a 2438 *1..$4..AUTH..$8 0x0030: 0d0a 6d79 7375 7065 720d 0a ..mysuper..
→
$4..AUTH是命令长度与指令，$8..mysuper就是密码明文。 FTP/Telnet
USER xxx/PASS yyy行在-XX中清晰可见，ASCII 区域一目了然。
安全审计时的避坑提醒
-
-XX输出默认不自动换行，长包容易漏看。建议配合less -S或重定向到文件后用grep -A 2 -B 2 'PASS\|password\|AUTH'快速定位。 - 不要仅靠关键词搜索：有些系统用 Base64 编码（如某些 API 认证头），需人工判断
Authorization: Basic xxx后的 base64 字符串是否可解。 -
-XX会显示整个帧（含以太网头、IP 头、TCP 头），真正敏感内容在 TCP payload 区域（即 ASCII 列右侧、十六进制列中靠后的可读部分），注意跳过前面协议头字节。 - 若发现疑似明文，务必验证是否真实有效：比如 MySQL 的
password=字段在新版协议中只是占位符，实际密码已哈希化；而 PostgreSQL 的password=出现在PasswordMessage类型包中才可信。
实际快速筛查建议（终端内一步到位）
# 抓 100 个包，保存并实时 grep 明文关键字（适合应急响应）
sudo tcpdump -i eth0 -s0 -XX -c 100 -n port 3306 or port 5432 or port 6379 | \
grep -i -E "(user=|pass=|password=|AUTH [[:print:]]{3,}|USER [[:print:]]+|PASS [[:print:]]+)" --color=always只要匹配到上述模式，再结合 -XX 上下文确认 ASCII 区域是否连续可读，基本可判定存在明文传输风险。
不复杂但容易忽略。
