Wireshark抓Telnet明文密码需先用显示过滤器（如tcp.port==23 && ip.addr==目标IP）定位流量，再右键Follow TCP Stream还原完整会话，用户名和密码以ASCII明文形式出现在TCP载荷中，中间含\r\n等控制符。
Wireshark抓Telnet明文密码：必须用显示过滤器定位TCP流
Wireshark本身不会自动高亮密码，它只是把原始字节流按协议结构展开。Telnet的用户名和密码是逐字符发送的，中间夹杂\r\n、^M等控制符，直接扫包列表根本找不到“password:”字样。
关键操作是：先用显示过滤器缩小范围，再用TCP流重组还原会话内容。
- 启动抓包前，确保目标主机已开启Telnet服务（
sudo apt install xinetd telnetd），且/etc/xinetd.d/telnet中disable = no - 抓包时使用过滤表达式：
tcp.port == 23 and ip.addr == 192.168.1.2（替换为目标IP） - 找到任意一个Telnet数据包 → 右键 → Follow → TCP Stream → 立刻看到完整交互，包括明文输入的用户名（如
admin\r\n）和密码（如123456\r\n） - 注意：如果看到乱码或空格断开，说明字符编码不一致，但ASCII可读部分（字母、数字、常见符号）仍清晰可见
FTP登录凭据在Wireshark里藏在哪几个包里
FTP控制连接（端口21）上，USER和PASS命令是分开发送的，不是在同一数据包里。很多人只搜pass却漏掉user，导致以为没抓到完整凭证。
正确做法是按时间顺序串联两个请求，而不是依赖关键词搜索。
- 用显示过滤器：
ftp.request.command == "USER" || ftp.request.command == "PASS" - 找到
USER包后，向下翻1–3个包，基本就是对应的PASS包（中间可能有331响应） - 点开
PASS包 → 展开FTP Request→ 查看Request argument字段，值就是明文密码（如myftp123） - 不要用
http或dns这类过滤器——FTP有自己的解析器，ftp才是有效协议关键字
为什么HTTPS和SSH在Wireshark里看不到密码，而Telnet/FTP可以
不是Wireshark能力不够，而是协议设计决定的：Telnet和FTP（未启用TLS）在应用层直接把认证信息作为纯文本塞进TCP payload；而HTTPS和SSH在传输前已加密，Wireshark拿到的只是密文块。
有人试图用SSLKEYLOGFILE解密HTTPS，但这需要浏览器配合导出密钥；SSH则根本不可行——OpenSSH不提供密钥导出接口，且密钥交换过程本身受保护。
- Telnet/FTP密码出现在Wireshark的
Frame→TCP→Data层级，十六进制区可直接看到ASCII字符串 - HTTPS密码在
Transport Layer Security字段下只有Encrypted Application Data，点不开 - SSH同理，
Secure Shell协议解析器只显示SSH Protocol头，payload为Unknown - 别浪费时间对SSH流量右键“Follow → SSH Stream”——这个选项根本不会出现
内网抓包发现明文密码后，下一步该做什么
发现不代表结束。真实渗透或安全评估中，重点不在“抓到了”，而在“怎么证明风险存在且可利用”。
最容易被忽略的是权限边界问题：你抓到的密码，是否真能用于进一步横向移动？比如Telnet密码是否对应管理员账户？FTP账号是否有写权限？
- 立即验证：用抓到的凭证尝试登录同一台设备的SSH（如果开放）、或访问其Web管理界面（常见默认端口80/443/8080）
- 检查FTP目录列表返回：如果
PASS后跟了LIST请求，且响应中包含drwxr-xr-x等权限位，说明该账号具备文件系统访问能力 - 导出凭证时禁用
File → Export Packet Dissections → As Plain Text——避免把敏感信息存成明文文件；改用Export Specified Packets仅保存含USER/PASS的少数几个包 - 记住：Wireshark抓到的是“已发生的通信”，不是实时监听器；如果目标刚改密码，旧会话里抓到的仍是旧凭证
