Bugku-AWD自动化攻防框架源码拆解与实战指南

📅 发布时间:2026/10/6 8:25:59
Bugku-AWD自动化攻防框架源码拆解与实战指南
简介这份资源是面向AWD攻防竞赛的自动化攻击框架源码包适合有一定Python基础、希望提升比赛效率的CTF选手与安全学习者参考。项目围绕AWD场景下的批量攻击与命令控制展开涵盖攻击核心、内存马管理、SSH与冰蝎等后门交互、请求发送与配置管理等模块可作为理解自动化攻防工具设计思路的实战样本。压缩包共66个文件以py与pyc源码为主辅以xml配置、png示意图、md说明及db数据文件整体约1.02MB结构紧凑、便于本地运行调试。目前已有448人学习下载读者可从中获取完整的框架目录组织、模块划分方式与关键实现代码结合项目说明逐步梳理攻击流程与配置逻辑进而按自身需求扩展功能或移植到其他竞赛环境适合作为攻防竞赛备赛与安全工具开发的参考资料。1. 拆开 Bugku-AWD 专版一套能直接跑起来的自动化攻防框架长什么样如果你打过 AWDAttack With Defense线下赛大概经历过这种场面比赛开始前十分钟别人还在手忙脚乱地配 SSH、翻目录、找 flag 路径隔壁队伍已经批量提交了三轮 flag。差距往往不在手速而在于有没有一套趁手的自动化框架。Bugku-AWD 专版就是干这个的——它是一套用 Python 写的 AWD 比赛自动化攻击框架把目标发现、命令下发、内存马注入、flag 自动提交这些重复动作串成流水线。整个项目以源码形式打包入口是start.py核心逻辑集中在code/目录下的AttackCore.py、AutoAck.py、SshAck.py、BehinderAck.py等模块配置走config/下的SimpleConfig.py和MemShellConfig.py数据落在data/Awd.db。它适合有一定 Python 基础、想理解 AWD 自动化攻击链路怎么搭的竞赛选手也适合把源码当学习材料、拆解模块设计的开发者。下面我按「这是什么 → 怎么配 → 怎么跑 → 坑在哪」的顺序把这份源码拆一遍。2. 模块拆解与运行环境从 start.py 到 AttackCore 的调用链2.1 目录结构与各模块职责拿到压缩包解压后先别急着python start.py花五分钟把目录结构过一遍后面调参会省很多事。整个工程的骨架大致是这样路径作用start.py程序入口负责初始化配置、加载数据库、启动攻击主循环code/AttackCore.py攻击核心调度串联各类攻击模块code/AutoAck.py自动化攻击流程封装批量对目标执行动作code/SshAck.py基于 SSH 的远程命令执行模块code/BehinderAck.py冰蝎Behinder内存马相关交互code/MemShell.py内存马管理配合MemShellConfig.py使用code/RecvCmd.py接收/解析命令处理回传结果code/SendReq.py请求发送封装统一处理 HTTP 交互code/func.py通用工具函数集合config/SimpleConfig.py基础配置项目标、端口、凭据等config/MemShellConfig.py内存马相关配置db/Utils.py数据库操作封装读写data/Awd.dbdata/Awd.dbSQLite 数据库存目标信息、flag 记录等从调用链看start.py拉起后会读取SimpleConfig.py里的配置通过db/Utils.py把目标写进Awd.db然后交给AttackCore.py调度。AttackCore再根据攻击类型分发给SshAck、BehinderAck或AutoAck。理解这条链出问题时你才知道该去哪个文件打断点。2.2 环境依赖与 Python 版本源码里能看到__pycache__下是cpython-36.pyc说明作者当时用的是 Python 3.6。这个信息很关键——如果你用 Python 3.11 直接跑某些老库的 API 可能已经变了。稳妥做法是建一个 3.6 或 3.7 的虚拟环境。常见依赖包括requestsHTTP 交互、paramikoSSH 连接、flaskReqFlagServer.py里可能起的接收服务等。我一般会先跑一遍导入检查看缺什么补什么# 建虚拟环境建议 3.6/3.7 python3.7 -m venv venv source venv/bin/activate # 先尝试导入主模块报什么缺什么 python -c import requests, paramiko如果报ModuleNotFoundError按提示pip install对应包即可。注意paramiko在新版本里对旧 SSH 算法的支持有变化如果连目标时提示算法协商失败可以降到paramiko2.7.2这类较老的版本这是打老靶机时的血泪经验。2.3 配置文件怎么改config/SimpleConfig.py是你要动的第一个文件。里面通常定义了目标 IP 列表、SSH 端口、用户名密码、flag 提交接口地址等。改之前先备份一份原始配置方便对照。典型改动是把目标地址换成你比赛环境的网段把提交接口换成赛事平台的地址。MemShellConfig.py则是内存马相关的参数比如马的类型、密码、连接路径。这两份配置分开设计是有道理的基础连接信息和攻击载荷解耦换比赛环境时只动SimpleConfig攻击手法不用重配。提示改配置前先cp config/SimpleConfig.py config/SimpleConfig.py.bak调崩了能快速回滚别问我是怎么记住这条的。3. 自动化攻击链路实操从目标录入到 flag 提交3.1 把目标写进 Awd.db框架用 SQLite 存目标信息db/Utils.py封装了增删改查。你可以直接改配置让程序自动录入也可以手动往库里塞。先看看库结构sqlite3 data/Awd.db .tables sqlite3 data/Awd.db .schema搞清楚表名和字段后批量录入目标就顺手了。假设表叫targets字段有ip、port、user、passwd# 用 db/Utils.py 里的封装批量插入避免手写 SQL 出错 from db.Utils import DBUtils db DBUtils(data/Awd.db) targets [ {ip: 192.168.1.10, port: 22, user: root, passwd: toor}, {ip: 192.168.1.11, port: 22, user: root, passwd: toor}, ] for t in targets: db.insert_target(t) # 方法名以实际源码为准这里的关键是别硬编码 SQL 字符串用封装好的方法字段名对不上时改一处就行。Awd.db同时还会记录已提交的 flag避免重复提交被平台判无效这个去重逻辑在Utils.py里值得读一遍。3.2 SSH 批量命令执行SshAck.py负责 SSH 通道。AWD 里拿到一台机器后常见动作是找 flag、读配置、留后门。批量执行的核心是复用连接、控制并发别一个目标开一个线程把对面打挂。下面是一个调用示意from code.SshAck import SshAttack # 单目标执行命令返回 stdout attacker SshAttack(host192.168.1.10, port22, userroot, passwdtoor) out attacker.exec_cmd(cat /flag) # 具体方法名以源码为准 print(out)参数上要注意超时设置。默认超时如果太长一个死目标会拖住整个循环太短又容易误判。我一般把连接超时设 3 秒、命令超时设 5 秒比赛环境网络抖动大这个值比较稳。并发数别超过目标数的三分之一否则 SSH 握手容易被限流。3.3 内存马注入与 Behinder 交互BehinderAck.py和MemShell.py是这套框架里技术含量较高的部分。思路是通过已拿到的入口比如 Web 漏洞注入内存马再用冰蝎客户端协议去连。MemShellConfig.py里配马的类型和密码。注入成功后后续命令走内存马通道比反复打漏洞稳定。这块调试建议先在本地靶机验证起一个存在上传或反序列化漏洞的 Web 服务走一遍注入流程确认马能连上、命令能回显再上比赛环境。直接在线比赛环境调内存马翻车概率极高。3.4 flag 自动提交与去重ReqFlagServer.py和SendReq.py配合完成 flag 提交。流程是攻击模块拿到 flag → 交给提交模块 → 提交前查Awd.db看是否已交过 → 未交则发请求。提交接口的地址、参数格式在SimpleConfig.py里配。这里有个细节很多平台对提交频率有限制提交模块里最好加个间隔比如每提交一条 sleep 0.5 秒。源码里如果没做限速自己补一个否则容易被平台风控。4. 避坑与排查那些让框架跑不起来的常见问题4.1 现象start.py 一跑就报编码错误原因源码里有中文注释或字符串Python 3.6 在某些系统默认编码不是 UTF-8读文件时炸。解决在文件头确认有# -*- coding: utf-8 -*-或者运行时设export PYTHONIOENCODINGutf-8。CmdColor.py里如果有彩色输出转义Windows 终端下也可能乱码换 Linux 或 WSL 跑。4.2 现象SSH 连上了但命令没回显原因目标 shell 是非交互式或者命令输出走了 stderr。SshAck.py如果只读 stdout就会漏。解决执行时把 stderr 重定向到 stdout命令写成cat /flag 21或者在exec_cmd里同时读两个通道。这个坑在打一些精简版容器时特别常见。4.3 现象内存马注入成功但连不上原因马的类型和客户端协议不匹配或者密码配错。MemShellConfig.py里的密码要和 BehinderAck 连接时用的一致。解决先用冰蝎图形客户端手动连一次确认马是活的、密码对再让框架去连。别跳过手动验证这步否则你会在框架日志里找半天。4.4 现象flag 提交返回「已提交」或「无效」原因Awd.db里的去重记录和平台状态不同步或者 flag 格式没对齐多了换行、少了前缀。解决提交前对 flag 做 strip去掉首尾空白去重逻辑以平台返回为准别只信本地库。我一般会在提交模块里加一行日志把原始 flag 和提交结果都打出来方便对账。4.5 现象并发一高目标就掉线原因并发数设太大SSH 或 HTTP 连接被目标限流。解决把并发降到个位数加连接复用和重试。AWD 比赛里稳定性比速度重要打挂对面自己也拿不到分。5. 进阶玩法把框架改成你自己的攻击流水线源码跑通只是起点真正拉开差距的是按比赛环境改造它。我一般会做三件事。第一把AttackCore.py的调度逻辑抽出来做成可插拔的模块注册机制——新攻击手法写成一个类注册进去就行不用改主循环。第二给Awd.db加一张actions表记录每个目标执行过哪些动作、结果如何赛后复盘时能看清哪条链路有效。第三把 flag 提交模块的限速和重试做成配置项不同平台风控强度不一样现场调参比改代码快。验证改造是否成功别只看「跑起来了」要看三个指标目标覆盖率配置里的目标有多少被成功处理、flag 提交成功率、单轮耗时。我习惯在start.py末尾加一段统计输出每轮结束打印这三个数。如果覆盖率上不去多半是连接或认证问题提交成功率低查 flag 格式和限速耗时突然变长看是不是某个目标超时拖累了整体。还有一个容易被忽略的点这套框架的模块命名和调用关系是作者按自己习惯定的你二次开发时最好先画一张调用图标清数据流向。不然改了一个模块另一个模块静默失败排查起来就是黑匣子。我吃过这个亏——有次改了SendReq.py的请求头结果BehinderAck.py依赖的某个字段被覆盖内存马通道直接哑了查了两小时才发现是耦合问题。从那以后我每次动公共模块前都强制走一遍全链路回归SSH 通、内存马通、flag 提交通三样都过才继续。希望这套拆解能帮到你把这份源码真正用起来而不是让它躺在硬盘里吃灰。本文还有配套的精品资源点击获取