简介面向AWDAttack With Defense比赛实战场景这款自动化攻击框架是专为参赛队伍与安全研究者打造的效率工具。它依托YML配置文件驱动核心引擎实现漏洞利用、Shell连接、内存马处理等模块的自动编排大幅降低攻防对抗中的重复编码负担。资源包共66个文件体积仅1.03MB核心代码以Py为主包含36个pyc编译文件与18个py源码便于直接运行和二次修改另有xml配置、png示意图、md说明及sqlite数据库等辅助材料。目前已有944人学习下载。该框架提供从启动入口到核心攻击、后门应答、SSH连接等模块的完整目录结构使用者可快速定位攻击链代码同时YML配置化设计允许自定义攻击阶段与条件逻辑适合在Bugku AWD赛场快速测试策略、模拟真实攻防环境对想提升自动化攻击能力的选手来说是一份轻量而实用的参考实现。1. 这个 zip 不是普通压缩包Bugku-AWD 专版到底解决什么问题打 AWDAttack With Defense攻防对抗赛的都知道真正的比赛里最缺的不是技术是时间。一轮五分钟进攻方要批量打对面几十个靶机防守方要同时盯着自己被种了哪些应急载荷、网站被黑到哪一步、flag 文件有没有被人提前抄走。手点浏览器肯定来不及于是就有了这类「[Bugku-AWD专版]一款用于AWD比赛中的自动化攻击框架.zip」它把扫描、利用、取 flag、提交这条链路做成一套可重复执行的自动化流程赛前配置好开赛就能对整张目标列表批量开火。这个 zip 标题最吸引人的是两点一是做了 Bugku 平台特化赛事规则、flag 校验、checker 提交接口这些细节大概率已经按 Bugku 的赛场节奏调过二是它以压缩包形式分发解压即用不依赖 Git 仓库和复杂部署。但压缩包分发的工具也是一把双刃剑——伪加密、二次打包、依赖缺失都是常见坑。这篇笔记就把这套框架从「怎么解压、怎么跑起来」到「参数怎么调、哪些玄学翻车」完整拆开适合临赛前想快速组一套攻击链的队长也适合第一次接触 AWD 自动化、想在靶场里先把流程跑通的新人。2. 把 AWD 的攻防节奏拆开看自动化框架从哪里下手2.1 五分钟一轮的比赛周期里人在哪一步最容易被拖死AWD 的典型规则是每队一个靶机上面跑着同构的 Web 服务flag 以文件或数据库字段的形式存在每隔一段时间常见是 3 到 5 分钟全部轮换一次。你既要保住自己靶机上的 flag 不被对面抄走又要在别人靶机上拿到新 flag 并在轮换前提交到 checker才算有效攻击分。防守分靠服务可用性和加固到位攻击分靠的就是「拿得到、交得快」。这一步最拖人的不是漏洞利用本身而是三个重复动作每轮要重新探测哪些靶机还活着、哪些漏洞被对手修了每次拿 flag 要对着几十台机器重复敲同一条命令拿到之后还要切到 checker 页面手动粘贴提交。三件事叠加一个人在两三轮之后就处于「手忙脚乱但产出极低」的状态。自动化攻击框架的切入点就在这里把探测、利用、取 flag、提交四件事从人工点击变成参数驱动的批处理任务。框架本质不是造新的漏洞利用方式而是把已知漏洞的利用步骤从「一次一次手打」压缩成「一轮一轮自动跑」。2.2 自动化攻击框架的四个模块探测、利用、取 flag、提交这类 AWD 专版框架核心模块翻来覆去就是四块。第一块是目标管理读入一份 targets.txt 或从裁判接口拉取在线队伍 IP 列表过滤掉自己队伍 IP 和自己的备用机第二块是利用动作对每个目标依次执行已配置的 POC比如文件上传 getshell、SQL 注入写文件、RCE 执行命令命中后记录会话标识第三块是 flag 采集通过 WebShell 通道执行cat /flag或查数据库字段按 flag 正则把结果抽出来第四块是提交器把 flag 通过 HTTP 请求或 socket 连接发到 checker 接口处理校验返回。这四块的优先级排序也是实战里的战术选择。比赛前期大家漏洞都还没补拼的是利用速度和首次拿 flag 的覆盖率所以探测和利用模块要快中期对面开始补洞、删 Webshell重点就变成权限维持和 flag 文件路径的多样性后期 checker 接口容易被高频提交打到限流提交模块就要带上退避重试。好的框架一定把这四块拆成独立组件而不是揉成一坨脚本这样某一环出问题时可以单独降级——比如 checker 崩了至少能先把 flag 收集到本地文件里等接口恢复再补交。2.3 为什么这类框架常以 zip 包形式分发伪加密与后门疑云选择 zip 而不是 Git 仓库原因很实际AWD 工具的使用场景常在赛前几小时选手在笔记本或临时云主机上部署需要一个解压即用的发布格式zip 在 Windows、macOS、Linux 上都有原生或命令行支持跨平台成本最低。同时把多个脚本、配置目录、依赖清单打包成一个文件方便分发——无论是 QQ 群传文件、网盘链接还是主办方下发都比 Git 仓库直观。但压缩包分发有一个绕不开的风险你拿到的 zip 可能被人二次打包过。常见手法是把原本干净的框架解压后塞进一个带后门的脚本再重新压成 zip 发布文件名都不改。更阴的是伪加密攻击者把 zip 目录区里的加密标志位置成 1但实际文件并没有加密内容让你解压时以为「需要密码」而去找密码或直接放弃。检测伪加密的办法后面第 5 章会细讲这里先记住一个结论任何比赛的题目包、工具包拿到后第一件事不是解压而是看压缩包的元数据和文件清单确认没有多余的可执行文件、没有异常的时间戳。把「工具本身是否可信」纳入检查项是 AWD 自动化里第一个该养成的习惯。3. 在本地跑通这套框架解压校验、环境依赖与最小启动命令3.1 拿到 zip 先别急着解压完整性校验与伪加密检测我一般拿到这类 AWD 框架包后的第一件事是先用unzip -l查看压缩包里的文件清单而不是直接解压。看清单能同时确认三件事目录结构是否符合预期、有没有混入奇怪的可执行文件比如.exe、.sh以外的二进制、各个文件的时间戳是不是集中在同一时间段。如果发现某个文件名明显和框架主题无关或者时间戳比其它文件晚了好几天那就高度怀疑被二次打包过先注意风险。unzip -l Bugku-AWD-framework.zip 7z l Bugku-AWD-framework.zipunzip -l是 Linux 下最直接的查看方式7z l则能额外显示每个条目的属性位。这里重点看每个条目名称后面有没有加密标志。如果所有条目都带*号或显示Encrypted但发布说明里又没有给出解压密码那就是伪加密的典型特征。伪加密的原理是压缩包目录区里 general purpose bit flag 的第 0 位被置为 1声明「此条目加密」但实际文件数据根本没加密解压工具看到加密标志就要求你输密码于是这个包在你眼里就成了「打不开的坏包」。如果你有把握这是别人恶意设置的伪加密常见做法是用 Python 脚本把加密标志修正掉或者直接用 7-Zip 的-ppass参数随便指定一个密码去解压——因为数据本身没加密7-Zip 会忽略错误的密码直接解出内容。import struct def fix_pseudo_encrypted(zip_path, out_path): with open(zip_path, rb) as f: data f.read() # 伪加密通常只改目录区条目逐条扫描 central directory header out bytearray(data) pos 0 while pos len(out) - 4: if out[pos:pos4] bPK\x01\x02: # central directory header 签名 # general purpose bit flag 偏移为 8长度 2 字节 flags struct.unpack(H, out[pos8:pos10])[0] flags ~0x0001 # 清除加密标志位 out[pos8:pos10] struct.pack(H, flags) # 跳过当前条目进入下一个 header name_len struct.unpack(H, out[pos28:pos30])[0] extra_len struct.unpack(H, out[pos30:pos32])[0] comment_len struct.unpack(H, out[pos32:pos34])[0] pos 46 name_len extra_len comment_len else: pos 1 with open(out_path, wb) as f: f.write(out) print(ffixed - {out_path})这段脚本的核心逻辑是扫描 zip 的 central directory header把每个条目的 encryption bit 清零后重新写回。注意它只处理伪加密——如果文件是真的加了密清掉标志只会让解压工具读出一堆乱码所以跑之前先用7z l确认所有条目确实是被「标记」而不是「数据加密」。修正完用unzip -t做一次完整性测试能跑通就说明包本身没有损坏可以进入下一步。3.2 环境依赖与运行前检查Python 版本和第三方库一个都不能少解压出来以后先看目录里的 README 或 requirements.txt。AWD 自动化框架最常见的运行时是 Python 3依赖通常是 requests、paramiko用于 SSH 连接维持权限。先检查本机 Python 版本和依赖避免跑到一半才发现缺库。python3 --version pip3 list 2/dev/null | grep -iE requests|paramiko python3 -c import requests, paramiko; print(deps ok)这三条命令分别是查 Python 大版本、查依赖库是否已安装、直接尝试 import 验证。看到deps ok说明依赖齐了。如果缺库用pip3 install -r requirements.txt装装的时候注意用国内镜像源加速别在赛前等海外源超时。另一个容易踩的点是 Python 2 和 Python 3 混用——很多老 POC 脚本是 Python 2 语法在 Python 3 环境里直接print xxx报错翻车。我一般会检查框架主入口文件开头的#!/usr/bin/env python3声明如果混着python2的脚本考虑直接用2to3批量转换或者单独用python2运行旧脚本。如果框架里包含 PHP 落地脚本或蚁剑马还要确认目标机的 PHP 版本和你本地的 PHP 客户端一致。常见做法是在本机装php-cli用于本地语法检查php -l shell.php能快速检测落地马有没有语法错误避免因为一个分号导致整个利用链失败。3.3 最小启动命令从目标列表到第一轮 flag 提交依赖齐了先用最小配置干跑一遍。这类框架通常需要一个目标列表文件、一个 flag 正则、一个 checker 提交地址。目标列表的格式一般是每行一个 IP 或IP:端口注释行用#开头。注意第一行应该写自己的靶机 IP框架靠它来排除误伤。# targets.txt 内容示例 # self 192.168.1.10 - 自己的靶机必须显式标注 192.168.1.11:80 192.168.1.12:80 192.168.1.13:8080启动命令通常是这样的形态python3 main.py \ --targets targets.txt \ --flag-regex flag\{[^}]\} \ --submit-api http://192.168.1.100:8080/api/flag \ --interval 90 \ --timeout 10这里--flag-regex是 flag 提取的正则表达式AWD 赛题里 flag 格式经常是flag{...}但有些比赛会换成ctf{...}或纯 UUID务必以赛前公布的格式为准--submit-api是 checker 的提交地址有的比赛要求带 token 认证要在配置文件里补上--interval是每轮攻击的间隔秒数设置成和比赛 flag 轮换周期一致的 90 秒确保每次都打在新 flag 上--timeout是单个目标的 HTTP 超时设太短容易误判目标宕机设太长又会在死靶机上浪费时间。跑起来之后观察前两轮日志的输出节奏正常状态应该是「探测 → 利用 → 取 flag → 提交」四步在几秒内完成然后等待下一个周期。如果前两轮没有任何 flag 提交成功不一定是框架坏了更可能是目标机器的漏洞已经被对手修复或者 flag 路径不对。这时候切到单目标、单漏洞的调试模式把 verbose 日志打开看具体是哪一步失败——这比盲目调大并发有用得多。4. 把参数调到能用的程度必调配置与战术取舍4.1 提交端配置认证方式、重试策略和 checker 限流框架能跑起来只是第一步真正决定你能不能拿分的是提交端配置。AWD 的 checker 接口通常有认证要求最常见的是在请求头里带一个赛事 token或者在 body 里带队伍 ID。这个 token 一般在赛前说明里给配置时要区分清楚是每个队伍一个固定 token还是每轮动态下发。固定 token 直接写进配置文件即可动态 token 则要考虑从裁判接口拉取这通常意味着框架需要额外做一次 HTTP 请求来刷新 token并在提交失败 401 时触发重新拉取。提交时的重试策略也需要单独调。我见过太多队伍死在「flag 提交过快」上拿到 flag 后两秒内连续提交三次第一次成功后面几次被 checker 判定为重放攻击直接把队伍 IP 拉黑几分钟。常见的保守做法是每个 flag 只提交一次成功后记录下来并进入冷却失败时区分错误码——网络超时重试格式错误不重试认证失败则刷新 token 后重试一次。# submit_with_retry.py 核心逻辑 import time, requests SUBMIT_API http://checker:8080/api/flag TOKEN your-team-token def submit(flag, max_retries2): headers {Authorization: fToken {TOKEN}, Content-Type: application/json} payload {flag: flag, team: your-team-id} for attempt in range(max_retries 1): try: resp requests.post(SUBMIT_API, jsonpayload, headersheaders, timeout5) if resp.status_code 200: return True, submitted if resp.status_code 429: time.sleep(5) # 限流等 5 秒再试不要疯狂重试 continue if resp.status_code 400: return False, bad-flag-format except requests.exceptions.Timeout: time.sleep(2) continue return False, retry-exhausted这里的参数值得细看max_retries2不是越大越好因为限流状态下重试越多、拉黑越久time.sleep(5)是给限流状态一个缓冲返回bad-flag-format时不重试说明这个 flag 本身有问题可能多复制了一个换行符或者正则没匹配完整。提交端设计的原则是「宁可漏一次不要频繁触发限流」因为限流惩罚往往影响整队的后续提交。4.2 攻击节奏参数并发、超时与每轮目标数攻击节奏参数的设置逻辑取决于比赛的具体规则你是单兵作战还是三人小队框架跑在本地还是远程云主机。本地跑的话网络延迟和本机性能是瓶颈并发数一般控制在 20 到 50 之间远程云主机带宽充裕可以适度放大。但并发数翻倍不等于效率翻倍——AWD 靶机多半是共享带宽你把对方机器打到 502自己也拿不到 flag反而暴露了攻击来源。超时参数--timeout和并发是配套调的。超时设太短一个慢速 PHP 页面还没返回就被判定失败浪费一次利用机会超时设太长一个死靶机会占住线程拖慢整体节奏。我通常的做法是先在全量目标上做一次快速存活探测ICMP 或 HTTP HEAD把不通的 IP 从列表里剔除再对存活目标跑利用。这样即使超时设置较紧也不会因为死靶机而丢失得分窗口。每轮目标数可以分批次打第一轮先打全部目标第二轮起只打上一轮成功过或未成功的子集。很多框架支持--skip-successed参数就是这个目的——已经拿过 flag 的目标如果漏洞还没被修下一轮新 flag 刷新后可以再打一次但如果连续两轮都没中就把这个目标标记为「已修复」跳过。4.3 流量侧参数延时、UA 轮换和请求加扰要不要开流量侧参数是容易被新手忽略但很影响存活率的一环。AWD 不仅是「你打别人」对手也在看自己的访问日志。如果你用默认的 Python requests UApython-requests/2.x去批量打对方靶机对方一眼就能从 access log 里筛出攻击流量然后用 WAF 规则把你的 IP 封掉。所以框架里一般会有 UA 轮换开关从预设列表里随机选 UA 发请求。这个开关建议默认开启代价只是每条请求多一次随机选择几乎不影响速度。延时参数--delay是另一个取舍点。每两个目标之间加 0.5 到 1 秒延时可以让流量特征没那么像脚本但会拖慢整轮攻击速度。比赛节奏紧的时候我一般不开全局延时只在针对单个目标的多次请求之间加 100 到 300 毫秒的随机延时这样既有一定混淆效果又不至于让一轮攻击超过 flag 轮换周期。最后是请求加扰。有些框架支持对 payload 做 Base64 编码或 URL 编码后再发送用来绕过简单的关键字检测。但要注意加扰逻辑如果只编码了 payload 而没同步编码签名或校验参数对方 WAF 可能直接根据请求结构异常来拦截反而暴露更多特征。我倾向于在赛前把加扰后的流量在本地靶机上先用tcpdump抓包看一眼再决定要不要开。5. 实战里常踩的坑从打到自己人到 zip 伪加密5.1 打到自己人的靶机目标列表忘了排除队友现象框架跑了几轮后自己队伍的靶机被自己的扫描流量打成 502flag 被自己抄走扣了防守分。原因目标列表里只写了对面队伍的 IP但框架默认把「所有可达目标」都当成攻击对象而队伍自己的靶机 IP 如果出现在目标列表里或裁判把备用机也纳入了扫描范围就会被无差别攻击。解决在 targets.txt 里用# self注释标出自己的 IP并在启动命令里显式传入--exclude-ip列表更稳妥的做法是在框架配置里写死「排除本队 C 段」因为备用机往往和主靶机在同一个子网只排除单个 IP 不够。5.2 zip 伪加密导致解压失败卡在第一步现象下载的框架包用unzip解压时报错invalid password或unsupported compression method换 7-Zip 也一样要求密码。原因发布者为了防盗版或防脚本批量转发把压缩包做了伪加密——标记加密但数据未加密或者干脆用了一个所有人都知道但你没注意到的密码比如bugku、awd这些比赛名。解决先用第 3 章的修正脚本去掉伪加密标志如果修正后仍解不开说明是真的加密那就去发布页面找密码很多比赛工具的密码就写在下载页面的注意事项里而不是 README 里。这里有个细节zip 伪加密在 Windows 自带资源管理器里表现是不弹密码框直接解压但 Linux 命令行工具会严格检查标志位——所以在 Windows 上解压正常、Linux 上报错的 zip九成是伪加密。5.3 PHP 版本差异导致 payload 失效拿不到 webshell现象框架的利用模块报告「上传成功」但访问 webshell 地址返回 404 或空白页。原因AWD 靶机环境五花八门有的跑 PHP 5.6有的跑 PHP 7.4有的开了disable_functions禁用了system、exec框架自带的 payload 如果按 PHP 5 的写法如$cmd$_POST[c];eval($cmd);在新版本下会因为短标签或函数禁用直接失效。解决赛前先对目标机器做一次指纹识别——访问/?phpinfo1或利用报错信息看 PHP 版本再选择对应版本的 payload。框架如果能支持按目标环境动态切换 payload 类型比如菜刀马、蚁剑马、哥斯拉马就优先用这种如果只有固定 payload至少准备两个版本的手动替换文件别把所有希望押在一个马身上。5.4 flag 提交过快被判攻击整队提交端口被限流现象连续两三个 flag 提交成功之后第三条提交开始返回 403看 checker 响应体是rate limit exceeded然后整队几分钟内提交什么都不成功。原因提交频率超过了 checker 的限流阈值触发的是队伍级惩罚而非单 IP 惩罚。解决在提交模块里加「单轮最多提交 N 次」的硬上限N 根据比赛目标数量估算——比如对面 20 个靶机每轮最多提交 20 个 flag再多就是重复或异常。同时把提交请求做时间抖动不要每轮都在同一秒批量提交观察 checker 的响应头里有没有Retry-After字段有就严格按它延时。这里要克制拿得到 flag 不等于有分提交端被拉黑才是真正的翻车。5.5 第七章之外flag 文件路径猜错框架空转一整轮现象日志显示利用成功、执行了命令但取 flag 模块返回空结果。原因不是所有比赛都把 flag 放在/flag有的在/var/www/html/flag.txt有的在数据库flag表里有的要执行find / -name flag*才找得到。框架默认路径如果和赛题不一致就是白忙活。解决赛前把框架的 flag 路径配置改成可配置列表按顺序逐个尝试cat /flag、cat /flag.txt、find / -name flag* 2/dev/null | head -5如果你能在赛前访问到靶机的初始环境直接确认 flag 实际位置写死在配置里比任何自动探测都快。6. 压箱底的技巧用防守侧日志反向验证攻击框架的有效性框架跑得再顺也要验证「它说成功是不是真的成功」。我自己的习惯是留一台自己的靶机做反向观察每次攻击轮次结束后立刻去自己的靶机上看 Nginx 访问日志和 WebShell 文件的最后修改时间判断对手的自动化工具是不是也在打你以及你的防御有没有挡住。这个习惯能一次性暴露两个问题如果你的框架声称打穿了对面但对面靶机上的 shell 文件在你访问时已被删除说明对手的应急响应速度比你快你的利用链需要加对抗删除的步骤反过来如果你的防御规则命中了大量对手流量说明你的攻击框架如果也按同样特征跑早晚会被同样手段防住。具体操作是在自己靶机上开 access log 的完整记录然后定期拉取分析grep -E (cmd|eval|base64_decode|system) /var/log/nginx/access.log \ | awk {print $1} | sort | uniq -c | sort -nr | head -20这条命令从 Nginx 日志里筛出包含危险关键字的访问记录按来源 IP 统计次数能看到对手有没有在批量探测你。如果发现某个 IP 频繁打eval和base64_decode那就是对方在用自动化框架打你——这时候把你的 WAF 规则里面对应的特征加到自己的配置里学到的不是攻击手法而是对手框架的流量特征反过来检查自己的框架有没有同样特征。这个反向验证习惯比任何调参都值钱自动化攻击框架的能力边界不在于它能跑多快而在于你能不能判断「哪一轮的结果是可信的」。比赛结束后我会把框架的日志和统计输出保留下来对照裁判给出的最终积分逐队看——哪些目标是稳定得分的、哪些目标是对手提前修洞而白打的、哪些目标是被友军误伤的。把这些标注在下一次比赛的 targets 文件模板里下一场比赛的配置时间至少能省两个小时。AWD 自动化攻击框架说到底是一个本地优先、参数可调、面向赛场的工具集合它的价值不是替你思考而是把重复劳动压缩到最小。祝你在赛场上少翻车、多得分希望帮到你。本文还有配套的精品资源点击获取
