简介：CTF线下AWD脚本合集是一份面向网络攻防竞赛选手的实战工具包，尤其适合刚接触AWD模式、不熟悉自编脚本的新手，也便于有经验的选手优化攻防流程。AWD要求参赛队伍在攻击对手系统的同时保护自身服务，对脚本化、自动化能力要求较高，该合集正是为节省编写与调试时间而整理。压缩包共34个文件，约3.18MB，以Python脚本、PHP木马与Webshell、txt说明文档为主，另含pyc编译文件、md说明及少量rar、exe工具，覆盖扫描探测、自动化攻击、不死马与WAF防御、日志分析、Flag获取等环节，目录结构清晰，便于按攻防阶段快速取用。目前已有3010人学习下载，可作为赛前熟悉攻防逻辑、积累常用脚本与排错思路的参考，使用时请遵守法律法规，仅限合法CTF比赛环境。
1. 从一份 AWD 脚本合集说起：线下攻防到底在拼什么
打过线下 AWD（Attack With Defense）的人都有一个共同感受：比赛开始后的前十分钟，比的是谁的手速和脚本准备得更充分。题目环境一开放，别人还在手敲ssh登录、手动cat /flag，你这边已经批量改完密码、批量提交 flag、批量部署 WAF 规则了——差距就是这么拉开的。所谓「CTF线下AWD脚本合集.zip」，本质上就是把这套「开局十分钟」的自动化动作沉淀成可复用的脚本集合，覆盖改密、拿旗、提交、防御加固、流量监控这几件事。它解决的不是某一道题的解法，而是把重复劳动压缩成一条命令，让你把精力留给真正的漏洞利用和权限维持。适合谁？适合已经打过一两场 AWD、被手速和体力拖垮过、想系统化自己工具箱的人；纯新手也能照着跑，但得先理解每条命令在干什么，否则脚本翻车时你连日志都看不懂。
2. 开局三件事：改密、拿旗、提交的脚本骨架
AWD 的节奏是固定的：环境开放 → 改掉默认密码 → 找到并提交 flag → 加固防守 → 循环。脚本合集的价值就在于把前三步做成一条流水线。下面按「先跑通最小闭环，再补防御」的顺序拆。
2.1 为什么改密脚本要放在第一条执行
AWD 里最常见的失分不是被攻破，而是被对手用默认密码直接登录你的机器，把你的 flag 提交走、把你的服务改坏。所以开局第一件事永远是改密。常见做法是维护一个目标主机列表，用sshpass批量登录后执行passwd或直接改服务后台密码。
#!/bin/bash # change_pass.sh - 批量修改 SSH 密码 # 依赖: sshpass (apt install sshpass) HOSTS=("10.0.0.1" "10.0.0.2" "10.0.0.3") OLD_PASS="ctf" NEW_PASS="Awd@2025_$(date +%s)" for host in "${HOSTS[@]}"; do sshpass -p "$OLD_PASS" ssh -o StrictHostKeyChecking=no root@"$host" \ "echo -e '${NEW_PASS}\n${NEW_PASS}' | passwd root" \ && echo "[+] $host 改密成功: $NEW_PASS" \ || echo "[-] $host 改密失败，检查网络或旧密码" done逻辑说明：StrictHostKeyChecking=no跳过首次连接的指纹确认，避免脚本卡在交互提示；NEW_PASS用时间戳拼接，保证每场密码不同，防止对手从上一场记录里复用。参数上，HOSTS数组要按你实际的靶机网段填，OLD_PASS是平台给的初始密码，通常赛前会公布。改密失败最常见的原因是旧密码不对或 SSH 端口不是 22，遇到失败先手动ssh登一台确认，别盲目重跑。
提示：改密后立刻把新密码写进一个本地文件，脚本后续的拿旗、加固都要用它，别改完就忘了。
2.2 拿旗脚本：定位 flag 路径的三种常见套路
flag 的位置每场比赛都不一样，但套路就那么几种：固定路径（/flag、/flag.txt）、数据库里、Web 目录下、环境变量里。拿旗脚本的核心是「广撒网 + 去重」，把所有可能位置扫一遍再统一输出。
#!/usr/bin/env python3 # grab_flag.py - 多路径扫描 flag import subprocess, re, hashlib CANDIDATES = [ "/flag", "/flag.txt", "/root/flag", "/tmp/flag", "/var/www/html/flag.php", "/home/ctf/flag" ] def run(cmd): try: return subprocess.check_output(cmd, shell=True, stderr=subprocess.DEVNULL).decode(errors="ignore") except Exception: return "" seen = set() for path in CANDIDATES: content = run(f"cat {path} 2>/dev/null") # 匹配常见 flag 格式 flag{...} 或 32 位十六进制 for m in re.findall(r"flag\{[^}]+\}|[0-9a-f]{32}", content): h = hashlib.md5(m.encode()).hexdigest() if h not in seen: seen.add(h) print(f"[+] {path} -> {m}")逻辑说明：CANDIDATES是经验路径池，实际比赛里可以再加/proc/self/environ（环境变量）和数据库导出。用md5去重是因为同一个 flag 可能出现在多个位置，重复提交会被平台判无效。参数上，正则flag\{[^}]+\}覆盖大多数平台格式，如果你们平台用纯十六进制，第二个分支兜底。跑完没输出，说明 flag 不在这些路径，转去查数据库或 Web 源码。
2.3 提交脚本：别让手速毁在接口限流上
拿到 flag 后要提交到平台接口。很多新手栽在这里：要么接口参数写错，要么提交太快被限流。提交脚本要处理三件事——正确的接口地址、正确的 token、合理的间隔。
#!/usr/bin/env python3 # submit_flag.py - 批量提交 flag import requests, time API = "http://platform.example.com/api/submit" TOKEN = "your_team_token_here" FLAGS = ["flag{xxx}", "flag{yyy}"] for f in FLAGS: resp = requests.post(API, data={"flag": f, "token": TOKEN}, timeout=5) print(f"[{resp.status_code}] {f} -> {resp.text}") time.sleep(1.5) # 间隔 1.5 秒，避开限流逻辑说明：timeout=5防止接口卡死拖垮整个脚本；time.sleep(1.5)是血泪经验，很多平台对同一队伍的提交频率有限制，间隔太短会返回「提交过于频繁」甚至临时封禁。参数上，API和TOKEN每场比赛都不同，赛前从平台页面抓一次。如果返回 403，先检查 token 是否过期；返回 429，把间隔调到 3 秒以上。
3. 防御脚本：WAF 规则、文件监控与流量告警
拿旗只是上半场，AWD 的分数大头在「守住」。对手会不断尝试打你的服务，防御脚本要能自动挡掉常见攻击并留下告警。这一章讲三个最实用的防御脚本。
3.1 用 Nginx 配置快速挡掉常见 Web 攻击
Web 题是 AWD 的重灾区，SQL 注入、文件上传、命令执行轮番上。与其一个个改代码，不如在 Nginx 层加一层规则，把明显的恶意请求拦掉。
# /etc/nginx/conf.d/awd_waf.conf # 拦截常见攻击特征 server { listen 80; server_name _; # 拦截 SQL 注入关键词 if ($args ~* "(union.*select|select.*from|sleep\(|benchmark\()") { return 403; } # 拦截命令执行 if ($args ~* "(;|\||`|\\$\(|passthru|system\()") { return 403; } # 拦截敏感文件访问 location ~* \.(git|svn|env|bak)$ { deny all; } }逻辑说明：$args匹配 URL 查询串，~*表示不区分大小写。第一条挡 SQL 注入的典型 payload，第二条挡命令执行的分隔符和函数名。注意if在 Nginx 里有「if is evil」的说法，这里只做简单拦截，不涉及复杂逻辑，风险可控。参数上，规则要按你实际的服务调整——如果你的业务本身就有select参数，会误伤，得加白名单。改完nginx -t测试再nginx -s reload。
注意：WAF 规则是双刃剑，误拦正常请求会直接掉分。上线前一定用正常业务请求测一遍。
3.2 文件完整性监控：第一时间发现被上传的 webshell
对手拿到权限后通常会传 webshell 维持访问。文件监控脚本定时比对 Web 目录的哈希，发现新增或修改就告警。
#!/usr/bin/env python3 # monitor.py - Web 目录文件监控 import os, hashlib, time, json WATCH_DIR = "/var/www/html" BASELINE = "baseline.json" def snapshot(path): result = {} for root, _, files in os.walk(path): for f in files: fp = os.path.join(root, f) try: with open(fp, "rb") as fh: result[fp] = hashlib.md5(fh.read()).hexdigest() except Exception: pass return result if not os.path.exists(BASELINE): json.dump(snapshot(WATCH_DIR), open(BASELINE, "w")) print("[*] 基线已建立") else: base = json.load(open(BASELINE)) now = snapshot(WATCH_DIR) for fp in now: if fp not in base: print(f"[!] 新增文件: {fp}") elif now[fp] != base[fp]: print(f"[!] 文件被改: {fp}")逻辑说明：第一次运行建立基线，之后每次运行对比。新增文件大概率是 webshell，被改文件可能是对手在改你的代码。参数上，WATCH_DIR按实际 Web 根目录填，BASELINE存到 Web 目录外，防止被对手删掉。这个脚本配合crontab每分钟跑一次，基本能第一时间发现入侵。
3.3 流量告警：从 access.log 里捞出攻击者 IP
被打了要能知道是谁打的、打了什么。从 Nginx 的access.log里统计高频 IP 和可疑请求，是成本最低的告警方式。
#!/bin/bash # traffic_alert.sh - 分析 access.log 找出攻击源 LOG="/var/log/nginx/access.log" echo "=== 请求量 Top 10 IP ===" awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -10 echo "=== 含攻击特征的请求 ===" grep -iE "(union|select|passwd|cmd=|eval\()" "$LOG" | tail -20逻辑说明：第一条统计请求量最高的 IP，AWD 里对手的扫描器往往请求量异常大；第二条捞出带攻击特征的请求，方便你定位攻击手法。参数上，LOG路径按实际填，如果日志被轮转，记得处理.gz文件。发现攻击 IP 后，可以用iptables直接封掉，但要注意别封到平台自己的健康检查 IP。
4. 避坑与排查：AWD 脚本最容易翻车的五个地方
脚本写得好不好，赛场上见真章。下面这五个坑，我基本每场都能见到有人踩。
坑一：改密脚本把平台健康检查也改了。现象是改完密码后平台显示服务异常、掉分。原因是平台用固定账号做存活检测，你把这个账号密码改了。解决：改密前先确认哪些账号是平台专用的，通常赛前文档会说明，只改自己的运维账号。
坑二：拿旗脚本扫到蜜罐 flag 被扣分。现象是提交后分数不升反降。原因是有些题目故意放假的 flag，提交会扣分。解决：拿旗脚本加一层校验，只提交符合平台格式且来源可信的 flag，不确定的先手动确认。
坑三：提交脚本并发太高被平台封 token。现象是提交接口全部返回 403，后续正常提交也失败。原因是短时间大量请求触发风控。解决：串行提交，间隔至少 1.5 秒，被封后联系裁判解封，别硬刚。
坑四：WAF 规则误拦正常业务导致服务不可用。现象是对手没打进来，自己人访问也 403。原因是规则太宽，把正常参数也拦了。解决：规则上线前用正常请求回归测试，宁可少拦也别误拦。
坑五：监控脚本的基线文件被对手删掉。现象是监控突然不告警了。原因是基线存在 Web 目录里，对手拿到权限顺手删了。解决：基线文件存到 Web 目录外，并加只读权限。
5. 把脚本合集用出复利：赛前演练与模块化改造
脚本合集不是拿来就能用的，直接跑大概率翻车，因为每场比赛的网段、密码、接口、flag 格式都不一样。真正会用的人，赛前会做两件事：一是把脚本里的硬编码参数抽成配置文件，二是拿本地靶机完整演练一遍。
先说模块化。上面那些脚本，HOSTS、OLD_PASS、API、TOKEN、WATCH_DIR这些参数每场都变，硬编码在脚本里改起来容易漏。我一般会抽一个config.yaml：
# config.yaml hosts: - 10.0.0.1 - 10.0.0.2 old_pass: "ctf" api: "http://platform.example.com/api/submit" token: "your_team_token" watch_dir: "/var/www/html"然后脚本里用yaml.safe_load读进来。这样换一场比赛只改一个文件，脚本本体不动。参数校验也要加：hosts为空直接退出，token没填就报错，别让脚本带着空参数跑。
再说赛前演练。找两三台本地虚拟机，一台当靶机、一台当攻击机，把改密、拿旗、提交、监控整条链路跑通。重点验证三件事：改密后还能不能正常登录、拿旗脚本能不能扫到本地放的测试 flag、监控脚本能不能发现你手动传的测试文件。演练时故意制造失败——把旧密码改错、把接口地址写错——看脚本的报错信息够不够清楚。报错信息模糊的脚本，赛场上就是黑匣子，出问题你只能干瞪眼。
最后一个习惯：每场比赛结束后，把当场踩的坑和临时改的参数记到一个notes.md里，下次赛前翻一遍。脚本合集的价值不在脚本本身，而在你不断迭代它的过程。我打了这么多场，真正救命的从来不是某个精妙的 exploit，而是开局那十分钟里，别人还在手忙脚乱，你已经把该做的都做完了。希望帮到你。
本文还有配套的精品资源，点击获取
