尧图网页设计 
简介这是一套面向网络安全竞赛选手与攻防爱好者的AWD实战脚本工具包聚焦攻防对抗场景下的信息收集、漏洞利用与系统防护需求。压缩包共34个文件约3.18MB以Python脚本、PHP木马、pyc编译文件、txt说明文档为主另含exe工具、rar压缩包与md说明覆盖攻击与防御两条主线。资源按攻击、防御及补充资料分区组织攻击侧包含信息收集、不死马生成、Webshell上传与GetFlag等脚本防御侧提供WAF、文件监控、日志分析与克制不死马等方案并附命令生成说明与日志地址配置。目前已有688人学习下载适合希望快速搭建攻防演练环境、熟悉常见脚本用法与排错思路的参赛者参考也可作为团队协作与应急响应的练习素材。需注意所有工具应在合法合规前提下使用。1. AWD 攻防赛脚本集合从“手忙脚乱”到“半自动防守”的落地拆解打 AWD 攻防赛最让人血压飙升的不是对手有多强而是你刚把 Web 服务修好对手已经用脚本批量改了你三台机器的 SSH 密码你还在手动ssh一台台看日志隔壁队伍已经用自动化脚本把 flag 提交了三轮。AWD 的本质是“时间窗口内的攻防效率比拼”谁先把重复动作脚本化谁就能腾出手来做真正的漏洞利用和权限维持。这份《AWD攻防赛脚本集合.zip》就是冲着这个痛点来的——它不是某个单一漏洞的 EXP而是一组覆盖“批量连接、服务巡检、flag 提交、权限维持、日志清理”的常用脚本合集适合第一次打 AWD 的新手快速建立防守节奏也适合老手拿来当模板改自己的私有工具链。下面我按“资源是什么 → 怎么用 → 坑在哪”的顺序把包里脚本的典型用法和参数配置拆开讲。2. 脚本集合的组成与运行环境先搞清楚你手里有什么2.1 包内脚本分类与典型文件结构拿到一个脚本集合第一件事不是急着跑而是先看目录结构。AWD 脚本集合通常按功能分目录常见结构如下awd_scripts/ ├── connect/ # 批量 SSH / 批量执行命令 │ ├── batch_ssh.py │ └── hosts.txt ├── check/ # 服务存活与端口巡检 │ ├── port_scan.sh │ └── web_check.py ├── submit/ # flag 自动提交 │ ├── auto_submit.py │ └── config.ini ├── persist/ # 权限维持与后门清理 │ ├── ssh_key_push.sh │ └── cron_backdoor.sh └── clean/ # 日志清理与痕迹处理 └── clear_log.sh这个结构不是固定的但功能划分逻辑基本一致。connect目录解决“怎么同时操作多台机器”check解决“怎么快速发现服务异常”submit解决“怎么在拿到 flag 后第一时间交上去”persist和clean则是攻防对抗中“保权限”和“擦痕迹”的环节。先确认每个脚本的依赖Python 脚本一般需要paramiko、requestsShell 脚本依赖sshpass、nmap、curl。缺依赖直接跑报错会让人误以为是脚本本身有问题。2.2 运行环境准备Python 依赖与 SSH 免密AWD 比赛环境通常是 Linux 靶机但你的攻击机可能是 Windows WSL 或者一台 Linux 跳板。不管哪种先把基础依赖装齐# 更新包列表并安装常用工具 sudo apt update sudo apt install -y python3 python3-pip sshpass nmap curl # 安装 Python 依赖 pip3 install paramiko requests beautifulsoup4paramiko是 Python 里做 SSH 连接最常用的库requests用来提交 flag 或探测 Web 服务beautifulsoup4在需要解析 HTML 拿 flag 时用得上。sshpass则是 Shell 脚本里非交互式 SSH 登录的关键——没有它batch_ssh.sh这类脚本会卡在密码输入提示上。提示如果比赛环境不允许联网装包提前在本地把paramiko和requests的 wheel 包下好用pip3 install --no-index --find-links./wheels paramiko离线安装。接下来配置 SSH 免密这是批量操作的前提。假设你手上有三台靶机IP 分别是192.168.1.10、192.168.1.11、192.168.1.12统一用root登录# 生成密钥对如果已有可跳过 ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/awd_key # 把公钥推到每台靶机 for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do sshpass -p 初始密码 ssh-copy-id -i ~/.ssh/awd_key.pub -o StrictHostKeyCheckingno root$ip done-N 表示密钥不设密码方便脚本自动调用StrictHostKeyCheckingno跳过首次连接的指纹确认否则脚本会卡在yes/no交互上。这一步做完后续所有批量 SSH 操作都不需要再输密码。2.3 批量连接脚本的参数配置与执行batch_ssh.py这类脚本的核心逻辑是读一个主机列表文件对每台机器执行同一串命令然后把输出汇总。典型用法如下# batch_ssh.py 核心片段 import paramiko HOSTS_FILE hosts.txt KEY_FILE /root/.ssh/awd_key CMD cat /flag 2/dev/null; hostname; whoami def run_cmd(host, cmd): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, usernameroot, key_filenameKEY_FILE, timeout5) stdin, stdout, stderr client.exec_command(cmd) out stdout.read().decode() client.close() return out with open(HOSTS_FILE) as f: for line in f: ip line.strip() if not ip: continue try: print(f {ip} ) print(run_cmd(ip, CMD)) except Exception as e: print(f[!] {ip} 连接失败: {e})hosts.txt每行一个 IP不要带多余空格。timeout5是连接超时AWD 环境里靶机可能被对手打挂超时设太长会拖慢整个脚本。AutoAddPolicy()自动接受未知主机密钥省去手动确认。执行时直接python3 batch_ssh.py输出会按机器分组打印。如果某台机器连不上脚本会打印失败信息并继续下一台不会整体中断——这个容错设计在比赛里很关键因为对手可能已经把你某台机器搞下线了。3. 服务巡检与 flag 自动提交把重复动作交给脚本3.1 端口与服务存活巡检脚本AWD 比赛中你的服务可能被对手kill掉也可能被植入 WebShell 后门。巡检脚本要做的就是快速告诉你“哪些端口还活着、哪些页面被改了”。一个典型的 Shell 巡检脚本如下#!/bin/bash # port_scan.sh - 快速巡检常见 AWD 端口 HOSTS192.168.1.10 192.168.1.11 192.168.1.12 PORTS22 80 443 3306 8080 for host in $HOSTS; do echo $host for port in $PORTS; do timeout 2 bash -c echo /dev/tcp/$host/$port 2/dev/null \ echo [] $port open \ || echo [-] $port closed done done/dev/tcp是 Bash 内置的 TCP 连接方式不需要额外装nc或nmap在比赛环境里更轻量。timeout 2控制单次探测不超过 2 秒避免某个端口卡住导致整个巡检变慢。输出里[]表示端口开放[-]表示关闭或被防火墙拦截。如果发现 80 端口从 open 变成 closed说明 Web 服务挂了需要立刻上去重启。Web 服务巡检可以进一步用curl检查 HTTP 状态码和页面关键字# web_check.sh - 检查 Web 服务是否返回正常页面 for host in $HOSTS; do code$(curl -s -o /dev/null -w %{http_code} --max-time 3 http://$host/) echo $host HTTP_CODE$code # 如果状态码不是 200尝试重启服务 if [ $code ! 200 ]; then ssh -i ~/.ssh/awd_key root$host systemctl restart nginx 2/dev/null || service apache2 restart fi done-o /dev/null丢弃页面内容-w %{http_code}只输出状态码--max-time 3限制请求时间。状态码非 200 时自动尝试重启 Nginx 或 Apache这个“自愈”逻辑在比赛里能省下大量手动操作时间。注意重启命令要兼容systemctl和service两种方式因为不同靶机的初始化系统可能不一样。3.2 flag 自动提交脚本的配置与去重flag 提交是 AWD 里最机械也最不能出错的动作。手动提交容易漏、容易重复、容易在复制粘贴时出错。自动提交脚本的核心是从目标位置读取 flag通过比赛平台接口提交并记录已提交的 flag 防止重复。# auto_submit.py 核心逻辑 import requests import hashlib import time SUBMIT_URL http://比赛平台地址/api/submit TOKEN 你的队伍token FLAG_FILE /flag RECORD_FILE submitted.txt def load_submitted(): try: with open(RECORD_FILE) as f: return set(line.strip() for line in f) except FileNotFoundError: return set() def save_submitted(flag): with open(RECORD_FILE, a) as f: f.write(flag \n) def submit(flag): resp requests.post(SUBMIT_URL, data{flag: flag, token: TOKEN}, timeout5) return resp.status_code 200 submitted load_submitted() while True: try: with open(FLAG_FILE) as f: flag f.read().strip() if flag and flag not in submitted: if submit(flag): print(f[] 提交成功: {flag}) save_submitted(flag) submitted.add(flag) else: print(f[-] 提交失败: {flag}) except FileNotFoundError: pass time.sleep(10)submitted.txt是去重记录每提交成功一个 flag 就追加一行。time.sleep(10)控制轮询间隔太短会给平台接口造成压力太长会错过 flag 刷新窗口。TOKEN和SUBMIT_URL需要根据比赛平台的实际接口替换——不同平台的提交参数名可能不一样常见的是flag和token也有用answer和team_id的。拿到平台接口文档后先手动提交一次用浏览器开发者工具看请求参数再改脚本。注意有些比赛的 flag 是动态刷新的每轮会变。这种情况下脚本要配合“flag 监控”逻辑检测到/flag文件内容变化后立即提交而不是固定间隔轮询。3.3 权限维持与后门清理的脚本化AWD 的攻防是双向的你既要防对手进来也要在拿到对手机器权限后维持住。权限维持脚本通常做两件事推送自己的 SSH 公钥、写定时任务反弹 Shell。#!/bin/bash # ssh_key_push.sh - 向目标机器推送公钥 TARGET$1 KEYssh-rsa AAAAB3Nza... your_key_here sshpass -p 拿到的密码 ssh -o StrictHostKeyCheckingno root$TARGET \ mkdir -p ~/.ssh echo $KEY ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这个脚本把公钥追加到目标机器的authorized_keys之后就能免密登录。chmod 600是必须的否则 SSH 会拒绝使用这个密钥文件。如果对手已经改了密码这个脚本就失效了需要先用漏洞拿到的 Shell 来执行。后门清理则是反向操作检查自己机器上有没有对手留下的异常 SSH 公钥、异常定时任务、异常进程。# check_backdoor.sh - 检查常见后门痕迹 echo authorized_keys cat ~/.ssh/authorized_keys 2/dev/null echo crontab crontab -l 2/dev/null ls -la /etc/cron.d/ /etc/cron.daily/ 2/dev/null echo 异常监听端口 netstat -tlnp 2/dev/null | grep -v 127.0.0.1 echo 异常进程 ps aux | grep -E nc |ncat|socat|python -c | grep -v grepauthorized_keys里如果出现不认识的公钥直接删掉。crontab和/etc/cron.d/里如果有奇怪的定时任务比如每隔几分钟反弹一次 Shell也要清理。netstat看有没有非业务端口在监听ps aux看有没有nc、socat这类常见反弹工具在跑。这个脚本建议每轮比赛间隙跑一次养成习惯。4. 避坑与常见问题脚本跑不起来先看这几条4.1 SSH 连接超时或拒绝现象batch_ssh.py对某台机器一直报TimeoutError或Connection refused。原因靶机 SSH 服务被对手打挂或者防火墙规则被改22 端口不通。也可能是你自己之前改了 SSH 配置导致服务没重启。解决先用port_scan.sh确认 22 端口状态。如果端口 closed通过比赛平台的 VNC 或控制台进去重启 SSHsystemctl restart sshd。如果端口 open 但连接被拒检查/etc/hosts.deny和iptables -L有没有被加规则。4.2 flag 提交返回 403 或 token 无效现象auto_submit.py打印[-] 提交失败HTTP 状态码 403。原因token 过期、提交频率过高被平台限流、或者 flag 格式不对比如多了换行符或空格。解决先手动提交一次确认 token 有效。检查flag.strip()是否去掉了所有空白字符。如果平台有限流把time.sleep(10)改成 30 秒。有些平台要求 flag 带特定前缀确认读取到的 flag 是否完整。4.3 批量脚本把正常服务误杀现象巡检脚本执行后原本正常的 Web 服务反而挂了。原因重启命令写得太粗暴比如killall nginx之后没有正确启动或者systemctl restart在服务本身有依赖问题时失败。解决重启前先nginx -t检查配置语法确认无误再 restart。更稳妥的做法是先用curl确认服务确实不可用再执行重启避免“误判导致误杀”。可以在脚本里加一层判断只有连续两次检测到非 200 才触发重启。4.4 日志清理脚本把关键证据也删了现象跑完clear_log.sh后自己排查问题时找不到任何日志。原因清理脚本直接rm -rf /var/log/*把系统日志和业务日志一起清了。解决清理要有选择性只清包含自己操作痕迹的日志行比如sed -i /你的IP/d /var/log/auth.log而不是整个删除。比赛里保留日志对复盘和申诉都有用别图省事全删。4.5 Python 脚本在靶机上跑报缺少模块现象把auto_submit.py传到靶机上执行报ModuleNotFoundError: No module named requests。原因靶机环境精简没有装 Python 第三方库且可能无法联网安装。解决提交脚本尽量放在自己的攻击机上跑通过 SSH 读取靶机上的 flag 文件而不是把脚本传到靶机。如果必须在靶机跑提前用pip3 download把依赖包下好一起传过去离线安装。5. 进阶技巧把脚本串成一条“防守流水线”单个脚本用起来是散的真正提效的是把它们串成一条定时执行的流水线。我一般会写一个watchdog.sh每 30 秒跑一轮巡检 提交 后门检查用cron或while循环驱动#!/bin/bash # watchdog.sh - AWD 防守流水线 while true; do echo $(date) bash port_scan.sh bash web_check.sh python3 auto_submit.py --once bash check_backdoor.sh sleep 30 doneauto_submit.py --once表示只跑一轮提交就退出而不是无限循环这样流水线不会卡在提交环节。sleep 30是整条流水线的节奏比赛前期可以调到 10 秒后期稳定后调到 60 秒减少负载。另一个实用技巧是给脚本加“变更检测”用md5sum记录关键文件的哈希下一轮对比发现变化就告警。# 记录 Web 目录哈希 find /var/www/html -type f -exec md5sum {} \; /tmp/web_hash_now.txt # 与上一轮对比 if [ -f /tmp/web_hash_last.txt ]; then diff /tmp/web_hash_last.txt /tmp/web_hash_now.txt echo 无变化 || echo [!] Web 目录被改动 fi mv /tmp/web_hash_now.txt /tmp/web_hash_last.txt这个逻辑能帮你第一时间发现对手有没有在你的 Web 目录里留 WebShell。diff有输出就说明文件被增删改需要立刻人工确认。参数配置上hosts.txt和config.ini这类文件建议用版本管理工具管起来每轮比赛前确认 IP 列表和 token 是最新的。我吃过亏——有一次比赛换了靶机网段脚本还在打上一轮的 IP白白浪费了十分钟。从那以后我每次开赛前都强制走一遍“改配置 → 单机测试 → 批量执行”的流程确认第一台机器返回正常后再放开跑。希望帮到你。本文还有配套的精品资源点击获取 AWD攻防赛脚本集合：批量SSH、flag自动提交与防守流水线实战
简介这是一套面向网络安全竞赛选手与攻防爱好者的AWD实战脚本工具包聚焦攻防对抗场景下的信息收集、漏洞利用与系统防护需求。压缩包共34个文件约3.18MB以Python脚本、PHP木马、pyc编译文件、txt说明文档为主另含exe工具、rar压缩包与md说明覆盖攻击与防御两条主线。资源按攻击、防御及补充资料分区组织攻击侧包含信息收集、不死马生成、Webshell上传与GetFlag等脚本防御侧提供WAF、文件监控、日志分析与克制不死马等方案并附命令生成说明与日志地址配置。目前已有688人学习下载适合希望快速搭建攻防演练环境、熟悉常见脚本用法与排错思路的参赛者参考也可作为团队协作与应急响应的练习素材。需注意所有工具应在合法合规前提下使用。1. AWD 攻防赛脚本集合从“手忙脚乱”到“半自动防守”的落地拆解打 AWD 攻防赛最让人血压飙升的不是对手有多强而是你刚把 Web 服务修好对手已经用脚本批量改了你三台机器的 SSH 密码你还在手动ssh一台台看日志隔壁队伍已经用自动化脚本把 flag 提交了三轮。AWD 的本质是“时间窗口内的攻防效率比拼”谁先把重复动作脚本化谁就能腾出手来做真正的漏洞利用和权限维持。这份《AWD攻防赛脚本集合.zip》就是冲着这个痛点来的——它不是某个单一漏洞的 EXP而是一组覆盖“批量连接、服务巡检、flag 提交、权限维持、日志清理”的常用脚本合集适合第一次打 AWD 的新手快速建立防守节奏也适合老手拿来当模板改自己的私有工具链。下面我按“资源是什么 → 怎么用 → 坑在哪”的顺序把包里脚本的典型用法和参数配置拆开讲。2. 脚本集合的组成与运行环境先搞清楚你手里有什么2.1 包内脚本分类与典型文件结构拿到一个脚本集合第一件事不是急着跑而是先看目录结构。AWD 脚本集合通常按功能分目录常见结构如下awd_scripts/ ├── connect/ # 批量 SSH / 批量执行命令 │ ├── batch_ssh.py │ └── hosts.txt ├── check/ # 服务存活与端口巡检 │ ├── port_scan.sh │ └── web_check.py ├── submit/ # flag 自动提交 │ ├── auto_submit.py │ └── config.ini ├── persist/ # 权限维持与后门清理 │ ├── ssh_key_push.sh │ └── cron_backdoor.sh └── clean/ # 日志清理与痕迹处理 └── clear_log.sh这个结构不是固定的但功能划分逻辑基本一致。connect目录解决“怎么同时操作多台机器”check解决“怎么快速发现服务异常”submit解决“怎么在拿到 flag 后第一时间交上去”persist和clean则是攻防对抗中“保权限”和“擦痕迹”的环节。先确认每个脚本的依赖Python 脚本一般需要paramiko、requestsShell 脚本依赖sshpass、nmap、curl。缺依赖直接跑报错会让人误以为是脚本本身有问题。2.2 运行环境准备Python 依赖与 SSH 免密AWD 比赛环境通常是 Linux 靶机但你的攻击机可能是 Windows WSL 或者一台 Linux 跳板。不管哪种先把基础依赖装齐# 更新包列表并安装常用工具 sudo apt update sudo apt install -y python3 python3-pip sshpass nmap curl # 安装 Python 依赖 pip3 install paramiko requests beautifulsoup4paramiko是 Python 里做 SSH 连接最常用的库requests用来提交 flag 或探测 Web 服务beautifulsoup4在需要解析 HTML 拿 flag 时用得上。sshpass则是 Shell 脚本里非交互式 SSH 登录的关键——没有它batch_ssh.sh这类脚本会卡在密码输入提示上。提示如果比赛环境不允许联网装包提前在本地把paramiko和requests的 wheel 包下好用pip3 install --no-index --find-links./wheels paramiko离线安装。接下来配置 SSH 免密这是批量操作的前提。假设你手上有三台靶机IP 分别是192.168.1.10、192.168.1.11、192.168.1.12统一用root登录# 生成密钥对如果已有可跳过 ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/awd_key # 把公钥推到每台靶机 for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do sshpass -p 初始密码 ssh-copy-id -i ~/.ssh/awd_key.pub -o StrictHostKeyCheckingno root$ip done-N 表示密钥不设密码方便脚本自动调用StrictHostKeyCheckingno跳过首次连接的指纹确认否则脚本会卡在yes/no交互上。这一步做完后续所有批量 SSH 操作都不需要再输密码。2.3 批量连接脚本的参数配置与执行batch_ssh.py这类脚本的核心逻辑是读一个主机列表文件对每台机器执行同一串命令然后把输出汇总。典型用法如下# batch_ssh.py 核心片段 import paramiko HOSTS_FILE hosts.txt KEY_FILE /root/.ssh/awd_key CMD cat /flag 2/dev/null; hostname; whoami def run_cmd(host, cmd): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, usernameroot, key_filenameKEY_FILE, timeout5) stdin, stdout, stderr client.exec_command(cmd) out stdout.read().decode() client.close() return out with open(HOSTS_FILE) as f: for line in f: ip line.strip() if not ip: continue try: print(f {ip} ) print(run_cmd(ip, CMD)) except Exception as e: print(f[!] {ip} 连接失败: {e})hosts.txt每行一个 IP不要带多余空格。timeout5是连接超时AWD 环境里靶机可能被对手打挂超时设太长会拖慢整个脚本。AutoAddPolicy()自动接受未知主机密钥省去手动确认。执行时直接python3 batch_ssh.py输出会按机器分组打印。如果某台机器连不上脚本会打印失败信息并继续下一台不会整体中断——这个容错设计在比赛里很关键因为对手可能已经把你某台机器搞下线了。3. 服务巡检与 flag 自动提交把重复动作交给脚本3.1 端口与服务存活巡检脚本AWD 比赛中你的服务可能被对手kill掉也可能被植入 WebShell 后门。巡检脚本要做的就是快速告诉你“哪些端口还活着、哪些页面被改了”。一个典型的 Shell 巡检脚本如下#!/bin/bash # port_scan.sh - 快速巡检常见 AWD 端口 HOSTS192.168.1.10 192.168.1.11 192.168.1.12 PORTS22 80 443 3306 8080 for host in $HOSTS; do echo $host for port in $PORTS; do timeout 2 bash -c echo /dev/tcp/$host/$port 2/dev/null \ echo [] $port open \ || echo [-] $port closed done done/dev/tcp是 Bash 内置的 TCP 连接方式不需要额外装nc或nmap在比赛环境里更轻量。timeout 2控制单次探测不超过 2 秒避免某个端口卡住导致整个巡检变慢。输出里[]表示端口开放[-]表示关闭或被防火墙拦截。如果发现 80 端口从 open 变成 closed说明 Web 服务挂了需要立刻上去重启。Web 服务巡检可以进一步用curl检查 HTTP 状态码和页面关键字# web_check.sh - 检查 Web 服务是否返回正常页面 for host in $HOSTS; do code$(curl -s -o /dev/null -w %{http_code} --max-time 3 http://$host/) echo $host HTTP_CODE$code # 如果状态码不是 200尝试重启服务 if [ $code ! 200 ]; then ssh -i ~/.ssh/awd_key root$host systemctl restart nginx 2/dev/null || service apache2 restart fi done-o /dev/null丢弃页面内容-w %{http_code}只输出状态码--max-time 3限制请求时间。状态码非 200 时自动尝试重启 Nginx 或 Apache这个“自愈”逻辑在比赛里能省下大量手动操作时间。注意重启命令要兼容systemctl和service两种方式因为不同靶机的初始化系统可能不一样。3.2 flag 自动提交脚本的配置与去重flag 提交是 AWD 里最机械也最不能出错的动作。手动提交容易漏、容易重复、容易在复制粘贴时出错。自动提交脚本的核心是从目标位置读取 flag通过比赛平台接口提交并记录已提交的 flag 防止重复。# auto_submit.py 核心逻辑 import requests import hashlib import time SUBMIT_URL http://比赛平台地址/api/submit TOKEN 你的队伍token FLAG_FILE /flag RECORD_FILE submitted.txt def load_submitted(): try: with open(RECORD_FILE) as f: return set(line.strip() for line in f) except FileNotFoundError: return set() def save_submitted(flag): with open(RECORD_FILE, a) as f: f.write(flag \n) def submit(flag): resp requests.post(SUBMIT_URL, data{flag: flag, token: TOKEN}, timeout5) return resp.status_code 200 submitted load_submitted() while True: try: with open(FLAG_FILE) as f: flag f.read().strip() if flag and flag not in submitted: if submit(flag): print(f[] 提交成功: {flag}) save_submitted(flag) submitted.add(flag) else: print(f[-] 提交失败: {flag}) except FileNotFoundError: pass time.sleep(10)submitted.txt是去重记录每提交成功一个 flag 就追加一行。time.sleep(10)控制轮询间隔太短会给平台接口造成压力太长会错过 flag 刷新窗口。TOKEN和SUBMIT_URL需要根据比赛平台的实际接口替换——不同平台的提交参数名可能不一样常见的是flag和token也有用answer和team_id的。拿到平台接口文档后先手动提交一次用浏览器开发者工具看请求参数再改脚本。注意有些比赛的 flag 是动态刷新的每轮会变。这种情况下脚本要配合“flag 监控”逻辑检测到/flag文件内容变化后立即提交而不是固定间隔轮询。3.3 权限维持与后门清理的脚本化AWD 的攻防是双向的你既要防对手进来也要在拿到对手机器权限后维持住。权限维持脚本通常做两件事推送自己的 SSH 公钥、写定时任务反弹 Shell。#!/bin/bash # ssh_key_push.sh - 向目标机器推送公钥 TARGET$1 KEYssh-rsa AAAAB3Nza... your_key_here sshpass -p 拿到的密码 ssh -o StrictHostKeyCheckingno root$TARGET \ mkdir -p ~/.ssh echo $KEY ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这个脚本把公钥追加到目标机器的authorized_keys之后就能免密登录。chmod 600是必须的否则 SSH 会拒绝使用这个密钥文件。如果对手已经改了密码这个脚本就失效了需要先用漏洞拿到的 Shell 来执行。后门清理则是反向操作检查自己机器上有没有对手留下的异常 SSH 公钥、异常定时任务、异常进程。# check_backdoor.sh - 检查常见后门痕迹 echo authorized_keys cat ~/.ssh/authorized_keys 2/dev/null echo crontab crontab -l 2/dev/null ls -la /etc/cron.d/ /etc/cron.daily/ 2/dev/null echo 异常监听端口 netstat -tlnp 2/dev/null | grep -v 127.0.0.1 echo 异常进程 ps aux | grep -E nc |ncat|socat|python -c | grep -v grepauthorized_keys里如果出现不认识的公钥直接删掉。crontab和/etc/cron.d/里如果有奇怪的定时任务比如每隔几分钟反弹一次 Shell也要清理。netstat看有没有非业务端口在监听ps aux看有没有nc、socat这类常见反弹工具在跑。这个脚本建议每轮比赛间隙跑一次养成习惯。4. 避坑与常见问题脚本跑不起来先看这几条4.1 SSH 连接超时或拒绝现象batch_ssh.py对某台机器一直报TimeoutError或Connection refused。原因靶机 SSH 服务被对手打挂或者防火墙规则被改22 端口不通。也可能是你自己之前改了 SSH 配置导致服务没重启。解决先用port_scan.sh确认 22 端口状态。如果端口 closed通过比赛平台的 VNC 或控制台进去重启 SSHsystemctl restart sshd。如果端口 open 但连接被拒检查/etc/hosts.deny和iptables -L有没有被加规则。4.2 flag 提交返回 403 或 token 无效现象auto_submit.py打印[-] 提交失败HTTP 状态码 403。原因token 过期、提交频率过高被平台限流、或者 flag 格式不对比如多了换行符或空格。解决先手动提交一次确认 token 有效。检查flag.strip()是否去掉了所有空白字符。如果平台有限流把time.sleep(10)改成 30 秒。有些平台要求 flag 带特定前缀确认读取到的 flag 是否完整。4.3 批量脚本把正常服务误杀现象巡检脚本执行后原本正常的 Web 服务反而挂了。原因重启命令写得太粗暴比如killall nginx之后没有正确启动或者systemctl restart在服务本身有依赖问题时失败。解决重启前先nginx -t检查配置语法确认无误再 restart。更稳妥的做法是先用curl确认服务确实不可用再执行重启避免“误判导致误杀”。可以在脚本里加一层判断只有连续两次检测到非 200 才触发重启。4.4 日志清理脚本把关键证据也删了现象跑完clear_log.sh后自己排查问题时找不到任何日志。原因清理脚本直接rm -rf /var/log/*把系统日志和业务日志一起清了。解决清理要有选择性只清包含自己操作痕迹的日志行比如sed -i /你的IP/d /var/log/auth.log而不是整个删除。比赛里保留日志对复盘和申诉都有用别图省事全删。4.5 Python 脚本在靶机上跑报缺少模块现象把auto_submit.py传到靶机上执行报ModuleNotFoundError: No module named requests。原因靶机环境精简没有装 Python 第三方库且可能无法联网安装。解决提交脚本尽量放在自己的攻击机上跑通过 SSH 读取靶机上的 flag 文件而不是把脚本传到靶机。如果必须在靶机跑提前用pip3 download把依赖包下好一起传过去离线安装。5. 进阶技巧把脚本串成一条“防守流水线”单个脚本用起来是散的真正提效的是把它们串成一条定时执行的流水线。我一般会写一个watchdog.sh每 30 秒跑一轮巡检 提交 后门检查用cron或while循环驱动#!/bin/bash # watchdog.sh - AWD 防守流水线 while true; do echo $(date) bash port_scan.sh bash web_check.sh python3 auto_submit.py --once bash check_backdoor.sh sleep 30 doneauto_submit.py --once表示只跑一轮提交就退出而不是无限循环这样流水线不会卡在提交环节。sleep 30是整条流水线的节奏比赛前期可以调到 10 秒后期稳定后调到 60 秒减少负载。另一个实用技巧是给脚本加“变更检测”用md5sum记录关键文件的哈希下一轮对比发现变化就告警。# 记录 Web 目录哈希 find /var/www/html -type f -exec md5sum {} \; /tmp/web_hash_now.txt # 与上一轮对比 if [ -f /tmp/web_hash_last.txt ]; then diff /tmp/web_hash_last.txt /tmp/web_hash_now.txt echo 无变化 || echo [!] Web 目录被改动 fi mv /tmp/web_hash_now.txt /tmp/web_hash_last.txt这个逻辑能帮你第一时间发现对手有没有在你的 Web 目录里留 WebShell。diff有输出就说明文件被增删改需要立刻人工确认。参数配置上hosts.txt和config.ini这类文件建议用版本管理工具管起来每轮比赛前确认 IP 列表和 token 是最新的。我吃过亏——有一次比赛换了靶机网段脚本还在打上一轮的 IP白白浪费了十分钟。从那以后我每次开赛前都强制走一遍“改配置 → 单机测试 → 批量执行”的流程确认第一台机器返回正常后再放开跑。希望帮到你。本文还有配套的精品资源点击获取