很多人第一次接触 Burp Suite Intruder都是从同事的演示片段里看到的抓一个登录请求标好参数位置点一下 Start attack密密麻麻的结果马上刷屏再从里面挑出一条响应长度不一样的记录双击一看——登录成功后台进去了。整个过程可能比你泡一杯咖啡的时间还短。但说实话如果你以为 Intruder 的威力在于“快”那就理解偏了。它的真正价值是“可组合”把后台登录这样一个目标拆成 username、password 这些变量再把精心准备的弱口令字典喂进去工具会自动完成大量请求的发送与结果比对。这些年我做授权渗透测试后台弱口令检查基本都走这套流程从抓包到出结果5 分钟以内就能完成。这篇文章适合安全测试新手、想系统掌握 Intruder 的从业者也适合需要自查业务系统的运维同学。前提是只能在获得授权的系统上做测试这一点先讲清楚。1. 思路拆解Intruder 不是一个“爆破工具”而是一个请求编排引擎1.1 先理解 Intruder 的底层逻辑很多刚入行的朋友会把 Intruder 当成“自动换密码尝试登录”的暴力破解器这么理解不能算错但会把它的使用场景想窄了。Intruder 的本质是一个“请求模板 变量替换器”你给它一个 HTTP 请求模板把想要变化的位置标记成变量再给它一份或多份 payload它会自动生成大量请求并发送出去最后把响应收回来供你按状态码、响应长度、关键词等维度分析。这个逻辑套到登录场景就特别顺登录请求里有用户名、密码两个变量你用不同字典把这两个变量填上组合Intruder 就把每一个组合都实际请求一遍。所以它不止能做弱口令测试目录发现、参数 fuzz、Session ID 枚举等场景同样能用。明白这一点后你配置时思考的角度也会不同不是“爆破功能开关在哪”而是“我要把哪个位置设成变量每个变量用哪个 payload 来源”。注意Intruder 的定位是对单个目标做精细化、定向的测试优势是灵活不是海量并发。如果目标是千万级密码碰撞更多会借助专门工具如果目标是批量探测一堆接口脚本效率也更高。选 Intruder是因为它在图形界面下能最快完成“看得见、摸得着”的验证闭环。1.2 为什么后台登录场景特别适合用 Intruder后台登录是弱口令的重灾区。很多内部系统没有对接统一账号体系管理员为了方便记忆密码往往会落在几个固定套路里。在授权测试中后台登录又是最容易出成果的入口一个 admin/123456 可能就直接通向核心管理页面带来的风险等级完全不一样。这类场景的请求结构通常非常规律一个 POST 请求body 里是 username、password再加上一两个隐藏字段。这种“结构规则、参数有限”的请求恰好是 Intruder 最喜欢的输入不需要写一行代码就能完成完整测试。跑完之后还能把结果导出填充到渗透测试报告里作为证据。从项目流程来看“5 分钟爆破后台登录”可以拆成五件事准备请求包、构造或复用字典、设置变量位置、选攻击模式、启动并分析结果。后三步熟练之后一分钟内能完成真正花时间的是前两件。尤其字典如果你的字典只是网上随便搜来的旧列表跑出来的结果只能证明“字典不行”不能证明“目标系统安全”。2. 字典准备精选弱口令字典的构造思路2.1 字典为什么比工具本身更影响结果我见过不少人把精力花在调线程、调超时上结果跑完一列记录没有一条成功。心里还纳闷Intruder 不是挺厉害的吗其实 Intruder 只是个搬运工它把所有 payload 原封不动地发出去能不能成功九成取决于你喂给它什么。打个比方鱼竿再贵钩子上挂的是石头一天也钓不上鱼。弱口令字典的质量要看三个维度覆盖度、场景匹配度、干净程度。覆盖度指常见弱口令有没有收全场景匹配度指有没有针对目标系统做定制比如结合系统名称、年份、域名特征干净程度指列表里有没有多余空格、重复项、错误换行。同一个后台用通用字典跑可能一无所获换一份结合目标信息的定制字典也许第三条就中了。实际项目里我会先打开登录页面翻一下 HTML 源码看看有没有默认密码提示、开发注释、版本号。这些都可能成为字典里的定制种子。一份 20 条的高质量定制字典有时比 2 万条的通用大字典更值得跑。2.2 后台登录场景的字典构成对后台登录这类目标我会把字典拆成用户名和密码两份。用户名通常不会太大常见的就是 admin、administrator、root、test、guest、manager、operator、system、webadmin 这几个再根据目标系统的名称拼音、公司简称做几个扩展。密码字典相对大一些但也不是越大越好。精选的 500 到 1000 条往往比 100 万条的大字典实用因为大字典大部分条目根本不会出现在这种场景中反而拖慢速度、增加结果分析的噪声。一份典型的后台密码精选字典通常包含这几类纯数字弱口令123456、888888、666666、123123、520520键盘顺序类qwerty、abc123、1qaz2wsx、qwe123、zxcvbnm单词及常见变形password、admin123、welcome1、Passw0rd、Pssw0rd与站点相关的模式系统名拼音加年份、域名前缀加 123、公司简称加 2024管理后台专属高频口令admin888、admin123、admin123456、root123用户名和密码的搭配策略上我习惯先做“同名对撞”再做组合展开。同名对撞是指先把 admin/admin888、test/test123 这类账号密码一致或高度关联的样例跑一遍组合展开则是在用户名和密码之间做全排列。这样既能快速验证最可能的口令又不会漏掉散落在组合里的意外发现。贴一份可以拿去做示范的字典片段仅限授权测试学习使用# 用户名清单 admin administrator root test guest manager operator system webadmin # 密码清单 123456 admin admin888 admin123 admin123 password Password123 qwerty abc123 1qaz2wsx root123 test123 welcome1 Pssw0rd 666666 888888 Admin123实操心得字典值不要带多余空白字符统一用 LF 换行保存。很多系统会把密码里的空格当成有效字符参与校验如果字典里混入 CRLF 或空格会出现一波“人工造成的失败”纯属浪费请求。3. 模式选型四种攻击模式与变量标记要点3.1 四种攻击模式怎么选Intruder 的四种模式很多人背得很熟一上手就乱。这里结合登录场景给你一套可以直接套用的选型逻辑Sniper狙击手只有一个变量位置或者多个位置按顺序被同一个 payload 列表替换。适合固定用户名只枚举密码。Battering ram攻城锤多个变量位置同时填入同一个 payload 值。适合账号密码同值碰撞。Pitchfork草叉多个变量位置各自绑定不同的 payload 列表按行号一一配对。适合用户名和密码已经做成对应关系的情况。Cluster bomb集束炸弹多个变量位置各自绑定不同的 payload 列表做全排列组合。适合完全不知道账号密码分布的情况也是后台登录弱口令测试最常用的模式。重点说下 Sniper 和 Cluster bomb。Sniper 适合你已经锁定一个账号比如通过其他途径确认管理员账号是 admin接下来专门测它的密码。Cluster bomb 适合零信息开局用户名放 10 条、密码放 100 条全排列就是 1000 个请求后台登录接口一般能承受跑完也就一两分钟。用一张表看更直白模式变量数字典组合方式登录场景典型用法请求量Sniper单变量或顺序多变量同一份 payload 依次替换固定 admin枚举密码密码条数Battering ram多变量所有变量用同一份值账号密码同值碰撞字典长度Pitchfork多变量多个 payload 源按行配对账号与密码已对应成行行数Cluster bomb多变量多个 payload 源全组合账号×密码全排列乘积我的建议是第一次做后台登录测试先跑 Cluster bomb用户名压到 5 到 10 个密码压到 50 到 100 个。如果没结果再调试请求包、换字典方向而不是一上来就搞 100 万行的巨型组合。3.2 正确标记变量位置标记变量位置的原理很简单在请求模板里凡是想动态替换的部分用两个§符号包起来。在 Burp 的文本编辑区选中参数值点击 Add § 就会自动包上。以一个登录包为例标记之后长这样POST /admin/login.php HTTP/1.1 Host: 192.168.1.10 User-Agent: Mozilla/5.0 Content-Type: application/x-www-form-urlencoded Cookie: JSESSIONIDabc123 Connection: close username§admin§password§123456§这里 username 和 password 的值被包上了 §表示这两个位置是动态的。注意不要把 Cookie 里的安全标记、固定固定值参数也顺手包进去除非你确实想测它。我见过有人手滑把 Host 或 Content-Type 标上了结果所有请求直接 400排查半天才意识到是标记位置错位。配置 payload 时要理清对应关系Cluster bomb 模式第一组 payload 对应第一个 §第二组对应第二个 §顺序不能反。如果用户名和密码的 payload 源放反了跑出来的请求就是密码不变、用户名轮换自然永远进不去。注意Burp Suite 社区版对 Intruder 请求速度有限制实际跑大字典时会明显慢于专业版。社区版做 5 分钟规模的小范围演示完全够用如果项目里要跑上千条甚至上万条请求要么考虑专业版要么用脚本补齐。4. 完整实操5 分钟爆破后台登录4.1 抓包与请求准备第一步是拿到登录请求。最直接的方式是浏览器挂上 Burp 的代理监听 127.0.0.1:8080然后在登录页随便输入一个测试账号密码点登录。Burp 的 HTTP History 里会出现这个 POST 请求右键发送到 Intruder 即可。这里有个容易被忽略的细节登录过程可能不止一条请求。很多系统会先发 GET 拉取表单再发 POST 提交数据。你要盯的是携带 username 和 password 参数的 POST而不是前面的静态资源请求。建议先把请求发到 Repeater手动改一次参数、点 Go确认能正常返回再做 Intruder。这个“先在 Repeater 验证请求包可用”的习惯能帮你筛掉一大半后面的坑。4.2 配置 Intruder 并启动把干净的请求包发到 Intruder 后按照这个流程操作在 Positions 页签将攻击模式选为 Cluster bomb选中 username 和 password 的参数值分别标记为两个变量位置。在 Payloads 页签把用户名字典和密码字典分别粘贴到 Payload set 1 和 Payload set 2。在 Options 页签线程数设在 5 到 10 之间。线程不是越高越好后台接口往往有频率策略太高容易触发锁定或封禁太低则速度太慢。点击 Start attack窗口弹出结果表格开始刷新。跑的过程里你可以直接看到状态码分布。登录失败通常返回 200 加一个“用户名或密码错误”的页面登录成功则往往是一个 302 跳转到后台首页或者 200 加一个长度差异明显的页面。所以扫结果时眼睛先看 Length 这一列长度明显不同的记录优先级最高。4.3 结果分析一分钟内定位成功条目分析结果时别只盯着状态码。登录失败和成功经常都是 302甚至都是 200真正区分它们的是响应内容。我的做法是加两层判断在 Options 页签的 Grep-Match 里填上“密码错误”“用户名不存在”“Login failed”这类页面特征关键词。如果登录成功后会跳转到后台地址就在 Redirections 里设置跟随重定向再对比最终响应长度。实际操作中如果目标没有复杂的防爆破机制Cluster bomb 跑 10×100 共 1000 条请求专业版几十秒完成社区版会慢一些5 分钟内足够跑完并分析。锁定可疑条目后双击打开请求发送到 Repeater 单独再打一次确认确实能进入后台或者拿到有效会话 Cookie。这一步不能省报告里写起来才扎实。实操心得爆破成功后第一时间把响应的 Cookie、跳转路径和响应包截图存好。这些是权限验证的关键证据后续写报告、复测对比都要用到。别等会话过期了再想起来去截那时候往往需要重新跑字典。5. 常见问题与排查技巧实录5.1 为什么一个也没命中排查顺序很重要。先确认请求包本身能不能用拿一组确实正确的账号密码在 Repeater 里手动登录一次。如果手动能过、Intruder 全失败大概率是变量标记错误或字典格式问题。再检查登录接口有没有来源限制比如 IP、User-Agent、Referer这时候要用浏览器实际发送的完整请求头而不是只带裸参数的简化请求。最后确认目标系统是否做了前后端双重校验前端加密的密码字段单靠改 body 是无效的。很多时候我会打开一两条 Intruder 请求和浏览器实际发送的登录请求做对比。参数顺序不同、少了隐藏字段、少了某个固定值都可能导致服务端直接拒绝。隐藏字段尤其常见。很多后台登录页都有防跨站请求伪造的 tokenbody 里带一个_token或csrfmiddlewaretoken。这类字段不处理Intruder 跑多少条都会因为 token 校验失败而全军覆没。两种思路一是抓一个有效 token 放进请求模板跑短字典短时间内 token 复用也许能通过二是写脚本从响应中动态提取 token每请求携带新值。后者已经超出 Intruder 本身的能力需要借助扩展脚本实现。5.2 验证码、锁定策略和频率限制怎么应对验证码和账号锁定策略是 Intruder 的天敌。遇到图形验证码建议先判断接口是否真的校验有些系统只是前端生成验证码、服务端根本不校验这种情况可以直接去掉该字段跑如果服务端严格校验就不要硬上 Intruder 了。这类系统的防护目标本来就是阻断自动化登录强行对抗既浪费时间也把测试性质跑偏了不再是“检查弱口令”而是“攻破防护机制”。账号锁定策略常见表现是连续失败 5 次就锁账号或锁 IP。这时候 Intruder 并不合适它天然就是高频请求。我的做法是换更小的字典、更低的线程、更长的间隔把总体失败次数控制在策略阈值内或者评估是否需要换测试账号。做授权测试时这类信息要提前同步给客户避免把生产账号锁死造成业务影响。频率限制方面可以在 Intruder 的 Resource pool 里配置每秒请求数上限把速率压到接口能承受的范围。很多人觉得限速影响效率但对登录测试来说稳定比速度重要得多——你不可能在一个线上系统上把接口打崩那就不再是测试而是事故了。5.3 结果误报与验证杂谈Intruder 结果里可能混着大量看着像成功的响应固定返回 302、固定返回 200 但长度完全一致。误报的主要原因是没有设 Grep-Match或者没有跟随重定向。我遇到过一个案例目标系统所有登录尝试都会先 302 到一个统一错误页再从错误页返回 200。如果只看第一跳状态码1000 条记录几乎全是“成功”实际上一个都没进。解决办法是填上 Grep-Match 关键词把 Redirections 设为始终跟随等最终响应回来后再按长度和关键词判断。对可疑条目做二次验证时我通常会把请求发到 Repeater把里面的 payload 改为实际有效凭据测试一次确认整个判断链路是通的然后再把 Intruder 中可疑的那组值原样重发一次看能否复现成功。两次都通过才敢写进报告。6. 实战经验沉淀与扩展思路最后聊几点踩过坑之后沉淀下来的东西。第一是“先小后大”的测试节奏。拿到后台登录接口不要急着上大字典先拿 2 到 3 组针对性极强的组合手工试一下比如 admin/admin、admin/123456、系统名拼音加年份。连这都进不去说明大概率没有特别容易的弱口令再启动 Intruder 跑大字典也不迟。反过来一上来就全速跑容易先触发锁定或封禁后面什么都做不了。第二是把字典当成可复用的资产。我会把用过的字典按场景分类保存通用后台、CMS 默认口令、设备默认口令、协议弱口令每个目录里再放一个说明文件记录来源和适用场景。新项目开场就是从本地字典库拖几份出来跑而不是临时去搜一份可能过时的列表。字典资产管理好“5 分钟出结果”的能力才能稳定复现出来。第三是考虑 Intruder 之外的能力延伸。当目标因为动态 token、验证码、多阶段认证导致 Intruder 搞不定时我一般会转到脚本方案从请求序列中提取动态值、重新构造请求、循环发送。Intruder 负责快速验证思路脚本负责把思路在更复杂的规则上跑通两者配合才是完整的弱口令测试流程。这个方向超出了本文范围但既然你已经掌握了 Intruder后续很值得往这个方向再走一步。最后分享一个小技巧。把爆破出来的成功凭据写进报告时务必记录测试时间、响应长度和当时的请求包。后台会话很可能短时间内过期如果没有第一时间截图留档写报告时再想复现往往需要重新跑一遍字典。这个习惯帮我省下了大量重复劳动也避免了好几次报告里证据缺失的尴尬。