简介：面向AWD（Attack vs Defense）线下赛参赛者与网络攻防实践者，这套工具集合将比赛中高频使用的代码审计、流量监控、远程连接与端口扫描工具整合到一起，省去四处搜集和验证兼容性的时间，可直接用于靶场训练、赛前环境搭建或日常渗透测试。包体共115个文件，压缩后约92.7MB，其中包含大量php、aspx、jsp等Web脚本源码，exe、dll运行程序与依赖库，以及css、conf、ini等配置类文件，既有可直接运行的攻击辅助工具，也有用于环境适配的脚本与配置，基本覆盖Web攻防、进程运维与可视化界面的常见需求。压缩包内还附带AWD资料集合，包括比赛教程、策略指南与过往案例分析，既能帮助新手理解攻防规则，也能为老手提供战术复盘参考，是赛前快速热身的有益补充。工具链上，Nmap与masscan负责端口探测，Wireshark与tcpdump用于流量审计，Burp Suite等组件支撑Web漏洞分析，整体形成从信息收集到攻击防御的一套完整方案，对于缺少完整工具链的参赛者尤为友好。目前已有2618人学习下载。
1. AWD工具集合是什么：一场攻防对抗赛的兵器库，先解决“一个人打三个方向”的问题
AWD（Attack With Defense）是CTF攻防对抗赛里节奏最快的一种赛制：每支队伍拿到一台或几台配置完全相同的靶机，比赛一开始，既要守住自己的服务器，又要打穿对面的服务器，每隔三十分钟到六十分钟一轮，全场都在互相攻击。真正上手一次你就会发现，时间根本不够用——检查源码、修漏洞、种权限维持、看流量、打对手，这些工作一个人同时顾不过来。所谓“各种awd工具，工具集合”，就是把流量监控、漏洞利用、持久化维持、批量巡检等脚本和二进制工具按场景组织在一起，让你面对一台靶机时，先跑哪条命令、后跑哪条命令、异常看哪个输出，都有现成的路径。这篇不打算给你罗列工具清单，而是讲清楚一套可复现的搭建方法、实战节奏和翻车点，让你在下一场比赛前能直接照着做。
2. 理解AWD工具集合：从赛制节奏到工具链选型
2.1 先看清AWD的赛制与工具使用节奏
AWD的核心矛盾是“你只有一台机器，但对手有几十台”。以常见的Web AWD为例，主办方会给每队下发一台相同配置的Linux服务器，跑着LNMP或LAMP环境，网站源码里藏了一定数量的漏洞。计分规则通常是存活分加攻击分：你的靶机被其他人打穿，每轮扣分；你打穿别人的靶机，每轮加分。所以工具的用途不是单一的“攻击”或“防御”，而是围绕“别死”和“打死别人”这两个目标展开。
我把比赛时间切成三段来安排工具的使用节奏。开局前二十分钟是防御黄金期：先备份整站源码和数据库，挂上文件监控，查一遍原始源码里有没有别人预留的后门，再决定要不要上WAF。中间一小时是攻防均衡期：流量监控和文件监控保持后台运行，同时用批量脚本去打同网段的其他队伍。最后半小时是抢分窗口期：前面打下来的靶机要确认权限维持还在，分数还能持续进账，这时候更多时间花在保住已有成果上。
很多第一次打AWD的人会犯一个错误：上来就急着打别人，结果自己靶机连备份都没做，被对手一轮打穿，后面全是负分。工具集合的意义就在这里——它把“防御三件套”放在最前面，让你在慌乱里有顺序可依。比赛环境里常见的做法是，先跑一个setup.sh，把备份、监控、查马三件事一口气做完，再开始攻击。
2.2 工具集合的四大分类：流量、漏洞、加固、信息
任何一套AWD工具集合，本质都在解决四类问题。第一类是信息收集，对应“对面是什么环境、开放了哪些端口、跑了什么服务”；第二类是漏洞利用，对应“已知漏洞怎么批量打、怎么拿shell”；第三类是加固防御，对应“自己的机器怎么补洞、怎么发现被改的文件、怎么清掉别人种的马”；第四类是流量分析，对应“对手刚才用了什么姿势打进来、payload长什么样”。
这四大类不是平均用力。根据我的实战观察，新手队伍把八成精力花在漏洞利用上，老手队伍反而把六成精力放在防御和流量上。原因很简单：AWD里你能拿到的漏洞，别人也能分析出来；你打别人的同时，别人也在用同一套公开漏洞打你。流量分析工具的价值在于，当你发现自己靶机被种了后门，看一眼进出流量就能还原攻击路径，进而想起来去修那个漏洞、把所有同类型靶机都堵上。
我一般会在工具集合里按这四个分类建四个目录，而不是把一堆工具堆在同一个文件夹里。这样做的好处是，比赛中途切换任务时，你不用回忆某个脚本放在哪里，按目录找就行。另一个好处是，给目录编号之后，它们会按“信息收集→漏洞利用→加固防御→流量分析”的顺序执行，这是我在多场比赛里验证过压力最小的操作顺序。
2.3 为什么不是“工具越多越好”：武器库的取舍逻辑
网上关于AWD工具集合的分享有很多，动不动就是几十个工具的“全家桶”，看起来气势很足，实际比赛里效果往往很差。原因有三：第一，很多工具依赖特定的Python版本、特定的库，现场环境没网、没时间装依赖，工具直接跑不起来；第二，工具越多，越容易在紧急时刻选错命令，比如把清后门的脚本跑到了别人的靶机上；第三，部分平台会检查选手本机进程，一堆扫描器和利用工具同时在跑，容易被误判为作弊或触发反作弊机制。
我现在的取舍标准是：每个分类只保留两三个最可靠的方案，而且一定是自己比赛前在本地真实跑过一遍的。信息收集用nmap和目录爆破脚本；漏洞利用用sqlmap加手工EXP；加固防御用md5sum做文件校验和、用inotifywait做实时监控；流量分析用tcpdump抓包加一个提取HTTP请求的小脚本。这套组合看起来并不华丽，但每个环节都能在三十秒内启动，不需要额外装依赖，稳定压倒一切。
“最小可用”还有一层意思：你的工具集合本身要能在离线环境运行。比赛现场网络隔离是常态，不要指望现场下载任何东西，所有脚本和静态二进制都要提前打包进一个压缩文件里。我习惯把这个压缩文件同时放在本地、U盘和云盘三个位置，防止比赛时电脑出问题或者U盘读不出来。工具的选型不是秀肌肉，而是保证你在高压状态下不会因为工具本身卡住。
3. 搭建一套AWD工具集合：最小清单与目录规范
3.1 工具集合的最小目录结构
搭建一套AWD工具集合，第一步不是写脚本，而是定目录结构。没有结构的工具集合，比赛时你会陷入“找文件比执行文件更久”的困境。下面是我常用的最小目录结构，完全可以照着抄：
AWD-Toolkit/ ├── 01_info/ │ ├── nmap_scan.sh │ ├── dirsearch.sh │ └── targets.txt ├── 02_pwn/ │ ├── batch_sqlmap.sh │ ├── exp/ │ │ └── exec_payload.py │ └── shellcat.sh ├── 03_defense/ │ ├── backup.sh │ ├── file_monitor.sh │ ├── webshell_check.sh │ ├── patch_weakpasswd.sh │ └── disablescan.sh ├── 04_traffic/ │ ├── sniff_http.py │ └── tcpdump_all.sh ├── 05_persist/ │ ├── gen_ssh_key.sh │ ├── install_cron.sh │ └── clean_perist.sh ├── conf/ │ ├── my_ip.txt │ └── passwd_list.txt └── tools/ ├── sqlmap/ ├── burpsuite_pro.sh └── chkrootkit.sh这个结构的逻辑是：目录名自带编号，比赛时按编号顺序执行即可；conf目录放IP清单和弱口令字典，这类信息经常要改，独立出来方便统一修改；tools目录放第三方工具，不污染自己的脚本。值得多说一句的是targets.txt，里面按行存放对手靶机的IP地址，所有批量脚本都从这里读目标，避免在攻击脚本里反复改IP，也避免误把本机IP写进目标列表。
3.2 按场景组织脚本：巡检、利用、加固、绕过
目录定好后，真正花时间的是把每个场景的脚本写好。我的经验是，一个场景一个脚本，脚本要做成“无交互、白屏输出关键结果”的风格。比赛时你没有精力看满屏刷日志，脚本只输出最关键的结论即可。
先看加固场景最核心的备份脚本，这是整个防御的基础：
#!/bin/bash # backup.sh - 快速备份 Web 源码和数据库到 /tmp/backup WEB_ROOT="/var/www/html" DB_USER="root" DB_PASS="your_db_pass" BACKUP_DIR="/tmp/backup" # 开始备份 mkdir -p "$BACKUP_DIR" cp -a "$WEB_ROOT" "$BACKUP_DIR/web_bak_$(date +%Y%m%d_%H%M%S)" mysqldump -u"$DB_USER" -p"$DB_PASS" --all-databases > "backup_dir=$BACKUP_DIR/db_$(date +%Y%m%d_%H%M%S).sql" echo "[+] 备份完成: $BACKUP_DIR"这个脚本的逻辑很直白：cp -a保留了文件属性和软链接，对Web目录做全量复制；mysqldump把全库导出成SQL文件。参数里WEB_ROOT和DB_PASS需要在比赛现场根据目标环境修改，所以我通常会把这两个变量放在脚本开头统一标注，比赛时只需改一处。备份目录选/tmp/backup而不是/root/backup，是因为很多比赛环境没有多余的磁盘空间，/tmp是相对安全且读写快的目录。
再看文件监控脚本，这个是发现对手有没有动你文件的关键：
#!/bin/bash # file_monitor.sh - 用 inotifywait 实时监控 Web 目录的文件变化 WEB_ROOT="/var/www/html" LOG_FILE="/tmp/file_monitor.log" inotifywait -m -r -e modify,create,delete,move "$WEB_ROOT" | while read path action file; do echo "[$(date '+%H:%M:%S')] $action $path$file" >> "$LOG_FILE" done-m表示持续监控，-r递归监控子目录，-e指定监控的事件类型。这里只监控modify、create、delete、move四种事件，覆盖了对手上传webshell、修改网页、删除源文件等常见操作。脚本的弱点也很明显：如果对手绕过Web目录、直接写系统级后门，它就监控不到。所以这个脚本适合和下面的进程监控配合使用，而不是单独依赖。比赛中我一般会在攻击阶段切出去之前把它启动，并放到后台运行。
3.3 常用工具与替代方案的取舍
目录结构搭好之后，接下来是具体工具的选择。这块我不打算报菜名，只讲我在实战里验证过相对可靠的一组搭配。信息收集首选nmap，扫全端口很快，输出也稳定。需要扫描靶机开放端口时，一条命令就够了：
nmap -sV -T4 -O --open -oN 01_info/nmap_result.txt 192.168.1.0/24参数说明：-sV探测服务版本，-T4加快扫描速度，-O做操作系统识别，--open只输出开放端口的结果，-oN把结果保存为文本。对批量打多台靶机来说，这个命令能在两分钟内给出所有队伍的服务清单。有些队伍会问为什么不用更快的masscan，我的回答是：masscan快，但结果经常不完整，而且对应用层服务的判断远不如nmap细致，AWD里你不需要扫几万台机器，一个网段用nmap已经足够。
漏洞利用阶段，sqlmap是绕不开的，但直接全自动跑会很慢。我一般用--batch参数配合自己整理好的字典，快速确认站点是否可注入。Web目录爆破则用dirsearch带着常见字典跑，这两个工具在比赛环境里都能离线运行，是我每次必带的。如果比赛平台允许带静态编译的二进制，再带一个busybox，里面集成了很多常用命令，关键时刻能救命——比如系统自带的cat或netstat被替换成后门时，busybox是保持原样的。
4. 把工具集合用在实战流程：从源码检查到对抗恢复
4.1 源码审计阶段：先摸清对方给你留的洞
比赛开始后，第一件事永远是备份，第二件事是审计源码。很多人觉得源码审计要提前做，比赛时没时间。实际上你不需要审计完所有代码，只需要找出最可疑的几个文件。这里有个操作习惯值得推荐：用grep直接搜索危险函数，不要打开一个个文件去看。
grep -rn -E "eval\(|assert\(|system\(|shell_exec\(|exec\(|passthru\(|popen\(|proc_open\(" /var/www/html --include="*.php"这条命令把所有PHP文件里调用了危险函数的行都列出来，-E启用正则，-rn递归并显示行号。找到结果后，优先看带$_GET、$_POST、$_REQUEST参数拼接的行，那就是最可能被利用的注入点。对付这种漏洞，最快的方法是直接用正则替换把这些危险函数注释掉或替换成安全写法，但这个操作要谨慎，因为可能会影响站点正常功能，导致服务不可用被扣分。
在真实比赛里，我见到更多的情况是：漏洞分析确实花时间，但对手的利用速度更快。所以更稳妥的策略是先给关键文件打好补丁，再考虑修复所有漏洞。补丁的意思是：把数据库里的admin用户密码改掉、把phpMyAdmin关掉或加访问控制、把/tmp目录设置成不可执行。这些操作不需要理解漏洞原理，五分钟内就能完成，却能把大多数停留在“默认配置利用”层面的攻击挡在门外。
4.2 攻击窗口期：批量利用与批量种马
源码审计结束、基础防御上线之后，就进入攻击窗口期。这时候最常见的操作是对同网段所有IP批量跑漏洞利用。这里有一个必须强调的纪律：批量脚本一定要从conf/targets.txt读目标IP，这个文件要反复检查，绝不能包含自己的IP。常见的做法是，在脚本里把所有目标放在一个列表中，先打印出来人工确认一遍再执行。
#!/bin/bash # batch_sqlmap.sh - 对多个目标批量检测 SQL 注入 while read -r target; do [ -z "$target" ] && continue echo "[*] 检测 $target ..." sqlmap -u "http://$target/index.php?id=1" --batch --forms \ --crawl=0 --level=1 --risk=1 \ --dbs --timeout=10 --retries=1 \ -o 02_pwn/report_$target.txt 2>/dev/null done < conf/targets.txt参数说明：--batch跳过所有交互确认；--forms让sqlmap自动填充页面表单；--crawl=0只测起始页面，不加爬虫深度，省时间；--level=1和--risk=1用最低检测等级，只测最常见注入点，保证速度；--timeout=10防止卡死；-o把结果输出到独立文件。最后2>/dev/null把报错信息丢弃，避免屏幕上全是sqlmap的调试日志影响判断。
批量利用成功之后，立刻要做的是权限维持。我倾向于用最轻量的方式：如果拿到的是RCE权限，先创建一个带SSH密钥的隐藏用户，或者把公钥写到目标机器的authorized_keys里。注意不要依赖单一维持手段，因为对手和主办方都会定期检查。比赛中比较稳定的维持方式是写一个定时任务，每隔几分钟把当前shell反弹回来，但在反弹地址上要小心，别把反弹命令明文写在容易被发现的文件里。
4.3 防御窗口期：流量分析、文件监控与快速恢复
攻击的同时，防御不能停。这里说的防御不是一个固定动作，而是一个持续循环：发现异常、定位原因、修复漏洞、恢复文件。我习惯在攻击窗口期每十五分钟切回来看一次file_monitor.log和/tmp/backup目录，确认自己的靶机没有被对手动过手脚。
流量分析是这个循环里最关键的输入。一条简单的tcpdump命令，可以看到谁在访问你的靶机、用了什么payload：
tcpdump -i eth0 -s 0 -w /tmp/capture_$(date +%s).pcap # 抓完包后，用 tshark 快速提取 HTTP 请求，只保留 URL 和 UA 头 tshark -r /tmp/capture_*.pcap -Y "http.request" -T fields \ -e ip.src -e http.request.method -e http.request.uri -e http.user_agent-i eth0指定网卡，-s 0表示抓完整数据包，-w保存到pcap文件。后面用tshark过滤出HTTP请求，-Y是显示过滤表达式，-T fields指定只输出这几个字段。这样你看到的不是乱码，而是一列“谁、用什么方法、请求了什么路径、用什么User-Agent”的清单。攻击者通常会用curl或Python脚本打你，UA特征明显，看一眼就能锁定可疑来源。
一旦确认被攻击，恢复的顺序也有讲究：先把后备的webshell查一遍，再恢复源码和数据库，最后才上WAF。很多人顺序反了，先上WAF，结果源码里的后门还在，等于给对手留了个暗门。恢复文件时只恢复被污染的那部分，不要整个目录回滚，因为对手可能在你回滚后立刻再打一次，你还需要留日志分析。这时候备份脚本的意义就体现出来了：你有干净的源码副本，就有了后悔药，不至于被同一招反复打穿。
5. 避坑与排查：AWD工具使用中的五个常见掉链子
5.1 工具版本与本地环境不匹配
现象：比赛现场运行python3 exploit.py，报错ModuleNotFoundError: No module named 'requests'，现场又没网，pip装不上，整个利用流程卡死。
原因：很多AWD工具脚本依赖第三方库，你在本地有网环境测试时一切正常，比赛环境却什么都没装。这是工具集合里最高发的翻车点，没有之一。还有一个隐蔽情况是，目标机器上可能没有python3命令，只有python，但你写的脚本第一行固定调python3，也会直接跑不起来。
解决：提前把所有脚本改成纯标准库实现，不依赖第三方模块；或者用静态编译的Python二进制打包进工具集合。最省事的做法是把脚本调用的解释器写成变量，运行时先探测环境再决定执行方式。另外，所有核心脚本至少要在一台干净的全新系统上跑通一次，确认不依赖你本地安装过的任何“巧合”库。
5.2 批量利用脚本误伤自己被反打
现象：批量脚本跑了一轮，发现自己的靶机被种了马，检测日志里全是自己脚本的痕迹，对手顺着来源反向拿到了你的权限。
原因：targets.txt里手滑写入了自己的内网IP，或者脚本里用网段前缀匹配时把本机IP包含了进去。另一个常见原因是，某些漏洞利用payload会反弹shell到写死的IP，如果之前测试时用的IP没改，反弹shell会打到你自己机器上。
解决：给批量脚本加一个强制黑名单，脚本启动时自动读取本机所有网卡IP，比对后从目标列表里移除；执行之前先把目标列表打印出来人工扫一眼。反弹shell的地址统一写在conf/my_ip.txt里，每次比赛前单独检查这个文件。宁可慢一分钟，不要打到自己人，这是批量脚本的第一原则。
5.3 备份恢复脚本的坑：备份的是壳、丢的是马
现象：被对手打穿后，用备份恢复源码，结果上线后门还在，对手持续得分，你却始终找不到后门藏在哪里。
原因：备份脚本只备份了/var/www/html目录，但对手的权限维持手段写在其他位置，比如/usr/lib下的恶意so、/etc/ld.so.preload里的预加载劫持、系统定时任务里的反弹shell。你用备份恢复了网页文件，系统层面的后门原封不动，等于只修了表没治病。
解决：备份范围扩大，除了Web目录，还要把系统关键位置的哈希表保存下来：/etc/passwd、/etc/crontab、/usr/bin下的关键命令、/tmp、/dev/shm。恢复时先对照哈希表找到新增文件，再决定是否回滚。我现在的备份脚本会在备份Web目录后用一下md5sum生成全盘基线，比赛中间做完整性校验就是用它，比自己猜哪里有后门靠谱得多。
5.4 权限维持被队友或被防护清掉
现象：辛辛苦苦打下来的靶机，过了一轮发现权限没了，分数也没进来，更无语的是不知道是谁清的。
原因：AWD靶机通常不只有你在攻击。你种了一个后门，其他队伍打进来之后顺手清理了所有可疑文件，把你提权的账号也删了。另一种情况是你自己队伍里的队友不知道哪些文件是你的维持手段，在“加固”时误删了权限维持文件。
解决：权限维持多做几层，且互相独立：Web层留一个不死马，系统层放一个定时任务，SSH再留一个密钥。多层保证其中一层被清，另一层还能回来。同时要跟队友约定好，防御操作只动Web源码和安全配置，不碰系统级定时任务和隐藏文件，让“清除可疑文件”前先口确认。比赛里最可怕的不是对手强，而是队友把你的后门当作对手的后门清了。
5.5 工具被上传检测拦下：webshell查杀的对抗
现象：用常见的webshell管理工具上传小马上线，刚落地就被检测系统告警，站点被置为隔离状态，整个攻击计划暴露。
原因：比赛平台大多部署了webshell查杀引擎，常见的一句话木马、加密马特征太明显，直接上传必然触发告警。很多选手以为绕过查杀就是改特征，结果越改越夸张，反而容易被盯上。
解决：不要执着于对抗查杀，可以用更弱的痕迹换取更大的隐蔽性。比如不传文件，直接通过命令执行写入内存马；或者利用已有合法脚本，在业务代码里注入少量逻辑；再或者打持久化的落点选在日志目录、/tmp这种查杀扫描很少覆盖的位置。比赛的本质是得分，不是秀免杀。只要你的攻击能让对手慢一小时发现，就已经建立了巨大优势。查杀对抗这块，我个人的习惯是提前准备三个不同风格的马，赛前在本地查杀引擎里测一遍，只保留能过检的，而不是临时改。
6. 让工具集合更好用：本地自测沙箱与打包发布技巧
6.1 用容器搭一个30秒启动的本地靶场
任何工具集合都要在比赛前自测，我一般用容器在本地搭一个虚拟靶场，30秒内启动，专门用来验证脚本的可用性。这个沙箱容器只装一个最简单的Web服务，故意留一个执行漏洞，然后依次跑备份、监控、利用、恢复整套流程。这样做的好处是，比赛时工具集合里的每个脚本至少是刚刚验证过能跑的，不会被环境问题打乱节奏。我见过太多队伍赛前不测，开赛五分钟发现sqlmap连不上目标、监控脚本因为路径写错一直在报错，白白浪费宝贵的防御窗口期。
6.2 把常用命令封装成一条命令入口
工具集合如果只是堆一堆脚本，比赛时还是会手忙脚乱。我习惯在根目录放一个总控脚本，把最常用的操作收拢成一条命令，比如直接执行备份、启动监控、查看当前得分状态。这样一来，无论多紧张，你只需要记住三个操作：./awd.sh backup、./awd.sh monitor、./awd.sh status。封装的核心不是炫技，而是把需要思考的步骤提前变成习惯动作，把注意力留给真正需要判断的攻防决策。赛事进行到最后半小时，你基本没有精力在目录里翻找脚本，一条命令入口的价值就会被放大好几倍。
6.3 赛前工具自检清单与团队同步
最后分享一个我自己的赛前自检习惯：用三分钟把工具集合从上到下过一遍。第一，检查targets.txt和my_ip.txt是否更新为当前赛场网段；第二，备份脚本在本地沙箱再跑一次，确认数据库密码还能对上；第三，所有脚本文件权限设为可执行，避免比赛时发现没有执行权限；第四，压缩包同时存在于本机和U盘。这四个动作做完，工具集合这块就基本不会掉链子。跟团队同步是另一个容易被忽视的点：至少让队友知道备份文件放在哪个目录、监控日志在哪个文件、恢复脚本要怎么启动，避免你掉线之后整个防御体系瘫痪。我吃过一次亏，赛前忘了告诉队友备份路径，赛中被打击后队友等了一个小时也没找到怎么恢复，那次之后自检清单里永远多一条“团队同步”。希望这些细节能帮到你，让下一场AWD不再因为工具本身乱了阵脚。
本文还有配套的精品资源，点击获取
