WebCracker 不是使用那种装完就能一路点“下一步”的软件。我第一次跑它的教程时候，对着命令行愣了十分钟——参数太多，使用文档又写得像天书。教程后来摸清楚了，使用其实核心就三件事：目标、教程字典、使用并发。教程搞明白这三样，使用剩下的教程都是细节。

先搞清楚你要测什么

WebCracker 的使用本质是 HTTP 请求爆破工具。它把字典里的教程用户名和密码组合成请求，往目标登录接口上砸，使用看哪个组合能返回 200 或者跳转成功。教程所以第一步不是使用打开软件，是打开浏览器 F12。

拿一个典型场景说：某后台登录页，POST 到 /api/login，body 是 { "user":"admin","pass":"123456"}，失败返回 401，成功返回 200 加一个 token。你得先把这些信息抓下来。我见过有人连请求方法都没确认就往 WebCracker 里塞，跑了一下午全是 405，白费电。

抓包的时候注意几个点：有没有 CSRF token？如果有，WebCracker 得配置动态提取规则，否则每次请求都带同一个过期 token，结果全是失败。还有 Cookie，有些站点登录接口依赖前置的 session cookie，你得先手动访问一次首页拿到 cookie，再填进 WebCracker 的 header 配置里。

字典决定成败

WebCracker 自带的那几个字典，说实话，只能拿来测试环境用。真实场景下，字典质量直接决定你能不能出结果。

用户名这块，别一上来就上 top1000 通用字典。先手动试几个：admin、administrator、test、guest，看看返回信息有没有差异——比如“用户不存在”和“密码错误”返回不同提示，那就是用户名枚举漏洞，你可以先跑一遍用户名字典，把存在的用户筛出来，再针对这几个用户跑密码字典。这样效率高一个数量级。

密码字典更讲究。我一般会分三层：第一层是 rockyou.txt 前 10000 条，快速过一遍弱密码；第二层是结合目标信息的定制字典——公司名、域名、年份、常见后缀（如 @123、2024）；第三层才是全量爆破。很多人直接跳第三层，结果跑了三天什么都没出，其实目标用的就是 admin888 这种，第一层就命中了。

并发和延迟的平衡

WebCracker 默认并发是 10。这个值在测试环境没问题，放到生产环境要么太慢，要么把对方打挂。

我一般先设 5，跑 100 个请求看响应时间。如果平均延迟在 200ms 以内，逐步加到 20、50。超过 50 之后，很多 WAF 就开始拦截了——你会看到大量 403 或者连接重置。这时候别硬刚，降到 10 以下，加上 --delay 500（每个请求间隔 500ms），虽然慢，但能跑完。

还有个坑：有些站点会对同一 IP 的频繁请求做限速。WebCracker 支持代理池，但配置起来麻烦。我的做法是挂一个 Burp Suite 做上游代理，在 Burp 里配好 IP 轮换，WebCracker 只负责发请求。这样灵活得多。

结果解读别只看 200

跑完之后，WebCracker 会列出所有“成功”的条目。但别高兴太早——有些站点登录成功也返回 200，但 body 里写着“密码错误”。你得看响应长度和关键词。

我习惯在 WebCracker 里设置 --match-string "dashboard" 或者 --filter-length 1234，只保留真正成功的响应。如果拿不准，就把结果导出成 CSV，用 Excel 按响应长度排序，异常值往往就是突破口。

最后说一句：WebCracker 只是工具，别把它当银弹。我见过太多人拿着它乱扫，结果被对方封了 IP 还浑然不知。测之前确认授权，测的时候控制节奏，测完清理日志。这行干久了，你会发现技术只占三成，剩下七成是判断力和耐心。