简介WebCrack是一款开源免费的Web后台弱口令与万能密码批量爆破检测工具面向网站管理员、渗透测试与安全审计人员帮助定位后台登录弱口令漏洞、检验系统抗爆破能力适用于获得授权的合规测试场景。资源压缩包共18个文件核心为12个Python脚本分别承担字典生成、请求解析、爆破任务调度、日志记录等模块职责另有3个文本字典或配置、1份Markdown说明文档和1张界面示意图整体仅114KB轻量易用。已有406人学习下载用户还可借助开源代码按需二次开发。实际使用后可掌握密码字典构建、并发参数调整、目标URL设置及结果日志解读等操作要点快速发现后台弱口令与万能密码风险为安全加固提供依据。需注意此类批量爆破工具应严格限定在合法授权测试中避免对目标服务器造成压力或引发纠纷。1. Web 后台批量爆破不是“撞运气”拿 WebCrack 过一次弱口令矩阵Web 安全测试里有个很真实的现象不少 Web 后台不是被高精尖漏洞打下的而是被弱口令撞开的。admin/123456 这类组合在内部系统、测试环境、老版本 CMS 上到处都是。批量爆破就是把弱口令按优先级批量送到登录接口看哪一把钥匙能开门。WebCrack 正是做这件事的开源免费工具专攻 Web 后台弱口令与万能密码的批量爆破、检测。它解决的是最重复的劳动探测后台路径、尝试弱口令、尝试万能密码、落结果文件。原来手动要切换十几个标签页的活现在一条命令批量跑完适合授权渗透、运维巡检、上线前自查这三类人。使用边界必须先写明所有目标都必须提前拿到授权。后面写到的命令、并发、规避都以授权为前提这也是这条工具链里最不能含糊的一步。2. 先弄明白爆破逻辑再动手弱口令、万能密码与 WebCrack 的实现边界2.1 弱口令批量爆破本质是“按优先级穷举登录请求”很多人第一次拿到这类工具会把它想成黑匣子填个地址字典一扔就能撞出结果。实际没那么玄。弱口令批量爆破背后的逻辑分成三段先收集目标登录接口地址再构造请求把账号密码填进去最后分析响应判断这次有没有登录成功。WebCrack 做的是把这三步自动化并且通过并发、延时、超时参数把请求控制在目标能承受的范围内。这里首先要讲后台路径探测。你拿到一个站点可能只知道根域名不知道后台是 /admin、/wp-admin 还是 /manage。WebCrack 通常内置一份常见后台路径列表会先逐个请求探测把响应码为 200 且页面特征像登录页的路径挑出来再对这些路径批量尝试口令。这一步很关键因为弱口令哪怕再弱如果路径错了爆破根本无法触达登录接口。其次是登录请求的构造。很多后台登录接口的字段并不叫 username/password而是 loginName、pwd甚至走 JSON 接口。我一般会先用浏览器开发者工具抓一次真实登录请求确认接口地址、表单字段和 Cookie 规则填写进工具配置后再跑批量。跳过这一步直接跑结果基本不可信——这也是后面第 4 章第一个避坑点的核心来源。选型时还有一层要考虑的是并发控制。批量爆破不能单线程慢慢爬也不能无脑开 50 个线程砸一个目标。常见做法是先用 -t 5 到 -t 10 做一轮试探观察目标响应时间和验证码触发情况再决定要不要往上加。线程、间隔、超时这三个参数本质上决定了这轮爆破是在“做测试”还是在“砸站点”。2.2 万能密码不只是一条 SQLWebCrack 怎么把注入测成“能进系统”万能密码这个词很多搜索场景会跟“sql注入万能密码绕过”绑定。实际测试里有两条路线一条是构造能让 SQL 恒真的注入语句比如把密码字段写成 admin OR 11让服务端校验逻辑直接短路另一条是找“前端校验后端不校验”的接口缺陷在参数里塞特殊值让登录判定失效。WebCrack 在做这项检测时关键不是只发一条 payload而是要判定这次请求到底有没有跨进后台。从实现上看这类工具通常把万能密码 payload 内置成一份字典每条 payload 都作为密码尝试登录。为了避免误报登录成功的判定会设两道关卡第一道看状态码有没有从 401/200 变成 302/200第二道看响应体里是否出现“退出”“后台首页”“用户中心”这类登录后才有的特征词。WebCrack 属于偏响应结果判断的风格这也是后面误报排查看起来麻烦、但误报可控的原因。# 万能密码请求的简化示意同一 payload 被替换进密码字段 payload_or admin OR 11 resp s.post(login_url, data{ username: admin, password: payload_or, action: login }) print(resp.status_code, resp.url) if 退出 in resp.text or resp.url ! login_url: print(疑似绕过成功)逻辑说明这里用 requests 会话对象 s 模拟一次登录请求把注入 payload 放进密码字段。判定条件是两个响应状态码是否落在预期范围以及响应文本里是否出现后台特征词。单看 status_code 是不够的很多框架就算登录失败也返回 200。参数说明payload 里11这种写法是经典恒真表达式实际目标如果加了参数化查询这条会失效所以工具里通常还会带admin--、admin#、) OR (11之类的变体。payload 越多越容易误报这也是为什么后面第 4 章会把“二次请求后台首页”当作人工复核的必做动作。2.3 与同类工具的边界什么时候用超级弱口令工具箱什么时候用 WebCrack搜索“弱口令爆破”的时候很容易看到“超级弱口令工具超级字典”这一类条目它们和 WebCrack 是两层东西。超级弱口令工具箱主要面向 FTP、SSH、RDP 这类服务协议的账号爆破检测的是协议层弱口令操作偏图形化字典以服务账号为重心。WebCrack 的输入面是 HTTP 登录接口面向 Web 后台两者检测对象有重叠但发力点完全不同。另一个常被拉出来对比的是 sqlmap。sqlmap 是专业 SQL 注入检测工具能精确判断注入类型和利用条件WebCrack 做的是登录弱口令加轻量注入绕过它不会告诉你这次是时间盲注还是联合注入只会告诉你“这组账号密码能不能进”。实际测试中我通常先让 WebCrack 跑弱口令和万能密码筛出能直接进的筛不出的再交给 sqlmap 做更细的注入审计。工具类型典型工具检测面适合场景服务弱口令检查超级弱口令工具箱SSH、FTP、RDP 等协议服务器账号审计Web 登录弱口令爆破WebCrackHTTP 登录接口后台批量检测SQL 注入深度检测sqlmap注入点与注入类型漏洞细节确认选型判断我一般按三步走先确认被测对象是协议服务还是 Web 登录页协议服务用前者Web 后台用 WebCrack再看有没有已知的注入点有就把 sqlmap 排进来最后看目标数量几十个 Web 后台一起扫的时候WebCrack 这种轻量批量工具性价比最高。如果是本地搭的 Web 靶场做练习同样可以拿这套工具练手靶场环境里随便扫也不担心越界。3. 把一条命令跑通到出报告WebCrack 的安装、参数与批量输出3.1 环境准备与启动Python 3 让依赖一次装齐WebCrack 这类工具大多基于 Python 3 编写核心依赖是 requests 这个 HTTP 库。拿到源码包后先解压到工作目录再把依赖装上。常见做法是建一个虚拟环境避免和系统里其他安全工具打架。# 进入源码目录后先建虚拟环境再装依赖 cd webcrack python3 -m venv venv source venv/bin/activate pip install -r requirements.txt python webcrack.py --help逻辑说明前三行创建并激活独立 Python 环境pip 按 requirements.txt 把 requests、colorama 这类依赖装进去。最后一条--help不是为了扫描而是验证工具能正常启动同时看当前版本支持哪些参数。参数说明venv 是虚拟环境目录名可以随意起。如果启动时报“没有 --help 这个参数”说明入口脚本名不一定是 webcrack.py常见做法是 ls 看目录里有没有 main.py 或 run.py替换入口文件名即可。依赖缺什么就补什么pip install requests colorama能覆盖大部分报错场景。3.2 单目标检测的最小参数集先手动探登录接口再开跑批量之前强烈建议先对单个目标做一轮探测。原因前面说过登录接口的字段名、提交方式、Cookie 规则都不一样先把单点跑通批量结果才可信。# 单目标模式-u 指向后台登录页 # -U 指定一个待爆破账号-P 指定密码字典文件 # -t 1 是单线程先不加并发方便观察请求行为 python webcrack.py -u http://192.168.1.20/admin/login.php \ -U admin -P ./dicts/top100.txt \ -t 1 -o ./single_result.txt逻辑说明-U和-P组成账号/密码组合-o指定结果文件-t 1让请求一个个发避免第一次跑就把目标冲垮。如果登录页有验证码这一步多半直接失败此时不要急着加线程先看是不是要配置 Cookie 预请求。参数说明-u尽量指向 login.php、admin.php 这类提交地址而不是站点首页。密码字典每行一条工具按行读取内置字典常见的顺序是 123456、admin、123456789 这类高频弱口令如果你有几条特别有把握的密码可以单独做一个小字典优先喂进去。常用参数可以先用一张表记下来批量场景还会用到其中几个参数作用典型值说明-u单个目标 URL/admin/login.php登录接口地址-f目标列表文件targets.txt每行一个目标-U爆破账号admin可重复指定多个账号-P密码字典pwd.txt每行一条密码-t并发数5-10单目标试探用 1-d请求间隔秒1-3防止触发频率限制-o输出文件result.txt保存命中结果3.3 字典策略内置字典、自定义字典与优先级爆破效果一半靠工具一半靠字典。如果内置字典只有几十条常见弱口令批量扫真实目标时命中率会低得让人怀疑人生。常见做法是工具内置一份按出现频率排序的弱口令字典同时允许外部指定自定义字典并且自定义字典的优先级更高。# 自定义密码字典 pwd_custom.txt一行一条 admin 123456 admin888 Admin123 2025admin逻辑说明自定义字典会优先于内置字典执行工具先把自定义字典里的密码试完再继续内置字典。这样做的目的是让有情报依据的密码先跑提高命中效率而不是上来就空跑十几万条大字典。参数说明字典文件按行分割即可不需要额外格式。注意一个细节有些工具会去掉字典行首尾的空格所以密码行里不要留多余空格避免密码被截断后跟实际口令对不上。我平时会准备三份字典top100 用于大体量目标快速筛选top1000 用于重点目标再维护一份“站点特征字典”把目标域名前缀、年份组合、公司缩写预生成好。实际效果比盲目堆几百万条大字典好得多。3.4 批量目标文件与结果输出命中列表与请求日志单点跑通后批量就是喂目标列表。这里有一个习惯建议尽量提供后台登录页的完整 URL而不是根域名。只给根域名的话工具要先做路径探测每个目标多出几十次请求批量耗时会被明显放大。# targets_batch.txt每行一个待测后台登录页 http://192.168.1.20/admin/login.php https://app.example.com/manage/login https://demo.example.org/wp-admin/ # 批量模式-f 接目标列表-t 10 并发-d 2 每次请求延迟 2 秒 python webcrack.py -f ./targets_batch.txt \ -t 10 -d 2 -o ./output/result.txt逻辑说明-f与单目标参数-u二选一。批量模式下工具对每个 URL 依次执行弱口令与万能密码检测某个目标超时或连不上会被记到失败列表里而不是中断整个任务。这是批量工具的基本要求不然一个目标掉线后面全部卡住。参数说明-d 2代表每个请求间隔 2 秒对外部目标建议不低于 1内网测试环境可以降到 0 但要接受日志量翻倍。-o输出的 result.txt 每行记录 URL、账号、密码、状态码命中条目还会带一列响应特征词方便后续人工复核。批量跑的时候我习惯把终端输出重定向一份到日志文件工具出问题也能回溯当时每个请求的状态。跑完不要只看命中列表还要看失败列表里哪些目标响应码是 401/403哪些是超时。前者说明目标存在但口令未命中后者说明网络或目标侧有限制机制。这些信息直接决定下一轮要不要加字典、调并发、换策略。4. 批量爆破最容易翻车的五个现场排查与避坑记录4.1 现象目标明明存在弱口令结果一条都没爆出来表现是单目标测试跑完后报告一条命中都没有但手动登录 admin/123456 却能进后台。原因登录接口有前置校验最常见的是必须先 GET 一次登录页拿到临时 Cookie工具却直接 POST 提交登录请求服务端判定会话非法返回未授权或 302 弹回登录页。工具依据响应判断失败自然一条都爆不出来。解决先手动复现一次正常登录流程在浏览器开发者工具的 Network 面板里看登录成功需要携带哪些 Cookie 和表单字段然后把 Cookie 初始化逻辑配置进工具。常见做法是给目标开一个“预请求配置”让工具先 GET 登录页存下 Cookie再开始爆破。这样弱口令能爆出来万能密码检测也更接近真实条件。4.2 现象批量跑到一半整个来源 IP 被目标封掉表现是一开始正常跑了几十个目标后大量请求超时或返回 403最后连正常访问都进不去。原因并发开得太大请求频率太高目标侧的 WAF 或访问控制把来源 IP 加进了临时黑名单。这种翻车在批量扫生产环境时经常出现。解决把并发降到 5 以下、请求间隔提到 2 到 3 秒、单请求超时控制在 10 秒以内。另一个惯用做法是主动拆批每批 5 个目标批与批之间停一分钟一旦发现连续 403 立即停跑等几分钟再续。续跑不要从头跑从失败列表里挑未完成目标继续即可已扫过的不会重跑。如果目标是云 WAF 场景最好再确认一下流量出口 IP 是否有针对网关的频率限制。4.3 现象万能密码检测误报率高到一半以上表现是报告里一大片命中人工复核却发现绝大多数根本无法登录。原因判定逻辑把“请求成功”当成了“登录成功”。很多登录接口不管密码对不对都会返回 302 跳转工具把每个 302 都记成命中或者响应体出现“账号已被锁定”这类提示工具仍然按成功登记。解决改成两步判定。第一步看登录请求的状态码和跳转落点第二步用刚刚返回的会话去请求一次后台首页如果首页返回 200 且响应文本包含“退出”“后台管理”“欢迎”这类特征词才确认命中。WebCrack 输出里保留响应特征词这一列就是为了给人做这层复核用的不要只看状态码。4.4 现象字典文件很大跑到一半像卡死一样表现是进度条停住日志文件十几分钟没有新增记录看起来像死机。原因不是机器卡死是任务队列被阻塞。并发开得大、字典又大请求堆积成百万级队列或者目标网络不稳定大量请求等待超时线程被超时等待占满后续任务全部排队。解决把并发调低把超时调短。我一般把单请求超时控制在 8 到 10 秒重试次数设为 0 或 1宁丢不拖。判断是不是假死就看日志文件最近 5 分钟有没有新增内容没有就是在空转这时不要硬等中断后保留已完成结果再按失败列表续跑。跑大字典前也建议先用 top100 做一轮预筛能少走很多弯路。4.5 现象报告显示命中手工复测却提示密码过期或验证码拦截表现是工具报告里写着 admin/123456 命中手动登录却提示密码已失效或者弹出验证码无法继续。原因两种可能。第一种是目标账号有定期改密策略工具扫到的口令是历史弱口令当前已失效第二种是爆破频率触发了风控目标侧插入了验证码后续请求全部被拦。解决区分处理。如果是密码过期在复测结果里注明“不可用”不要当作可利用漏洞上报如果是验证码触发把命中目标单独挑出来拉大请求间隔或暂停几分钟再手动登录确认一次。出现这种现场时报告结论要写清楚弱口令存在但当前不可用建议目标侧尽快强制改密。5. 读完报告别急着收工把命中结果手工复核成“可交付证据”再继续5.1 手工复核用 curl 重放登录并确认会话有效性批量工具给出的命中列表只是候选能不能写进交付报告必须人工在命令行或浏览器里复现一次。我的习惯是用 curl 重放登录请求把请求头、Cookie、响应内容完整留档当作证据链的一部分。# 重放登录请求带上工具命中时记录的账号密码 curl -i -s -c cookies.txt \ -d usernameadminpassword123456actionlogin \ -e http://192.168.1.20/admin/login.php \ http://192.168.1.20/admin/login.php # 第二步带 Cookie 请求后台首页确认没有跳回登录页 curl -s -b cookies.txt -L \ http://192.168.1.20/admin/index.php -o page.html head -n 30 page.html逻辑说明第一条命令用-c保存会话 Cookie-e模拟来源页按工具命中时的表单字段重放登录第二条命令携带 Cookie 请求后台首页如果返回 200 且包含后台特征词说明会话有效。head -n 30是快速看一眼响应内容不需要从头到尾读一遍 HTML。参数说明-d里的字段必须和工具命中时的表单配置一致否则重放结果不准-L跟随跳转后如果最终停留在登录页而不是后台首页说明 Cookie 没有通过鉴权这条候选要备注“无法验证”。写报告时我会把这两步的响应码和关键响应体片段一并贴进去客户复核也方便。5.2 把新后台路径、新密码沉淀进规则下一轮更省事爆破一轮之后最有价值的隐藏产出其实是目标侧的信息积累哪些后台路径不在内置列表里、哪些账号组合在实测里频繁出现、密码里有没有年份或编号规律。这些信息应该回收进下一轮的字典和路径规则而不是扫完就丢。常见做法是维护一份私有后台路径清单每轮批量后把新发现的路径同步进去密码词条同样按域名前缀、当前年份、常见弱口令变体预生成追加到自定义字典。几轮之后这套配置会越来越贴近实际目标特征命中率比通用字典高出一截。做这件事的时候我习惯同时把误报样本收集起来反向补充到“响应特征词”黑名单里让工具的判定规则越用越准。从那以后我每次跑 WebCrack 都会强制走一遍三段流程先确认授权范围再手动探一次登录请求格式最后分小批量试探并发。报告里凡是写“存在弱口令”的条目都必须有 curl 重放加 Cookie 鉴权成功这两条证据否则不算数。这个习惯救过我很多次也让我在交付时少被追问“这个命中到底能不能登录”。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/8 15:49:35 · 阅读 1.2k Web后台批量爆破实战：弱口令检测与万能密码绕过指南
简介WebCrack是一款开源免费的Web后台弱口令与万能密码批量爆破检测工具面向网站管理员、渗透测试与安全审计人员帮助定位后台登录弱口令漏洞、检验系统抗爆破能力适用于获得授权的合规测试场景。资源压缩包共18个文件核心为12个Python脚本分别承担字典生成、请求解析、爆破任务调度、日志记录等模块职责另有3个文本字典或配置、1份Markdown说明文档和1张界面示意图整体仅114KB轻量易用。已有406人学习下载用户还可借助开源代码按需二次开发。实际使用后可掌握密码字典构建、并发参数调整、目标URL设置及结果日志解读等操作要点快速发现后台弱口令与万能密码风险为安全加固提供依据。需注意此类批量爆破工具应严格限定在合法授权测试中避免对目标服务器造成压力或引发纠纷。1. Web 后台批量爆破不是“撞运气”拿 WebCrack 过一次弱口令矩阵Web 安全测试里有个很真实的现象不少 Web 后台不是被高精尖漏洞打下的而是被弱口令撞开的。admin/123456 这类组合在内部系统、测试环境、老版本 CMS 上到处都是。批量爆破就是把弱口令按优先级批量送到登录接口看哪一把钥匙能开门。WebCrack 正是做这件事的开源免费工具专攻 Web 后台弱口令与万能密码的批量爆破、检测。它解决的是最重复的劳动探测后台路径、尝试弱口令、尝试万能密码、落结果文件。原来手动要切换十几个标签页的活现在一条命令批量跑完适合授权渗透、运维巡检、上线前自查这三类人。使用边界必须先写明所有目标都必须提前拿到授权。后面写到的命令、并发、规避都以授权为前提这也是这条工具链里最不能含糊的一步。2. 先弄明白爆破逻辑再动手弱口令、万能密码与 WebCrack 的实现边界2.1 弱口令批量爆破本质是“按优先级穷举登录请求”很多人第一次拿到这类工具会把它想成黑匣子填个地址字典一扔就能撞出结果。实际没那么玄。弱口令批量爆破背后的逻辑分成三段先收集目标登录接口地址再构造请求把账号密码填进去最后分析响应判断这次有没有登录成功。WebCrack 做的是把这三步自动化并且通过并发、延时、超时参数把请求控制在目标能承受的范围内。这里首先要讲后台路径探测。你拿到一个站点可能只知道根域名不知道后台是 /admin、/wp-admin 还是 /manage。WebCrack 通常内置一份常见后台路径列表会先逐个请求探测把响应码为 200 且页面特征像登录页的路径挑出来再对这些路径批量尝试口令。这一步很关键因为弱口令哪怕再弱如果路径错了爆破根本无法触达登录接口。其次是登录请求的构造。很多后台登录接口的字段并不叫 username/password而是 loginName、pwd甚至走 JSON 接口。我一般会先用浏览器开发者工具抓一次真实登录请求确认接口地址、表单字段和 Cookie 规则填写进工具配置后再跑批量。跳过这一步直接跑结果基本不可信——这也是后面第 4 章第一个避坑点的核心来源。选型时还有一层要考虑的是并发控制。批量爆破不能单线程慢慢爬也不能无脑开 50 个线程砸一个目标。常见做法是先用 -t 5 到 -t 10 做一轮试探观察目标响应时间和验证码触发情况再决定要不要往上加。线程、间隔、超时这三个参数本质上决定了这轮爆破是在“做测试”还是在“砸站点”。2.2 万能密码不只是一条 SQLWebCrack 怎么把注入测成“能进系统”万能密码这个词很多搜索场景会跟“sql注入万能密码绕过”绑定。实际测试里有两条路线一条是构造能让 SQL 恒真的注入语句比如把密码字段写成 admin OR 11让服务端校验逻辑直接短路另一条是找“前端校验后端不校验”的接口缺陷在参数里塞特殊值让登录判定失效。WebCrack 在做这项检测时关键不是只发一条 payload而是要判定这次请求到底有没有跨进后台。从实现上看这类工具通常把万能密码 payload 内置成一份字典每条 payload 都作为密码尝试登录。为了避免误报登录成功的判定会设两道关卡第一道看状态码有没有从 401/200 变成 302/200第二道看响应体里是否出现“退出”“后台首页”“用户中心”这类登录后才有的特征词。WebCrack 属于偏响应结果判断的风格这也是后面误报排查看起来麻烦、但误报可控的原因。# 万能密码请求的简化示意同一 payload 被替换进密码字段 payload_or admin OR 11 resp s.post(login_url, data{ username: admin, password: payload_or, action: login }) print(resp.status_code, resp.url) if 退出 in resp.text or resp.url ! login_url: print(疑似绕过成功)逻辑说明这里用 requests 会话对象 s 模拟一次登录请求把注入 payload 放进密码字段。判定条件是两个响应状态码是否落在预期范围以及响应文本里是否出现后台特征词。单看 status_code 是不够的很多框架就算登录失败也返回 200。参数说明payload 里11这种写法是经典恒真表达式实际目标如果加了参数化查询这条会失效所以工具里通常还会带admin--、admin#、) OR (11之类的变体。payload 越多越容易误报这也是为什么后面第 4 章会把“二次请求后台首页”当作人工复核的必做动作。2.3 与同类工具的边界什么时候用超级弱口令工具箱什么时候用 WebCrack搜索“弱口令爆破”的时候很容易看到“超级弱口令工具超级字典”这一类条目它们和 WebCrack 是两层东西。超级弱口令工具箱主要面向 FTP、SSH、RDP 这类服务协议的账号爆破检测的是协议层弱口令操作偏图形化字典以服务账号为重心。WebCrack 的输入面是 HTTP 登录接口面向 Web 后台两者检测对象有重叠但发力点完全不同。另一个常被拉出来对比的是 sqlmap。sqlmap 是专业 SQL 注入检测工具能精确判断注入类型和利用条件WebCrack 做的是登录弱口令加轻量注入绕过它不会告诉你这次是时间盲注还是联合注入只会告诉你“这组账号密码能不能进”。实际测试中我通常先让 WebCrack 跑弱口令和万能密码筛出能直接进的筛不出的再交给 sqlmap 做更细的注入审计。工具类型典型工具检测面适合场景服务弱口令检查超级弱口令工具箱SSH、FTP、RDP 等协议服务器账号审计Web 登录弱口令爆破WebCrackHTTP 登录接口后台批量检测SQL 注入深度检测sqlmap注入点与注入类型漏洞细节确认选型判断我一般按三步走先确认被测对象是协议服务还是 Web 登录页协议服务用前者Web 后台用 WebCrack再看有没有已知的注入点有就把 sqlmap 排进来最后看目标数量几十个 Web 后台一起扫的时候WebCrack 这种轻量批量工具性价比最高。如果是本地搭的 Web 靶场做练习同样可以拿这套工具练手靶场环境里随便扫也不担心越界。3. 把一条命令跑通到出报告WebCrack 的安装、参数与批量输出3.1 环境准备与启动Python 3 让依赖一次装齐WebCrack 这类工具大多基于 Python 3 编写核心依赖是 requests 这个 HTTP 库。拿到源码包后先解压到工作目录再把依赖装上。常见做法是建一个虚拟环境避免和系统里其他安全工具打架。# 进入源码目录后先建虚拟环境再装依赖 cd webcrack python3 -m venv venv source venv/bin/activate pip install -r requirements.txt python webcrack.py --help逻辑说明前三行创建并激活独立 Python 环境pip 按 requirements.txt 把 requests、colorama 这类依赖装进去。最后一条--help不是为了扫描而是验证工具能正常启动同时看当前版本支持哪些参数。参数说明venv 是虚拟环境目录名可以随意起。如果启动时报“没有 --help 这个参数”说明入口脚本名不一定是 webcrack.py常见做法是 ls 看目录里有没有 main.py 或 run.py替换入口文件名即可。依赖缺什么就补什么pip install requests colorama能覆盖大部分报错场景。3.2 单目标检测的最小参数集先手动探登录接口再开跑批量之前强烈建议先对单个目标做一轮探测。原因前面说过登录接口的字段名、提交方式、Cookie 规则都不一样先把单点跑通批量结果才可信。# 单目标模式-u 指向后台登录页 # -U 指定一个待爆破账号-P 指定密码字典文件 # -t 1 是单线程先不加并发方便观察请求行为 python webcrack.py -u http://192.168.1.20/admin/login.php \ -U admin -P ./dicts/top100.txt \ -t 1 -o ./single_result.txt逻辑说明-U和-P组成账号/密码组合-o指定结果文件-t 1让请求一个个发避免第一次跑就把目标冲垮。如果登录页有验证码这一步多半直接失败此时不要急着加线程先看是不是要配置 Cookie 预请求。参数说明-u尽量指向 login.php、admin.php 这类提交地址而不是站点首页。密码字典每行一条工具按行读取内置字典常见的顺序是 123456、admin、123456789 这类高频弱口令如果你有几条特别有把握的密码可以单独做一个小字典优先喂进去。常用参数可以先用一张表记下来批量场景还会用到其中几个参数作用典型值说明-u单个目标 URL/admin/login.php登录接口地址-f目标列表文件targets.txt每行一个目标-U爆破账号admin可重复指定多个账号-P密码字典pwd.txt每行一条密码-t并发数5-10单目标试探用 1-d请求间隔秒1-3防止触发频率限制-o输出文件result.txt保存命中结果3.3 字典策略内置字典、自定义字典与优先级爆破效果一半靠工具一半靠字典。如果内置字典只有几十条常见弱口令批量扫真实目标时命中率会低得让人怀疑人生。常见做法是工具内置一份按出现频率排序的弱口令字典同时允许外部指定自定义字典并且自定义字典的优先级更高。# 自定义密码字典 pwd_custom.txt一行一条 admin 123456 admin888 Admin123 2025admin逻辑说明自定义字典会优先于内置字典执行工具先把自定义字典里的密码试完再继续内置字典。这样做的目的是让有情报依据的密码先跑提高命中效率而不是上来就空跑十几万条大字典。参数说明字典文件按行分割即可不需要额外格式。注意一个细节有些工具会去掉字典行首尾的空格所以密码行里不要留多余空格避免密码被截断后跟实际口令对不上。我平时会准备三份字典top100 用于大体量目标快速筛选top1000 用于重点目标再维护一份“站点特征字典”把目标域名前缀、年份组合、公司缩写预生成好。实际效果比盲目堆几百万条大字典好得多。3.4 批量目标文件与结果输出命中列表与请求日志单点跑通后批量就是喂目标列表。这里有一个习惯建议尽量提供后台登录页的完整 URL而不是根域名。只给根域名的话工具要先做路径探测每个目标多出几十次请求批量耗时会被明显放大。# targets_batch.txt每行一个待测后台登录页 http://192.168.1.20/admin/login.php https://app.example.com/manage/login https://demo.example.org/wp-admin/ # 批量模式-f 接目标列表-t 10 并发-d 2 每次请求延迟 2 秒 python webcrack.py -f ./targets_batch.txt \ -t 10 -d 2 -o ./output/result.txt逻辑说明-f与单目标参数-u二选一。批量模式下工具对每个 URL 依次执行弱口令与万能密码检测某个目标超时或连不上会被记到失败列表里而不是中断整个任务。这是批量工具的基本要求不然一个目标掉线后面全部卡住。参数说明-d 2代表每个请求间隔 2 秒对外部目标建议不低于 1内网测试环境可以降到 0 但要接受日志量翻倍。-o输出的 result.txt 每行记录 URL、账号、密码、状态码命中条目还会带一列响应特征词方便后续人工复核。批量跑的时候我习惯把终端输出重定向一份到日志文件工具出问题也能回溯当时每个请求的状态。跑完不要只看命中列表还要看失败列表里哪些目标响应码是 401/403哪些是超时。前者说明目标存在但口令未命中后者说明网络或目标侧有限制机制。这些信息直接决定下一轮要不要加字典、调并发、换策略。4. 批量爆破最容易翻车的五个现场排查与避坑记录4.1 现象目标明明存在弱口令结果一条都没爆出来表现是单目标测试跑完后报告一条命中都没有但手动登录 admin/123456 却能进后台。原因登录接口有前置校验最常见的是必须先 GET 一次登录页拿到临时 Cookie工具却直接 POST 提交登录请求服务端判定会话非法返回未授权或 302 弹回登录页。工具依据响应判断失败自然一条都爆不出来。解决先手动复现一次正常登录流程在浏览器开发者工具的 Network 面板里看登录成功需要携带哪些 Cookie 和表单字段然后把 Cookie 初始化逻辑配置进工具。常见做法是给目标开一个“预请求配置”让工具先 GET 登录页存下 Cookie再开始爆破。这样弱口令能爆出来万能密码检测也更接近真实条件。4.2 现象批量跑到一半整个来源 IP 被目标封掉表现是一开始正常跑了几十个目标后大量请求超时或返回 403最后连正常访问都进不去。原因并发开得太大请求频率太高目标侧的 WAF 或访问控制把来源 IP 加进了临时黑名单。这种翻车在批量扫生产环境时经常出现。解决把并发降到 5 以下、请求间隔提到 2 到 3 秒、单请求超时控制在 10 秒以内。另一个惯用做法是主动拆批每批 5 个目标批与批之间停一分钟一旦发现连续 403 立即停跑等几分钟再续。续跑不要从头跑从失败列表里挑未完成目标继续即可已扫过的不会重跑。如果目标是云 WAF 场景最好再确认一下流量出口 IP 是否有针对网关的频率限制。4.3 现象万能密码检测误报率高到一半以上表现是报告里一大片命中人工复核却发现绝大多数根本无法登录。原因判定逻辑把“请求成功”当成了“登录成功”。很多登录接口不管密码对不对都会返回 302 跳转工具把每个 302 都记成命中或者响应体出现“账号已被锁定”这类提示工具仍然按成功登记。解决改成两步判定。第一步看登录请求的状态码和跳转落点第二步用刚刚返回的会话去请求一次后台首页如果首页返回 200 且响应文本包含“退出”“后台管理”“欢迎”这类特征词才确认命中。WebCrack 输出里保留响应特征词这一列就是为了给人做这层复核用的不要只看状态码。4.4 现象字典文件很大跑到一半像卡死一样表现是进度条停住日志文件十几分钟没有新增记录看起来像死机。原因不是机器卡死是任务队列被阻塞。并发开得大、字典又大请求堆积成百万级队列或者目标网络不稳定大量请求等待超时线程被超时等待占满后续任务全部排队。解决把并发调低把超时调短。我一般把单请求超时控制在 8 到 10 秒重试次数设为 0 或 1宁丢不拖。判断是不是假死就看日志文件最近 5 分钟有没有新增内容没有就是在空转这时不要硬等中断后保留已完成结果再按失败列表续跑。跑大字典前也建议先用 top100 做一轮预筛能少走很多弯路。4.5 现象报告显示命中手工复测却提示密码过期或验证码拦截表现是工具报告里写着 admin/123456 命中手动登录却提示密码已失效或者弹出验证码无法继续。原因两种可能。第一种是目标账号有定期改密策略工具扫到的口令是历史弱口令当前已失效第二种是爆破频率触发了风控目标侧插入了验证码后续请求全部被拦。解决区分处理。如果是密码过期在复测结果里注明“不可用”不要当作可利用漏洞上报如果是验证码触发把命中目标单独挑出来拉大请求间隔或暂停几分钟再手动登录确认一次。出现这种现场时报告结论要写清楚弱口令存在但当前不可用建议目标侧尽快强制改密。5. 读完报告别急着收工把命中结果手工复核成“可交付证据”再继续5.1 手工复核用 curl 重放登录并确认会话有效性批量工具给出的命中列表只是候选能不能写进交付报告必须人工在命令行或浏览器里复现一次。我的习惯是用 curl 重放登录请求把请求头、Cookie、响应内容完整留档当作证据链的一部分。# 重放登录请求带上工具命中时记录的账号密码 curl -i -s -c cookies.txt \ -d usernameadminpassword123456actionlogin \ -e http://192.168.1.20/admin/login.php \ http://192.168.1.20/admin/login.php # 第二步带 Cookie 请求后台首页确认没有跳回登录页 curl -s -b cookies.txt -L \ http://192.168.1.20/admin/index.php -o page.html head -n 30 page.html逻辑说明第一条命令用-c保存会话 Cookie-e模拟来源页按工具命中时的表单字段重放登录第二条命令携带 Cookie 请求后台首页如果返回 200 且包含后台特征词说明会话有效。head -n 30是快速看一眼响应内容不需要从头到尾读一遍 HTML。参数说明-d里的字段必须和工具命中时的表单配置一致否则重放结果不准-L跟随跳转后如果最终停留在登录页而不是后台首页说明 Cookie 没有通过鉴权这条候选要备注“无法验证”。写报告时我会把这两步的响应码和关键响应体片段一并贴进去客户复核也方便。5.2 把新后台路径、新密码沉淀进规则下一轮更省事爆破一轮之后最有价值的隐藏产出其实是目标侧的信息积累哪些后台路径不在内置列表里、哪些账号组合在实测里频繁出现、密码里有没有年份或编号规律。这些信息应该回收进下一轮的字典和路径规则而不是扫完就丢。常见做法是维护一份私有后台路径清单每轮批量后把新发现的路径同步进去密码词条同样按域名前缀、当前年份、常见弱口令变体预生成追加到自定义字典。几轮之后这套配置会越来越贴近实际目标特征命中率比通用字典高出一截。做这件事的时候我习惯同时把误报样本收集起来反向补充到“响应特征词”黑名单里让工具的判定规则越用越准。从那以后我每次跑 WebCrack 都会强制走一遍三段流程先确认授权范围再手动探一次登录请求格式最后分小批量试探并发。报告里凡是写“存在弱口令”的条目都必须有 curl 重放加 Cookie 鉴权成功这两条证据否则不算数。这个习惯救过我很多次也让我在交付时少被追问“这个命中到底能不能登录”。希望帮到你。本文还有配套的精品资源点击获取