简介CTF线下AWD脚本合集是一份面向网络攻防竞赛选手的实战工具包尤其适合刚接触AWD模式、不熟悉自编脚本的新手也便于有经验的选手优化攻防流程。AWD要求参赛队伍在攻击对手系统的同时保护自身服务对脚本化、自动化能力要求较高该合集正是为节省编写与调试时间而整理。压缩包共34个文件约3.18MB以Python脚本、PHP木马与Webshell、txt说明文档为主另含pyc编译文件、md说明及少量rar、exe工具覆盖扫描探测、自动化攻击、不死马与WAF防御、日志分析、Flag获取等环节目录结构清晰便于按攻防阶段快速取用。目前已有3010人学习下载可作为赛前熟悉攻防逻辑、积累常用脚本与排错思路的参考使用时请遵守法律法规仅限合法CTF比赛环境。1. 从一份 AWD 脚本合集说起线下攻防到底在拼什么打过线下 AWDAttack 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_PASSctf NEW_PASSAwd2025_$(date %s) for host in ${HOSTS[]}; do sshpass -p $OLD_PASS ssh -o StrictHostKeyCheckingno root$host \ echo -e ${NEW_PASS}\n${NEW_PASS} | passwd root \ echo [] $host 改密成功: $NEW_PASS \ || echo [-] $host 改密失败检查网络或旧密码 done逻辑说明StrictHostKeyCheckingno跳过首次连接的指纹确认避免脚本卡在交互提示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, shellTrue, stderrsubprocess.DEVNULL).decode(errorsignore) except Exception: return seen set() for path in CANDIDATES: content run(fcat {path} 2/dev/null) # 匹配常见 flag 格式 flag{...} 或 32 位十六进制 for m in re.findall(rflag\{[^}]\}|[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}, timeout5) print(f[{resp.status_code}] {f} - {resp.text}) time.sleep(1.5) # 间隔 1.5 秒避开限流逻辑说明timeout5防止接口卡死拖垮整个脚本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逻辑说明第一条统计请求量最高的 IPAWD 里对手的扫描器往往请求量异常大第二条捞出带攻击特征的请求方便你定位攻击手法。参数上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而是开局那十分钟里别人还在手忙脚乱你已经把该做的都做完了。希望帮到你。本文还有配套的精品资源点击获取