1. 项目概览为什么要用Intruder做密码测试所有做Web渗透测试的人几乎都绕不开Burp Suite。而在Burp的众多模块里Intruder是出场率极高、也最能体现“暴力美学”的一个。简单说Intruder是一个自动化请求修改与重放工具它能对某一个HTTP请求中标记好的位置批量替换成字典里的值然后一次性发送大量请求用来做参数枚举、身份枚举、密码爆破这类工作。我在实际项目里最常用它做两件事一是测试某个登录接口是否存在弱口令问题二是在授权范围内对测试账号做密码找回、验证码绕过后的爆破验证。不管你用它是为了CTF拿分还是做企业内网的系统评估Intruder这套流程都是基本功。这个系列文章我会围绕一个典型场景展开用Burp的Intruder模块对一个Web登录接口实现密码字典爆破同时也把Sniper、Cluster Bomb这类攻击模式、Payload配置和结果分析技巧一起讲透。这篇文章更适合已经了解Burp基本代理抓包、能看懂HTTP请求包结构的读者。如果你是纯新手建议先把Proxy模块和Repeater模块摸熟了再回来看会顺畅很多。当然文章里涉及的关键概念我也会尽量讲清楚保证你照着操作能跑通。重要提醒本文所有内容仅供安全测试、CTF竞赛、本地实验或获得明确授权的渗透测试使用。对未授权目标执行密码爆破属于违法行为后果自负。动手之前先确认你有没有“书面授权”或者目标是不是你自己搭建的实验环境。2. 爆破前的思路梳理与环境准备2.1 密码爆破的本质一个不断试错的过程密码爆破的逻辑并不复杂——拿一批候选密码挨个填进登录请求里看哪个能返回“登录成功”的特征。这本质上就是一个“输入-响应-判断”的循环。真正有技术含量的不是“暴力”这个动作而是怎么把请求构造得足够真实、怎么选择有效的字典、怎么从海量响应里快速识别成功信号。我经常看到有人一上来就选了一个几GB的通用字典线程拉到100结果跑了半小时也没跑出来。问题往往出在字典跟目标的密码策略不匹配或者请求里还带着时间戳、CSRF Token这种动态参数导致每个请求都直接失败了。爆破看似无脑但前置的观察和构造工作才是成败关键。2.2 拿到目标登录接口的完整请求包第一步永远是先抓包。打开Burp配置好浏览器代理默认是127.0.0.1:8080关闭拦截或者临时放行然后在浏览器里手动登录一次目标系统随便输入一个账号和错误密码。回到Burp的HTTP History里找到刚才那条POST类型的登录请求。这个请求包里藏着所有爆破需要的信息。以常见的表单登录为例抓到的包应该是类似这样的结构POST /api/login HTTP/1.1 Host: test.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Content-Type: application/x-www-form-urlencoded Cookie: JSESSIONID9F8E2A1B3C4D5E6F usernameadminpassword123456我要特别提醒不要只盯着请求体里的username和password两个参数还要看请求头里的Cookie、Content-Type、X-Requested-With这些字段。有些系统会在请求头里校验来源、校验Ajax标识甚至校验Referer。如果这些字段缺失或者不对后端可能直接返回400或跳转到登录页爆破自然没法成功。一个很常见的坑是登录接口重定向到了首页你在浏览器里看着像是登录成功了实际上请求根本没进后端的登录逻辑。所以在抓包阶段就要把完整请求链看明白哪个是真正的登录接口哪个只是普通的POST请求。2.3 清理动态参数时间戳、Token与加密字段现在的Web系统很少是裸奔的登录请求里经常带着额外参数。我见过比较典型的几种时间戳参数每次请求都不一样如果不处理爆破时每个请求都会被判定为参数异常。CSRF Token藏在表单或Cookie里需要先获取一次有效Token再在爆破请求中动态替换。密码加密字段前端用JS对密码做了MD5、SHA256或RSA加密后再提交直接爆破明文密码没有意义必须处理成接口期望的密文格式。处理动态参数没有“一招鲜”的通用方法要具体情况具体分析。我自己常用的思路是先用Repeater手动重放抓到的请求确认静态参数能稳定通过如果请求里有动态参数先分析它是独立生成还是跟会话绑定对于CSRF Token可以用Burp的Session Handling规则自动获取或者写一个简单的Python脚本在爆破前批量获取Token对于加密字段最简单的方式是找到前端JS里的加密函数用本地脚本预生成加密后的字典再丢给Intruder用。这个阶段宁可多花20分钟也不要急着开跑。我见过太多人爆破不出结果最后发现是Token或时间戳在捣乱。2.4 确认字典方向先摸清密码策略准备爆破之前最好先了解目标系统的密码策略。比如系统要求密码至少8位、包含大小写和数字那么字典里全是6位纯数字肯定白搭。获取密码策略的途径有很多注册页面的密码提示忘记密码页面的规则说明前端JS里的正则校验代码系统默认密码文档或厂商公开资料。在授权测试中我通常会先准备一份“基础字典规则变形字典”的组合。基础字典包括常见的弱口令admin、123456、password、admin888、qwerty等。规则变形字典则是在基础词上追加数字、特殊符号、大小写变化等。Burp的Payload Processing功能就能实现这类动态变形不需要本地预先存一个巨大的字典文件。3. 深入Intruder攻击模式与Payload配置3.1 四种攻击模式的区别和适用场景Intruder提供了四种Attack Type很多人一开始搞不清该选哪个其实理解了就很简单。Sniper狙击手这是最基础的模式一次只爆破一个位置。如果你在请求里标记了两个位置比如用户名和密码Sniper会先用字典挨个替换第一个位置保持第二个位置不变全部跑完一轮后再用字典替换第二个位置保持第一个位置不变。也就是说两个位置不会同时变化。这个模式最适合“只爆破密码、用户名固定”的场景。比如你已经知道用户名是admin只需要在密码位置跑字典选Sniper就对了。它的优点是请求数量少、逻辑简单缺点是如果有两个变量需要同时变化它不算高效。Battering Ram攻城锤这个模式也比较冷门。它同样支持多个标记位置但所有位置同时替换成字典里的同一个值。比如你在用户名和密码两个位置都做了标记那么跑第一轮时用户名和密码都是字典第一个词第二轮都是字典第二个词。它适合那些“登录名和密码相同”的奇葩系统或者测试某些口令卡场景。日常登录爆破用得不多。Pitchfork草叉这个模式必须配合多个Payload字典。比如位置1用字典A位置2用字典B它是按索引对齐组合的A的第1个词配B的第1个词A的第2个词配B的第2个词。组合数量取决于两个字典里较短的那个长度。Pitchfork适合“已知用户名列表和对应密码列表”的场景。比如你在信息收集阶段拿到了几个账号每个账号可能对应不同密码用这个模式可以一一匹配。但如果两个字典长度不一致多余的部分不会跑这一点要注意。Cluster Bomb集束炸弹这个模式是暴力枚举的完全体。它会对所有标记位置做笛卡尔积组合比如位置1有1000个词、位置2有1000个词那就是100万次请求。组合数量等于各字典长度的乘积。Cluster Bomb适合的典型场景是“用户名和密码都不知道需要同时枚举”。举例来说你用1000个用户名和1000个密码做组合就会产生100万请求。这种模式功能最强大但对目标服务器压力也最大运行时间也会比较长。如果还叠加了线程数很容易把目标打崩或者触发风控。3.2 实战场景的攻击模式选择为了方便参考我把最常见的几种场景和推荐模式整理成了表格实战场景需要枚举的变量推荐模式原因已知用户名爆密码密码Sniper一次只跑一个变量逻辑清晰便于设延迟同时枚举用户名和密码用户名密码Cluster Bomb需要所有组合都覆盖已知用户名列表和密码列表用户名密码Pitchfork按索引配对请求量少用户名密码用同一个字典用户名密码Battering Ram用相同的词同时填充两个位置找回密码接口枚举手机号手机号Sniper单变量枚举以文章开头那个usernameadminpassword123456的请求为例如果只是爆破admin的密码那么只标记password的值Attack Type选SniperPayload选密码字典就足够了。3.3 Payload类型的选择字典不是越大越好Burp的Payload Type提供了很多选项我最常用的有这几个Simple list直接加载一个字典文件或者手动输入几个词。适合大多数爆破场景。Runtime file从外部文件实时读取字典适合超大字典不会一次性把内存打满。Custom iterator自定义迭代器可以像排列组合一样生成多个位置的组合。适合构造“前缀数字后缀”这类复杂字典。Numbers生成数字序列适合爆破验证码、手机号、订单号等纯数字参数。Character substitution这个不是Payload Type是Payload Processing里的功能可以把字典里某些字符替换成其他字符比如a替换成、e替换成3用于生成弱口令变体。选字典的原则是“先小后大”。我个人的习惯是先用一个几百条的高频弱口令字典快速试探如果一条都没中再考虑上大字典。不要一上来就上rockyou之类的巨型字典爆破日志几千页分析起来很痛苦。3.4 Payload Processing让字典自动变形很多人不知道Burp的Payload Processing有多好用。它可以在Payload发送之前对字典词做各种加工。我举几个实际用过的例子添加前缀后缀字典里有admin处理规则加上前缀test和后缀2024实际发送的就是testadmin2024。大小写变换把admin变成Admin、ADMIN、aDmin等不需要在字典里重复存。编码处理对Payload做URL编码、Base64编码等适合接口期望特殊格式的情况。字符串替换把字典里的o替换成0这样可以轻易生成adm1n这类变体。如果爆破接口要求密码是加密后的密文Payload Processing里还可以调用Burp扩展或外部脚本。比较常见的做法是先用Python脚本把密码字典全部加密成密文文件再作为Simple list加载。Burp本身不擅长做复杂的加密运算没必要硬来。4. 资源池与请求设置的调优经验4.1 线程数与延迟别把目标打死在Intruder的Resource Pool选项卡里可以设置并发请求数。这里必须说一句不是线程越多越快。线程过高会导致请求超时、连接重置反而拖慢速度更糟糕的是如果目标有登录失败锁定策略并发太大意味着几分钟内就触发锁定后面所有尝试都会失败。我常用的配速参考如下场景建议线程数建议延迟本地CTF靶机10无内网测试系统低防护5100-200ms公网授权测试目标1-3500-1000ms有锁定策略的系统1手动调整节奏在线上环境我宁可跑慢一点也不愿意把目标的风控触发。很多系统在连续失败5次后就会锁定账号15分钟如果你线程拉满前5个请求就把账号锁了后面几千个请求没有任何意义。这时候可以考虑爆破多个用户名每个用户名只试几个常见密码曲线绕过锁定限制。4.2 请求头与Cookie的处理细节在Intruder的请求编辑区除了标记爆破位置还要注意请求头参数。有些系统的接口要求请求头里带X-Forwarded-For字段会根据这个字段做IP风控。这时候如果用固定IP跑很快就会被拦截。有些系统则是靠Cookie维持会话。如果Cookie里的Session有有效期爆破时间太长导致Session过期后续请求都会失败。解决方案是让Intruder通过Session Handling规则自动从登录页获取新Cookie不过这个配置稍微复杂我在后面问题排查部分会细说。4.3 手动设置Throttle有节奏地爆破Intruder的Resource Pool里还有一个Throttle选项可以设置每个请求之间的固定间隔。我之前测试过一个比较严格的内网系统它对单IP的请求频率有限制超过阈值就直接返回验证码。一开始没设置延迟跑了200个请求后开始大量失败。后来我把Throttle调到1000ms虽然速度慢了但请求的成功率恢复到了100%。如果你的目标只是几十个密码的小字典没必要用高并发设个几百毫秒间隔慢慢跑真实效果反而更好。5. 爆破结果的判断与分析技巧5.1 从状态码和响应长度找异常爆破跑完之后Intruder的结果列表会显示每个Payload对应的响应状态码、响应长度、响应时间等信息。先别急着翻找“200”要注意对比所有响应的差异。正常逻辑是大部分失败请求的状态码都是200响应长度也差不多成功登录的请求要么状态码变成了302跳转要么响应长度明显不同要么响应内容里包含特定的关键词。我举一个实际操作例子。某次测试一个后台登录接口失败请求的状态码全是200响应长度都在3200字节左右。唯独有一个请求的响应长度变成了4150字节同时响应内容里多了msg:login success。就凭这个长度差异我直接锁定了正确密码。千万不要只看状态码很多系统不管密码对错都返回200真正的差异藏在Content-Length里。5.2 用响应内容筛选成功信号如果响应内容较大肉眼看几千行很痛苦。Intruder的Settings里有Grep-Match功能可以在发送请求前预设一些关键词比如login success、欢迎、dashboard、logout等。跑完之后结果列表会显示每个请求是否包含这些关键词一眼就能筛出来。还有一种情况是登录接口没有明显的成功关键字而是通过Set-Cookie长度变化来区分。比如失败时种一个sessionerror的Cookie成功时种一个很长的Token。这时候可以在Grep-Extract里提取Set-Cookie的字段值再根据长度对比定位。5.3 用Conditional Grep做进阶判断Burp新版本里的Conditional Grep功能非常实用。它可以基于状态码、响应长度、响应内容等条件做二次判断。比如你想筛选“状态码是302且响应里包含某个URL”的请求用Conditional Grep比手动筛选方便得多。我个人的分析习惯是先按响应长度升序或降序排序看有没有明显离群值然后对有离群值的请求右键Send to Repeater手动重放一遍确认它不是偶然的网络抖动导致。只有Repeater里复现成功我才会认定密码有效。5.4 一次典型的成功判断流程整理一个我自己在用的判断流程爆破结束后先看总请求量和完成时间排除网络中断或目标封锁导致的异常。按Content-Length排序找出长度异常集中的请求。对Top 3的异常请求逐一用Repeater重放。如果重放后返回的特征稳定再手动用浏览器或脚本登录一次最终确认密码可用。如果所有请求的响应都一样很可能目标接口加了Token或验证码需要回到第2章排查请求构造问题。6. 实战记录一次标准的Sniper爆破过程为了更直观地展示完整流程我用一个模拟项目X来做全流程演示。这个模拟项目X是我自己搭在内网的一台测试系统登录接口没有验证码没有失败锁定非常典型的低防护环境。第一步我在浏览器里访问模拟项目X的登录页面输入admin和wrongpass抓到的POST请求如下POST /login HTTP/1.1 Host: 192.168.1.10:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Content-Type: application/json Accept: application/json {username:admin,password:wrongpass}注意这个接口是JSON格式登录不是传统表单。在标记位置时我只需要选中wrongpass这几个字符点击“Add §”即可。请求体里的JSON引号不要标记进去否则会把引号也当成密码的一部分。第二步我准备了一个高频弱口令字典大概是这样的内容admin 123456 password admin123 admin888 letmein qwerty 12345678 admin123 test123没有用巨型字典因为测试环境本身密码策略不强先用小字典试探效率最高。第三步在Attack Type里选SniperPayload Type选Simple list把上面的字典加载进去。Resource Pool里线程设5Throttle设200ms。然后点击Start Attack。在实际运行过程中我观察到前8个请求的响应长度基本相同内容都是{success:false,msg:username or password error}。到第9个Payloadadmin123时响应长度变了内容是{success:true,msg:login ok,token:eyJhbGciOi...}。紧接着的请求又恢复到了原有的长度。到这一步基本可以确定密码就是admin123。我右键这个请求Send to Repeater修改密码字段再发一次返回同样成功确认无误。整个过程不到15秒效率很高。7. 常见问题与排查技巧实录7.1 问题一爆破时提示CSRF Token无效这是最常见的坑。解决办法分两步用Burp的浏览器访问登录页面从响应里提取Token。在Intruder的Payload Processing里并不适合直接处理Token因为Token每次请求都要变。更合适的方案是写一个Python脚本先请求登录页获取Token再把Token拼接到爆破请求里逐条发送。如果不想写脚本也可以用Burp的Session Handling规则。在Project Options Sessions Session Handling Rules里新增一条规则规则动作选择“Replace value in request”设置Token的来源请求和提取规则。这样Intruder每次发送请求前都会先获取一次新Token。不过这个配置比较复杂新手期建议先用脚本处理。7.2 问题二请求发出去后全是400 Bad Request出现这种情况先检查是不是Payload里包含了特殊字符比如空格、引号、中文等导致JSON或URL格式被破坏。如果是URL参数类型Intruder一般会自动编码但JSON类型不会自动处理遇到引号就会报错。解决方式是在Payload Processing里加一个“URL-encode all characters”或者在Payload类型里选择“Raw”并手动处理编码。还有一个容易被忽略的点请求头里的Content-Length是旧值添加或修改Payload后Burp一般会自动更新但如果你手动改动过原始包Content-Length可能不匹配。7.3 问题三跑着跑着突然大量返回验证码这是目标的风控生效了。遇到验证码不要再硬跑先停下来分析触发条件。一般触发条件是来自同一IP的请求超过阈值同一账号失败次数超过阈值User-Agent指纹不常见。应对思路是放慢速度、控制频率或者尝试用分布式IP池。如果是测试自己的系统也可以暂时在服务端关闭验证码验证逻辑把重点放在密码字典的验证上。7.4 问题四字典跑了很久一个成功标记都没有这种时候不要绝望回头重新做信息收集。我总结过几个排查方向密码策略是不是要求必须包含特殊字符导致字典命中率极低登录接口是不是被WAF拦截所有请求都返回了统一的拦截页面密码字段是不是经过了加密处理你提交的明文根本没有被后端识别账号本身是否存在先枚举用户名确认账号存在再爆破密码。我自己就遇到过一种情况目标系统的密码字段名不叫password而叫pwd_enc而且前端做了两次Base64编码。不抓包根本看不出来。7.5 问题五Intruder跑得太慢怎么加速如果确认目标没有风控也没有锁定策略可以考虑以下加速方案提高Resource Pool里的线程数关闭Throttle使用更精简的字典把不需要的请求头删掉减少网络开销。但请务记住加速的前提是目标能够承受。对生产环境目标我不建议线程超过10。8. 写在最后的几条实际经验关于Intruder爆破我个人的体会是工具的使用只是表层功夫真正拉开差距的在于对HTTP协议的理解。谁能准确分析请求里的每个参数谁能快速识别响应中的微小差异谁就能在授权测试中事半功倍。爆破失败不是工具不行而是准备工作没做够。最后分享一个我经常用的小技巧爆破前先拿10个左右的测试Payload放到Repeater里逐个手动发送观察请求频率和响应变化确认目标的风控策略。如果这10个请求里就有两个触发了验证码那就绝对不适合直接用Intruder跑大字典不如换个思路看看目标网站有没有短信轰炸、验证码绕过、撞库等其他测试面。还有一点爆破尽量选非工作时间进行。这不是迷信而是为了降低对目标系统正常业务的影响。授权测试也要讲边界不能为了印证漏洞把一个月的日志刷爆。控制节奏、控制影响才是专业渗透测试人员该有的习惯。