简介面向AWD攻防对抗赛选手的自动化攻击框架完整源码包含项目说明与模块化代码适合具备Python基础和熟悉CTF/AWD赛制的竞赛选手作为实战模板。压缩包共66个文件以Python源码py与pyc为主辅以XML配置、SQLite数据库、Markdown说明文档及结构示意图片整体仅1.02MB目录清晰便于定位pyc为编译中间产物py为可读源码便于对照和学习框架实现思路。当前已有448人学习下载属于轻量但功能完整的参考实现。框架提供远程命令交互、内存马注入、WebShell连接、SSH口令爆破、Flag自动提交等AWD常见攻击链模块同时保留独立运行入口与配置机制支持按需拆解和二次开发结合项目说明可快速理解各模块调用关系适合赛前集训、自动化攻击脚本编写演练及代码审计训练。1. Bugku AWD专版自动化攻击框架抢分靠它不靠手速打过AWDAttack With Defense的人都懂比赛前半小时拼的是漏洞利用速度后半小时拼的是批量操作手速。靶机一多、flag一换手工发包根本忙不过来——你还在浏览器里点上传、等响应、复制flag再贴到提交框隔壁队伍已经用脚本把全场扫了三遍。Bugku AWD专版自动化攻击框架就是干这个的它把信息收集、漏洞利用、flag提取与提交串成一条自动化流水线让一个选手同时盯防多台靶机。这个压缩包里有完整源码和项目说明适合正在准备AWD比赛、想从手工操作升级到脚本化对抗的CTF选手也适合刚接触攻防竞赛、想拆开看自动化框架内部结构的安全方向学生。它能解决的核心问题很简单把“人肉重复动作”变成“机器按规则循环”让你把精力留给最值钱的决策。2. 框架拆解信息收集、漏洞利用与批量提交怎么串成一条流水线2.1 AWD 的比赛形态决定框架设计三个回合里要抢什么AWD 赛制通常是每个队伍分配几台配置几乎一样的靶机里面有预设漏洞。比赛进入攻防对抗阶段后你的得分来源有两个方向攻击其他队伍的靶机拿到 flag 提交得分同时保证自己靶机不被别人打穿。整场比赛可以分成三个节奏阶段开局阶段大家都在摸目标、确认漏洞点对抗阶段开始互相打点、抢 flag、交 flag收尾阶段比拼的是稳定性和资源调度——谁的服务还活着谁的脚本还能跑谁就赢。这种形态直接决定了框架的设计取向。开局阶段要的是快扫描和指纹识别要能在几十秒内跑完对抗阶段要的是准payload 命中率决定你的得分效率收尾阶段要的是稳日志、去重、失败重试这些细节决定你后半程会不会崩盘。所以一个能用的 AWD 自动化框架不只是把攻击请求发出去那么简单它必须把“目标发现、漏洞确认、批量利用、回传提交”这四件事做扎实而且每一步都要有容错。这里有个关键认知AWD 里自动化框架的本质不是“无脑打”而是“有限资源下的重复劳动替代”。你只有一个人、一台电脑、两只手但靶机有十几台每台可能有两个漏洞点每个漏洞点需要一轮又一轮的尝试。框架把你从这些重复动作里解放出来你只需要盯着输出结果调整策略。这也是为什么 Python 成为这类框架的主流语言——requests、paramiko、threading 这些库足够成熟写脚本快改 payload 也快不像 Go 或 C 每次改完要重新编译。2.2 核心模块拆解从目标枚举到 flag 上分的完整链路一个典型的 AWD 自动化攻击框架内部至少包含四个能独立运行的模块它们靠一个调度器串起来。目标发现模块负责端口扫描和服务指纹识别。比赛中主办方通常会给一个内网网段你需要确认哪些 IP 是靶机、开放了哪些端口。常见做法是对每个 IP 的常用端口80、443、8080、8888、3306、6379 等做 TCP 连接测试然后对命中的 HTTP 服务抓取响应头、首页哈希、框架特征跟本地维护的指纹库做比对。这里有个容易被忽略的点端口扫描的结果要缓存下来不要每轮都全量重扫。AWD 比赛中带宽和连接数都是稀缺资源全量重扫会消耗大量时间还会被对方防守脚本盯上。漏洞利用模块是整个框架的心脏它维护一个 payload 列表。每个 payload 至少要包含三部分目标 URL 路径、请求方法和一个可替换的注入参数模板。比如某个靶机的已知漏洞是一句话木马文件的代码执行那 payload 就应该是{ name: eval_webshell, target_path: /shell.php, method: POST, params: {cmd: base64_payload_here} }这个模块要能区分“测试模式”和“攻击模式”。测试模式先用无害命令确认漏洞存在比如执行echo hit看返回里有没有特征字符串确认漏洞存活后才切换攻击模式执行读 flag 的真实命令。这样做的好处是避免对已失效的漏洞点白白发动请求同时也能减少暴露痕迹。flag 提交模块解决的是“拿到之后怎么办”的问题。它从攻击模块的返回内容里用正则提取 flag存进一个内存队列然后调用比赛平台的提交接口。这个模块必须自带三个能力去重、限速、失败重试。去重是防止同一个 flag 被重复提交扣分限速是防止提交频率太高被平台封禁失败重试是应对提交接口偶发超时通常重试两次间隔三秒。框架里的调度器负责让这些模块按预定的时间轴循环运行比如每轮扫描 30 秒、攻击 60 秒、提交与等待 15 秒形成一个闭环。从开发者视角看这个框架的代码量并不大核心逻辑通常不超过两千行。它的复杂度主要来自边界情况目标服务崩溃了怎么办、flag 格式变了怎么办、提交接口返回了意料之外的 JSON 怎么办。这些边界处理做得越细实战表现越稳。源码包里的项目说明一般会写清楚模块之间的数据流和配置项含义拿到手先看说明再读代码比你直接跑起来试要高效得多。3. 把源码跑起来AWD 专版的项目结构与最小启动配置3.1 项目目录与配置文件拿到压缩包先看哪几个文件拿到Bugku-AWD专版用于AWD比赛中的自动化攻击框架源码项目说明.zip之后解压出来的目录通常遵循一个比较固定的风格——核心逻辑与配置分离payload 单独成目录方便你按比赛目标动态增删。我一般会先看一眼整体结构重点确认下面这几类文件先找项目说明文档一般是README.md或者docs/目录里面会写启动方式、依赖的 Python 版本和第三方库、以及作者标注的已知问题。这部分是作者自己踩过的坑价值往往比代码本身还高。在config/或根目录找配置文件常见命名是config.py、settings.json、conf.ini。配置里会有比赛平台的提交接口地址、目标网段、并发数、超时时间这些关键参数。紧接着看core/或lib/下的主模块列表快速理解它是怎么组织的。# 解压并查看项目结构 unzip Bugku-AWD专版.zip -d bugku-awd cd bugku-awd find . -maxdepth 2 -type f | sort这段命令先把压缩包解压到bugku-awd目录再用find列出两层以内的所有文件。因为目录太深会把输出刷得很长只看到第二层就够定位核心文件了。执行后重点关注README.md、requirements.txt、config.py和core/目录。依赖安装是第一个容易翻车的地方。这个框架基于 Python 3常用的第三方库包括requests、paramiko、python-nmap、colorlog这几个。paramiko用于 SSH 爆破和后续的靶机权限维持python-nmap做端口扫描的封装colorlog只是让比赛现场看日志更舒服没有也不影响功能。# 安装项目依赖 pip install -r requirements.txt装完后验证一下版本python3 -c import requests, paramiko; print(requests.__version__, paramiko.__version__)。如果paramiko装不上多半是系统缺少libffi-dev或openssl-devUbuntu 系机器执行apt install -y libffi-dev openssl-dev后再重装。这类底层依赖问题在比赛中时间紧的时候特别闹心我习惯在赛前一天就把运行环境用 Docker 固定下来避免现场装。3.2 最小启动流程改配置、加载载荷、看着它上分框架要跑起来第一件事是改配置。哪怕是同一个比赛平台每场比赛的 flag 格式、提交接口、目标网段都不一样。AWD 比赛的 flag 通常长得像flag{...}但有些平台会加前缀比如hw_flag{...}、ctf{...}、或者纯随机字符串。这个正则写错了后面全白跑——攻击模块把 flag 打出来了提交模块识别不出来等于空转。# config.py 核心参数示例 TARGETS [ {ip: 10.10.10.2, port: 80, os: linux}, {ip: 10.10.10.3, port: 80, os: linux}, ] THREADS 8 TIMEOUT 5 FLAG_REGEX rflag\{[^}]\} SUBMIT_URL http://10.10.10.100/api/submit INTERVAL 30这里THREADS控制并发请求数太小跑得慢太大会把靶机打挂或者让自己被对方防守脚本封 IP。TIMEOUT是单次 HTTP 请求的等待时间INTERVAL是每轮攻击之间的间隔秒数。SUBMIT_URL是比赛平台提供的 flag 提交接口 —— 有些比赛要求直接 HTTP GET 提交有些要求 POST JSON要看平台文档。改好配置后先做一次“单目标单载荷”的通路测试别一上来就打全量。找一个自己队伍可控的靶机跑单个 payload 确认能出 flag、能提交成功# 最小启动先打一个目标、一个载荷 python3 main.py --config config.py --target 10.10.10.2 --module attack --payload eval_webshell这条命令的意思是加载config.py只针对10.10.10.2这一个目标调用攻击模块里名为eval_webshell的载荷。输出日志里应该能看到“提交成功”的字样。如果通了再放开全量跑# 全量启动所有目标、所有匹配载荷 python3 main.py --config config.py --module attack --submit全量跑的时候启动一次就行框架的内部调度器会按INTERVAL的节奏自动循环。需要强调一个实战习惯不要在比赛前五分钟才开始跑框架。你要至少在开赛前半小时完成一次“配置 → 单目标验证 → 全量热身”的流程确认目标网段里有多少台活靶机、哪些端口活着、payload 能不能命中。赛前热身时跑出来的信息本身就是开局阶段最宝贵的情报。4. 常见问题与避坑AWD 自动化框架翻车的六个高频原因4.1 批量提交被服务端限流flag 到手却交不上去这个现象很典型日志里显示攻击模块已经拿到了 flag但提交模块连续报错要么超时要么返回“提交过于频繁”。原因基本都在提交频控上——比赛平台的接口对单 IP 有请求速率限制一般在每秒几次到几十次不等。框架默认的并发提交配置远超这个上限导致请求被服务端拒掉或者更糟IP 被临时封禁。解决方法是给提交模块加一个独立的限速队列。把攻击模块产生的 flag 先进一个队列提交线程按固定速率消费比如每秒最多 5 次。同时在代码里做失败退避连续三次失败就停 10 秒。实际效果是即使有二十个 flag 同时进队也只会在半分钟内完成提交不会触发平台风控。还有一个细节如果比赛平台允许通过多个入口提交比如 HTTP 和 DNS 两种通道那框架可以把 flag 轮流分配到不同通道侧面分散请求压力。4.2 没做目标隔离载荷打进了自己的靶机这个坑几乎每个 AWD 新手都会踩。自动化框架从网段里发现目标后会把所有匹配的 IP 都当作攻击对象其中往往包括自己队伍的靶机。你用一句话木马打的“目标”其实是你自己要防守的 Web 服务。等打完一看自己靶机上的文件被改了、权限被降了防守分全掉光。原因在于框架的目标列表没有排除己方 IP。解决方式很粗暴但有效在TARGETS配置里直接写死“排除列表”把本队所有靶机 IP 和本队对外出口 IP 都加进去。代码层面目标发现模块在把 IP 加入攻击队列之前要用一个集合做过滤匹配上排除列表的直接跳过。我在自己项目里还会多一层保险框架启动时先从比赛平台拉一次当前队伍信息自动生成排除列表防止手抖漏填。提示比赛开始前把排除列表单独放在exclude.txt里跟主配置分开维护。排查问题时先看这个文件别在代码里翻半天。4.3 默认载荷覆盖不了新漏洞赛后复盘才发现一直在空转AWD 比赛有个规律主办方给的靶机除了已知的几个预设漏洞通常还会埋一两个需要现场挖掘的“隐藏点”。框架自带的 payload 列表只会扫已知签名遇到隐藏点就不会有反应——它会认为这个目标“没有漏洞”然后一直空转直到比赛结束。这个问题的根源是框架缺少一个“手动补充漏洞”的入口。我习惯的做法是框架的攻击模块支持运行时动态加载 payload我现场发现一个上传点可以直接写 shell就手写一个新的 payload JSON 放进payloads/custom/目录然后给框架发一个信号重新加载不用中断正在跑的任务。AWD 比赛里真正的差距往往就在这种临场反应上框架负责把已知漏洞自动化你要留出快速注入新漏洞的空间。4.4 日志文件无限膨胀比赛后半程靶机直接卡死框架默认把每次请求的响应体、请求头、时间戳全写进日志。比赛持续一两个小时单台靶机的访问日志可以达到几百 MB攻击流量的日志如果也全量落盘本地磁盘可能先满。磁盘满了之后Python 进程趁机卡死提交线程也跟着停摆整场白打。解决思路是分级日志请求摘要记一行响应体只在调试模式下才写日志文件按大小轮转比如单个文件 20MB超过就重命名再写新的保留最近五个轮转文件旧的直接删。另一个实用技巧是让日志输出到标准输出而不是文件比赛现场用tee同时做屏幕输出和文件备份既能实时看状态又不至于单文件无限增长。4.5 提交线程和攻击线程互相抢占flag 被重复扣分框架如果用了多线程攻击线程在跑 payload提交线程在消费 flag 队列两者之间如果没有锁保护同一个 flag 可能被多个攻击线程同时提取到、入队两次。提交模块拿到两个相同的 flag如果恰好没有去重第一遍提交成功得 10 分第二遍提交被判“重复提交”扣 5 分一正一负非常亏。解决方式是在提交模块里用一个全局去重集合每次提交前先判断 flag 是否在集合里不在才提交并加入集合。同时给这个集合加线程锁防止多个提交线程同时写入导致哈希表竞态。还有一个更稳的做法不只对 flag 去重还要对“目标 IP flag”的组合去重——因为不同靶机上的 flag 可能相同但只在一台目标上打出来的同一个 flag重复提交没有意义。4.6 目标靶机访问超时框架误报“漏洞失效”而停止攻击AWD 比赛中对手也会防守常见操作是给漏洞文件改名、删除一句话木马、加 WAF 规则。框架的攻击模块遇到Connection timed out或404 Not Found时会把这个目标标记为“失效”后续轮次不再攻击。但有些时候超时不代表漏洞没了只是对方临时用防火墙阻塞了你的来源 IP或者服务因为高并发假死了几秒钟。解决方法是把“失效判定”和“攻击停止”解耦。框架可以记录每个目标连续失败的次数超过 5 次才标记为疑似失效但依然保留每 10 轮探测一次存活性的低频任务。AWD 里经常出现一种反转某台靶机前半小时全程打不通后半小时防守方自己把服务玩崩了漏洞点又暴露出来。要是框架早早放弃了这个目标你就错过了最佳得分窗口。5. 载荷编写与参数调优让框架在真实靶场里稳住得分5.1 三种常见载荷写法命令执行、文件写入与内存马AWD 比赛里最常见的漏洞入口是两类一类是代码执行型的比如一句话木马、反序列化、模板注入另一类是文件上传型的比如任意文件上传、文件包含配合写入。载荷的编写思路也因此分成三种。命令执行型载荷是最基础的。典型场景是目标靶机上已经有一个 WebShell 文件你只需要通过 HTTP 请求往里面传命令。核心技巧是命令要做混淆编码防止被流量审计设备直接识别。AWD 比赛里常见的做法是把命令用 base64 编码传进去在目标端解码再执行import base64 import requests # 命令执行载荷执行 /readflag 拿到 flag 字符串 cmd /readflag 2/dev/null || cat /flag 2/dev/null encoded_cmd base64.b64encode(cmd.encode()).decode() url fhttp://{target_ip}/shell.php # 目标一句话木马密码为 cmd参数名为 x data {x: fsystem(base64_decode({encoded_cmd}));} resp requests.post(url, datadata, timeout5) # 返回内容里可能混着其他 HTML用框架的 FLAG_REGEX 提取 flag_match re.search(rflag\{[^}]\}, resp.text)这段代码的逻辑是先把要执行的 shell 命令 base64 编码再拼进system()函数里这样网络流量中不会出现cat /flag和system这种高敏感字符串。requests.post发送 POST 请求timeout设 5 秒避免靶机无响应时线程长时间卡住。从响应里用正则提取 flag 的时候要注意有些页面会有 WAF 拦截图返回内容里没有 flag 而是提示字符串这时需要靠状态码或者内容特征来跳过这次结果。文件写入型载荷适用于目标存在上传点或者可写目录的场景它不直接执行命令而是先把一个 WebShell 写进目标磁盘再通过命令执行载荷接管控制权。AWD 比赛中这个思路特别有用上传点往往有类型限制直接传 PHP 文件会被拦截你可以先传一张合法的图片文件图片的 EXIF 信息里藏 PHP 代码再用文件包含漏洞把这个图片当成 PHP 执行成功之后框架就获得了一个稳定的持久化后门。内存马型载荷是 AWD 高阶玩法主要用于 Java 系靶机。它的特点是不落盘直接把恶意 Filter 或 Servlet 注入到运行中的 Web 容器里即使对方扫描文件系统也找不到任何恶意文件。代价是靶机一旦重启、容器重挂内存马就失效了需要重新注入。这种载荷在代码层面比前两种复杂不少涉及字节码生成和容器上下文获取但框架只要内置了一两个常用模板现场改一下 URL 路径就能用。在比赛后期当对方的文件监控脚本已经盯上 Web 目录时内存马往往比文件型后门活得久。5.2 四个必调参数并发、超时、轮询间隔与去重参数调优在 AWD 里有点像玄学每个人的网络环境、靶机配置都不一样照搬别人的配置多半要翻车。但有四个参数是每次比赛前一定要调的调好了能救命。第一是并发数THREADS。这个参数控制同时发多少个请求。并发太小一轮打不了几台靶机得分效率低并发太大靶机的 Web 服务会崩你自己的出口 IP 也会被对方防守脚本快速识别并封禁。我的经验值是从 4 开始逐步往上加到 16观察日志里的超时率如果超时率超过 20%就退回上一个值。在比赛现场我一般会空出两分钟专门做这个“压测”。第二是超时时间TIMEOUT。设短了慢一点的靶机直接超时跳过把正常响应误判为故障设长了遇到不响应的情况线程会卡很久拖慢整个循环。对 AWD 这种内网低延迟环境3 到 5 秒是比较合理的范围。如果靶机上跑了复杂的加密解密流程响应超过 2 秒很正常这时候可以把超时放到 8 秒甚至 10 秒但不要再高了——超过 10 秒的响应本身就是异常信号继续等也是浪费时间。第三是轮询间隔INTERVAL。框架每轮攻击之间的停顿时间。这个参数直接影响“你在比赛里有多显眼”。间隔太短你的扫描和攻击请求会像洪水一样涌向所有靶机对方的流量监控很容易把你标记为攻击源间隔太长你捡漏的机会就少了——AWD 的 flag 是周期性更新的你要赶在别人之前去拿新 flag。我通常设定 30 到 60 秒一轮既保持持续得分又不至于让流量特征过于刺眼。第四是去重策略DEDUPE。上面第 4.5 节讲过重复提交扣分的问题这里的去重要分两层理解对内用内存集合过滤同一轮里多个攻击线程产生的重复 flag对外要记录已经提交过的 flag 集合防止下一轮轮询时同一个 flag 被再次提取到。但注意去重集合不能无限增长一场 AWD 两小时产生的 flag 数量通常在几千到几万条内存里放一个 Pythonset完全够用不需要引入 Redis 这种额外组件。6. 验证框架效果的三个技巧把黑匣子变成看得见的得分工具框架跑起来之后你面临的最大问题不是“它跑没跑”而是“它打得有没有效果”。终端上一行行日志刷得飞快但你不知道哪些是真的在得分哪些在空转。这里有三个验证技巧能让你从黑匣子状态里跳出来。技巧一用防守视角验证攻击是否真的落地。在框架跑全量攻击的同时打开自己靶机上的一份后端日志——Apache 的access.log或者 Nginx 的访问日志用tail -f实时观察你自己的靶机流量。如果框架的 payload 真的打中了自己网段里的其他靶机那份靶机上的日志会记录到来自你 IP 的请求同样你盯自己的日志也能看到别人打你的痕迹。这种防守视角能让攻击效果立刻显形# 实时盯自己靶机的 Web 访问日志观察框架攻击是否真实命中 tail -f /var/log/nginx/access.log | grep -E eval|base64|shell.php这段命令把日志里包含eval、base64、shell.php的请求行过滤出来。如果比赛开始时日志里频繁出现这些关键词说明你的框架正在被目标执行如果一分钟内没有任何输出大概率是漏洞点已经失效或者你的目标列表指向了自己人。技巧二从比赛日志里提取时间线统计真实得分率。框架每轮的攻击结果都会被记录成一行结构化日志里面包含时间戳、目标 IP、payload 名称、是否提取到 flag。比赛结束后用正则把每一轮的 flag 提取时间点拉出来画一条时间线你会清楚地看到框架在哪个阶段密集得分、哪个阶段突然哑火。比赛现场做这个太奢侈更适合赛后复盘但赛中有个简化版每 5 分钟看一眼计数器的增量如果连续两轮增量都是零立刻切到单目标调试模式别等比赛结束再去猜。技巧三把“验证”做成框架的一个内置子命令而不是临时写脚本。我一般在框架里加一个--check参数跑一次快速的端到端测试对指定靶机执行一个无害命令载荷、确认有响应、再跑一个读 flag 的载荷、然后调提交接口发一条测试 flag、确认返回“得分”。手写验证脚本容易忘配置、忘了排除列表做成子命令之后赛前五分钟跑一遍通过就开打不通过就看日志查原因省心很多。整个路线走下来我的核心教训是AWD 自动化框架不是“跑起来就完事”的工具它需要你在赛前调参、赛中盯盘、赛后复盘。我在一次比赛中因为没做目标隔离把自己的靶机打崩直接丢了半场防守分之后就把排除列表和单目标验证写进了自己的习惯清单。如果你第一次用这套框架别贪快从单目标单载荷起步逐步放大范围跑顺了再上全量。希望帮到你。本文还有配套的精品资源点击获取