简介FindPass是一款用于Windows NT4/2000系统的密码查询工具面向系统管理员与安全测试人员。它利用调试特权读取winlogon进程内存依据明文存储的域名与用户名定位对应登录会话进而解密出用户口令适用于管理员忘记本地账户密码或进行内网渗透测试的场景。资源共5个文件压缩包仅106KB其中包含FindPass.exe与pulist.exe两个可执行程序、FindPass.cpp完整C源码、readme说明文档及一张演示截图既可直接运行工具也可阅读源码理解Windows登录密码的内存存储与解码机制。工具支持通过pulist获取当前登录的用户名、域名与winlogon进程PID再对指定进程执行查找示例中成功恢复了测试账户的明文密码。目前已有793人学习下载适合需要掌握Windows认证机制或进行密码恢复研究的技术人员参考。1. 用户名密码查询工具 findpass先把漏网的明文账号捞出来做网络审计的人应该都有过这种经历拿到一个抓包文件明明知道里面某台设备的密码就是明文可翻包翻了半小时也没定位到那一条记录。findpass 就是解决这个问题的命令行工具它从 pcap、tshark 导出的流量字段文件或日志文本里把 HTTP Basic、FTP 登录、SMTP AUTH、表单 POST 中的用户名密码批量捞出来结果直接落成 JSON。适合网络管理员、应急响应人员和做内网安全评估的从业者使用尤其是对方还在用老系统、明文协议的场景。它的用法很简单一条命令就能出结果但真正决定提取效果的不是命令本身而是正则边界、编码识别、TCP 分片处理这些细节。下面从提取原理开始讲清楚再进入可复现的操作步骤。2. findpass 的提取原理协议特征匹配与正则边界的取舍2.1 抓包里哪些位置放着账号密码先明确一件事findpass 做的是明文凭证提取不是协议漏洞利用。它依赖的底层事实是FTP、Telnet、HTTP Basic 认证、SMTP AUTH 这些协议在传输过程中账号密码以固定格式出现在明文载荷里。只要 pcap 中对应协议的握手包被完整抓到账号密码就是可读的。常见的位置分三类FTP 登录命令客户端发USER root服务端回331客户端再发PASS 123456USER 和 PASS 一般相邻且在同一段载荷里。HTTP Basic 认证客户端在Authorization请求头里发Basic base64串解码后是用户名:密码。表单 POST 登录登录页面提交的键值对如usernameadminpassword123456通常出现在 TCP 的后续数据段中。Telnet 也常见它的格式更像交互式输入服务端提示login:客户端回用户名服务端提示Password:客户端回密码。由于没有统一的包边界提取难度更高findpass 默认的处理方式是把同一 TCP 连接的数据拼接后再匹配。《单独抓包看不到完整登录过程》是初用者最容易误判的点。只看单个数据包FTP 的 USER 和 PASS 可能被拆进两个包里表单 POST 的内容可能被中间代理重组成多段。所以 findpass 的核心逻辑不是逐包盲扫而是先做流窗口拼接再在拼接后的数据上跑正则。2.2 正则规则边界写严误报率才会低findpass 的正则全部基于字节串匹配也就是bytes类型避免文件编码干扰。下面是核心规则定义。import re # 各协议的识别规则统一用 bytes 匹配避免编码干扰 HTTP_BASIC re.compile( rbAuthorization:\s*Basic\s([A-Za-z0-9/]{4,}{0,2}), re.I ) FTP_LOGIN re.compile( rbUSER\s([^\s\r\n])\r?\nPASS\s([^\s\r\n])\r?\n, re.I ) FORM_POST re.compile( rb(?:username|user|account|login)([^\s]) rb(?:password|pass|pwd)([^\s]), re.I )第一组HTTP_BASIC匹配的是Authorization: Basic XXXXX。[A-Za-z0-9/]{4,}{0,2}这个结尾很重要base64 串最短也是 4 个字符且等号只出现在末尾、最多两个这样不会把后面的十六进制数据段吞进来。第二组FTP_LOGIN用了\r?\n兼容 Windows 和 Linux 下不同的换行风格。注意它要求 USER 和 PASS 在同一段连续数据里出现中间只允许\r?\n如果中间夹了服务端的331响应这条正则就不命中需要走流重组逻辑。第三组FORM_POST匹配键值对形式。键名覆盖了 username、user、account、login 这几种常见写法密码键覆盖了 password、pass、pwd。[^\s]定义值不包含和空白符防止跨字段误抓。每条正则看起来简单但去调过的项目里出现过不少翻车边界写宽了会把日志里的password***抓出来写窄了又漏掉真实凭证。经验是先把线上真实流量导几千行出来拿正则跑一遍看命中样例再决定放宽还是收紧。2.3 规则文件与参数不动主程序就能调匹配findpass 把正则规则和主程序拆开规则放在 JSON 文件里改匹配逻辑不用碰代码。{ http_basic: { pattern: Authorization:\\s*Basic\\s([A-Za-z0-9/]{4,}{0,2}), ignore_case: true, extract: base64_colon }, ftp_login: { pattern: USER\\s([^\\s\\r\\n])\\r?\\nPASS\\s([^\\s\\r\\n])\\r?\\n, ignore_case: true, extract: two_groups }, form_post: { pattern: (?:username|user|account|login)([^\\s])(?:password|pass|pwd)([^\\s]), ignore_case: true, extract: two_groups } }主程序启动时读这个文件把 pattern 编译成正则。extract字段告诉程序怎么解析捕获组base64_colon表示第一组是 base64 串解码后按冒号拆账号密码two_groups表示第一组是用户、第二组是密码。命令行参数按使用频率设计参数作用默认值--rules指定规则文件路径rules.json--min-len账号或密码最小长度过滤单字符误报1--reassemble开启流窗口拼接处理跨包凭证关闭--window-size单条流拼接窗口大小单位字节65536--output结果输出路径findpass_result.json--top只输出结果的前 N 条全部输出--reassemble这个参数后面会单独讲它解决的是 TCP 分片导致的漏报属于高频开关。3. 跑通第一次提取环境准备、tshark 导出与命令输出3.1 环境准备Python 与 tshark 命令行findpass 是 Python 3 脚本不依赖第三方库标准库里的 re、json、argparse、base64 就够用。另外需要准备 tshark 命令行工具它负责把 pcap 转成 findpass 能读的字段文本。# Debian/Ubuntu 系的常见安装方式 sudo apt update sudo apt install -y python3 tshark装完后验证两个工具都在python3 --version tshark -v注意 tshark 在部分发行版安装后普通用户抓包需要加入 wireshark 用户组否则会提示权限不足。常见做法是sudo usermod -aG wireshark $USER然后重新登录终端。Windows 上安装 Wireshark 时勾选 Tools 组件即可tshark.exe 在安装目录下。有一点值得提前说这里选择用 tshark 导出字段文件而不是让 findpass 直接解析 pcap。原因之一是 pcapng 容器格式比经典 pcap 复杂不同抓包工具生成的文件头有差异直接解析很容易翻车原因之二是 tshark 能顺便做协议过滤把无关流量挡在源头。3.2 用 tshark 导出流量字段抓包文件拿到手后先导出 TCP 载荷。下面的命令把每个 TCP 包的时间、来源 IP、目标 IP、端口、载荷十六进制数据导出为 Tab 分隔的文本文件。tshark -r dump.pcap -Y tcp.payload -T fields \ -e frame.time \ -e ip.src -e ip.dst \ -e tcp.srcport -e tcp.dstport \ -e data.data export.tsv各字段含义frame.time是包的捕获时间ip.src和ip.dst是通信双方tcp.srcport和tcp.dstport是端口data.data是 TCP 载荷的十六进制字符串。-Y tcp.payload把没有载荷的 ACK 包过滤掉减小文件体积。如果抓包文件很大建议在导出阶段就限定端口。比如只关心 FTP 和 HTTPtshark -r dump.pcap -Y tcp.payload (tcp.port 21 || tcp.port 80) \ -T fields \ -e frame.time \ -e ip.src -e ip.dst \ -e tcp.srcport -e tcp.dstport \ -e data.data ftp_http_export.tsv导出完成后用wc -l看一下行数确认数据不是空的。我一般还会随机抽几行看下data.data是否为空因为有些抓包工具会丢载荷信息空的十六进制字段对提取没有意义。3.3 执行 findpass 提取凭证导出文件就绪后直接跑主脚本。python3 findpass.py export.tsv -o result.json --min-len 1正常输出类似这样[findpass] 共发现 12 条候选凭证 [findpass] 协议 http_basic: 5 条 [findpass] 协议 ftp: 6 条 [findpass] 协议 http_form: 1 条 2025-01-10 10:23:45 192.0.2.10:51000 - 192.0.2.20:21 [ftp] admin / ftp_pass_2025 2025-01-10 10:23:46 192.0.2.10:51002 - 192.0.2.30:80 [http_basic] admin / admin123每一行对应一条候选凭证包含时间、来源、目标、协议、用户名和密码。完整结果写入result.json里面是结构化数据方便后续用脚本处理。JSON 里每条记录的字段长这样{ line_no: 182, time: 2025-01-10 10:23:45, src: 192.0.2.10, dst: 192.0.2.20, sport: 51000, dport: 21, proto: ftp, username: admin, password: ftp_pass_2025 }line_no是导出文件中的行号方便回查原始包src和dst对应通信双方dport是服务端端口可以帮助判断这台设备在跑什么服务。3.4 结果去重与输出控制一次抓包里同一个账号密码可能出现在多条记录里比如 TCP 重传、同一客户端多次登录。去重直接决定结果表干不干净。findpass 内置的去重逻辑按五元组加凭证内容做键def dedup_items(items): seen set() for it in items: key ( it[src], it[dport], it[proto], it[username], it[password] ) if key not in seen: seen.add(key) yield it这里没有把目标地址dst放进键里因为同一个内网源 IP 访问不同服务器时如果密码相同合并成一条反而能看出账号复用问题。如果你需要区分目标机器把it[dst]加到元组里即可。--top参数适合在结果量很大的时候先用来看头部数据。实际审计中我会先跑一次全量去重然后按dport分组统计确认哪些端口上的凭证最多再决定优先验证哪一批。4. 换场景调优从 HTTP 表单到超大 pcap 的四个典型参数改动4.1 HTTP 表单场景URL 编码与键名差异表单 POST 的提取最容易出问题的是编码。页面提交时如果开启了 URL 编码密码里的特殊字符会变成%21这种形式直接按文本看是乱码匹配规则倒是能命中原始串但结果可读性差。常见做法是在提取后做一次 URL 解码from urllib.parse import unquote def decode_form_value(value): return unquote(value.replace(, ))把%21%40%23还原成!#把还原成空格。findpass 在--decode-form-values参数开启时会自动执行这一步。键名差异则是另一个高频问题。有的系统表单字段是user_name、passwd还有的是login、secret。遇到这种情况不用改主程序直接在 rules.json 的form_post正则里把替代分支加进去。4.2 FTP 和 Telnet 场景开启流重组前面提到FTP 的 USER 和 PASS 可能跨两个 TCP 段HTTP 表单也可能被分片。逐包匹配在这种情况下必然漏报解决开关是--reassemble。开启后findpass 按五元组把同一 TCP 流的载荷累积到一个窗口里再对窗口数据跑正则。窗口大小由--window-size控制默认 64KB。python3 findpass.py export.tsv --reassemble --window-size 65536 -o result.json流拼接的具体逻辑是每个五元组加方向维护一个字节缓冲新包载荷追加到缓冲尾部超长时只保留最后 N 字节。这样凭证出现在连接建立后的前几包时窗口里一定覆盖得到。窗口设太大会拖慢速度设太小又拼不齐跨多段的凭证64KB 对大多数登录流程来说是够用的。Telnet 比 FTP 更麻烦它的提示符和输入不是标准命令结构。开启--reassemble后findpass 在拼接数据里扫描login:和Password:提示符之间的内容但 Telnet 选项协商字节\xff开头的序列要提前过滤否则会把账号密码串冲乱。这部分在脚本里实现了strip_telnet_options函数def strip_telnet_options(data): # 去掉 Telnet 协议自带的 IAC 命令字节保留纯输入内容 clean bytearray() i 0 while i len(data): if data[i] 0xff: i 3 continue clean.append(data[i]) i 1 return bytes(clean)逻辑说明Telnet 的 IAC 字节是0xFF后面跟两个参数字节长度遇到就直接跳过避免0xFF干扰后续匹配。这个函数只在--telnet-strip-iac参数开启时生效。4.3 超大 pcap分片导出与降低内存2GB 的 pcap 文件直接整体导出tshark 会吃大量内存findpass 读入后也容易 OOM。实际项目里我不会一次压给脚本而是先按端口分片再循环导出。for f in /data/pcap/*.pcap; do tshark -r $f -Y tcp.payload tcp.port21 -T fields \ -e frame.time -e ip.src -e ip.dst \ -e tcp.srcport -e tcp.dstport -e data.data \ ftp_export.tsv done这样每个文件单独处理某个文件格式有问题不会拖垮整个过程。导出后如果 TSV 超过 200MB我还会按时间切分比如按小时拆成多个文件分批跑 findpass最后合并 JSON 结果。--reassemble在这种大文件场景下要慎开因为流缓冲全在内存里并发流多时会涨得很快。4.4 加密流量的边界与替代手段HTTPS、SSH、加密 RDP 这类流量在 findpass 里提取不到凭证这是协议限制不是工具缺陷。面对全加密抓包我一般会换两条路一是判断抓包环境是否可控如果流量经过自己的代理设备可以配置 SSL 解密后再重复提取二是放弃流量侧直接去服务端日志里查登录记录应用日志里往往有账号和登录结果。这个边界在实际项目中要提前和需求方说清楚免得跑完一次发现结果为空双方都无法收场。findpass 适合的场景是内网审计中还有明文协议的存量设备比如老的 FTP 服务器、测试环境的 HTTP 后台、打印机管理页面。5. 避坑指南findpass 使用中的五个典型翻车问题5.1 base64 串多吞字符导致解码乱码现象HTTP Basic 解出来是一串带\x00或明显截断的乱码账号密码混在一起。原因正则里的 base64 字符集没有约束长度把后续载荷里的十六进制字符也吃进来了解码结果里混入多余字节。解决把正则收紧为[A-Za-z0-9/]{4,}{0,2}并在解码后做两层校验解码结果必须包含冒号且长度不超过 256 字节。实际经验是多数 base64 凭证解码后长度不超过 128 字节超长的直接丢弃比硬猜更可靠。5.2 表单密码是 URL 编码或 UTF-16结果看着像乱码现象密码字段提取出来是%21%40%23或者中间全是\x00直接读不出明文。原因页面提交前走了 URL 编码或者服务端用 UTF-16 接收参数而 findpass 默认按 UTF-8 显示中文和特殊字符全被打乱。解决开启--decode-form-values做一次 URL 解码UTF-16 则需要先按utf-16-le解码再跑正则。遇到疑似编码问题时我一般先截一段十六进制数据手工解码确认编码方式再决定该开哪个开关。5.3 把 pcap 或 pcapng 直接喂给脚本导致解析失败现象脚本报错或导出结果为空程序提示文件头不认识。原因findpass 的输入设计为 tshark 导出的字段文本不是 pcap 本身。不同抓包工具生成的 pcapng 文件头差异很大直接解析必然翻车。解决统一先走 tshark 导出步骤把data.data转成字段文本再喂给 findpass。如果环境里没有 tshark也可以用 Wireshark 的导出对象功能手动导出但字段顺序要对齐。5.4 USER 和 PASS 不在同一个包里导致漏报现象FTP 登录流程清晰同一连接里先后有USER和PASS但提取结果为空。原因两个命令分别落在不同的 TCP 段里逐包匹配时正则要求USER ...\r\nPASS ...连在一起所以没命中。解决开启--reassemble流重组。如果重组后还是漏检查抓包文件是否丢包——抓包时如果交换机端口镜像带宽不足中间段缺失那是流量侧的问题不是工具能补的。5.5 把提取结果直接当成最终凭证库使用现象findpass 输出的 12 条凭证里有 5 条是内网设备自己发的心跳包内容根本不是账号。原因正则只保证格式匹配不保证语义正确。设备型号、固件版本、主机名出现在用户名位置并不罕见。解决提取结果只作为候选集验证工作不可省略。后面第 6 章会给出交叉验证的做法。6. 验证提取结果用响应码和流量特征交叉确认6.1 响应码探测法对每一组候选凭证可以构造一次真实登录请求看服务端响应码判断是否有效。HTTP 服务用 curl 就能完成curl -s -o /dev/null -w %{http_code} \ -u admin:admin123 \ http://192.0.2.20/admin响应码说明401 表示认证失败但服务在线200 表示登录成功403 表示账号有效但权限不足也算验证通过502 或 504 则说明目标服务异常结果不可信。FTP 服务可以用带账号密码的登录命令验证curl -s -o /dev/null -w %{ftp_code} \ ftp://admin:ftp_pass_2025192.0.2.20/所有验证必须在有明确授权的网络和设备上进行这条原则我每次都会写进给需求方的交付文档里。6.2 流量特征与时间戳交叉验证不是所有凭证都能现场探测比如目标已下线或端口已变更。这时回头翻流量本身的特征会更高效。同一组账号密码出现在多个源 IP 指向同一目标端口大概率是扫描行为或默认口令被批量尝试单条流里时间戳前后几秒内存在完整的三次握手和登录过程则更像是真实业务凭证。我常用的指标是多包一致性同一个账号密码在至少三组不同时间、不同源 IP 的流里命中候选可信度会明显上升。做完验证后我会把结果重新导出成一张去重表标注每条凭证的验证状态、来源文件和原始行号交给需求方复盘。从那以后我每次跑完 findpass 都强制走一遍响应码验证和流量特征检查确认无误才写进报告这个习惯帮我挡掉了不止一次误报返工。希望你拿这套脚本跑任务时也能少踩这些坑快速定位到真正需要的账号信息。本文还有配套的精品资源点击获取