Python渗透测试脚本合集整理指南：环境隔离与脚本改造

简介：这是一份面向安全初学者与渗透测试从业者的Python实战脚本合集，围绕Python 3.9与Kali环境编写，强调用编程替代工具依赖，既可用于实战演练，也可作为Python安全编程的学习范例。资源共64个文件，以45个py脚本为主，辅以txt说明、passwords、username、result等字典与结果文件，压缩包约3.02MB，结构按功能模块划分清晰。内容覆盖干扰测试中的POC与EXP脚本、被动与主动信息搜集（DNS解析、域名与邮件爬取、ICMP/TCP/UDP/ARP主机发现、端口与服务识别、敏感目录探测）、未授权访问与SQL盲注检测、SQLMap Tamper脚本编写、XXE与SSRF检测、Base64/AES/DES/MD5加解密、弱口令生成与爆破、DDOS与嗅探等方向。已有166人学习，适合希望从脚本层面理解渗透流程、积累可复用代码与排错思路的读者参考。

1. 拿到一个 Python 渗透测试脚本工具合集，先别急着双击运行

很多人第一次拿到「Python渗透测试脚本,工具合集.zip」这类压缩包，第一反应是解压、找入口、双击运行，然后被一堆ModuleNotFoundError、SyntaxError和杀软弹窗劝退。我见过太多人卡在这一步，最后把包丢进回收站，转头去搜「python安装教程」重新开始。其实问题不在你，而在这个包本身——它大概率是某个从业者多年攒下来的脚本碎片，目录结构混乱、依赖版本打架、Python 2 和 3 混着写，甚至有些脚本是半成品。你要做的不是「运行它」，而是「把它当成一个待整理的知识库」，先分类、再隔离、最后逐个跑通。这篇笔记就是讲我怎么把这类合集拆成能用的东西：哪些脚本值得留、依赖怎么锁、在什么环境里跑、跑不通时看哪里。适合手里已经有一个类似压缩包、想把它变成自己工具箱的人，也适合刚学渗透测试、想通过读别人脚本快速入门的新手。

2. 先给合集做一次「体检」：目录分类与脚本筛选

2.1 用三条命令摸清压缩包的家底

拿到包之后，不要用图形界面解压完就开跑。我一般先在 Linux 虚拟机里操作，因为大部分渗透脚本对 Windows 的兼容性很差，尤其是涉及 socket、raw packet、subprocess 调 shell 的那些。先解压到一个隔离目录，然后跑三条命令看结构。

# 解压到独立目录，避免污染当前工作区 mkdir -p ~/tools/pt_collection && cd ~/tools/pt_collection unzip ~/Downloads/Python渗透测试脚本,工具合集.zip -d . # 第一条：看目录树，只展开两层，避免输出爆炸 find . -maxdepth 2 -type d | sort # 第二条：统计文件类型分布，心里有数 find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20 # 第三条：找出所有 Python 文件，并标记 Python 2 特征 grep -rl "print " --include="*.py" . | head -20 grep -rl "raw_input\|urllib2\|except Exception, e" --include="*.py" .

这三条命令分别解决三个问题：目录结构是否按功能分（比如scanner/、exploit/、crawler/），文件类型是否以.py为主还是混了大量.exe、.jar，以及有多少脚本是 Python 2 写的。第三条里print带空格、raw_input、urllib2、except Exception, e都是 Python 2 的典型特征，命中越多，说明这个包越老，后面要花的迁移时间越长。

参数说明：-maxdepth 2控制目录展开深度，太深会刷屏，太浅看不到子模块；sed 's/.*\.//'提取扩展名，注意没有扩展名的文件会被算成整行，可以再加grep '\.'过滤；grep -rl的-l只输出文件名，方便后续批量处理。

2.2 按「能不能独立跑」给脚本分三档

体检完你会得到一堆.py文件，但它们的质量参差不齐。我习惯按依赖复杂度分三档，这个分类直接决定后面怎么处理。

分档不是靠猜，用一条命令就能把 import 情况拉出来：

# 提取所有 py 文件的 import 语句，统计第三方库出现频率 grep -rh "^import \|^from " --include="*.py" . | \ sed 's/^from \([a-zA-Z0-9_]*\).*/\1/; s/^import \([a-zA-Z0-9_]*\).*/\1/' | \ sort | uniq -c | sort -rn | head -30

这条命令的输出就是你的「依赖热度榜」。排在前面的requests、socket、os、sys是标准库或常见库，不用慌；如果出现scapy、impacket、pwntools、paramiko，说明这个包里有偏底层的脚本，需要单独准备环境。注意sed那段的写法只提取第一个模块名，from a.b import c会被归到a，够用了，不用追求完美解析。

提示：不要在这个阶段就pip install -r requirements.txt。很多合集的 requirements 是作者随手pip freeze出来的，里面混了几百个无关包，直接装会把你的环境搞乱。正确做法是逐个脚本看 import，按需装。

2.3 把 C 档脚本当「阅读材料」而不是「运行目标」

C 档脚本里其实藏着最有价值的东西——作者的思路。我遇到过很多写死路径、缺模块的脚本，但里面的 payload 构造、请求头伪造、编码绕过逻辑写得很巧。这类脚本不要急着修，先读。读的时候重点看三处：请求怎么发的、payload 怎么拼的、结果怎么判断的。把这三段摘出来，改写成自己能用的函数，比修一个跑不起来的脚本划算得多。

比如一个跑不起来的 SQL 注入探测脚本，核心可能就这几行：

# 从 C 档脚本里摘出来的核心逻辑，重写成可复用函数 import requests def check_boolean_injection(url, param): """基于布尔盲注的简单探测：比较真/假条件的响应长度差异""" true_payload = f"{param}=1' AND '1'='1" false_payload = f"{param}=1' AND '1'='2" try: r_true = requests.get(f"{url}?{true_payload}", timeout=5) r_false = requests.get(f"{url}?{false_payload}", timeout=5) # 长度差异超过阈值，认为存在布尔盲注特征 diff = abs(len(r_true.text) - len(r_false.text)) return diff > 50, diff except requests.RequestException as e: return False, str(e)

这段代码的价值不在「能跑」，而在它示范了布尔盲注的判定思路：构造真条件和假条件，比较响应差异。参数timeout=5是必须的，渗透脚本最怕卡死；阈值50是经验值，实际用的时候要根据目标页面大小调整，页面本身波动大的话这个阈值要往上提。把这类逻辑抽出来，你就有了自己的探测函数库，比攒一堆跑不起来的脚本有用。

3. 环境隔离：为什么我坚持一个脚本一个 venv

3.1 全局装依赖是翻车的开始

新手最容易犯的错，是在系统 Python 里pip install一切。渗透脚本依赖的库版本冲突极其常见：scapy新版改了 API，老脚本跑不了；requests某些版本对 SSL 校验的行为不一样；impacket不同版本模块路径都变过。你在全局环境里装 A 脚本的依赖，可能就把 B 脚本搞挂了。血泪经验：我早期图省事全局装，结果一个pycryptodome的版本冲突让我排查了一下午，最后发现是两个脚本要的版本差了一个大版本。

正确做法是每个 B 档脚本（或每组功能相近的脚本）建一个独立 venv。命令不复杂，但要养成习惯：

# 为单个脚本建独立环境，Python 版本按脚本需要选 cd ~/tools/pt_collection/scanner python3 -m venv .venv source .venv/bin/activate # 先只装脚本明确 import 的库，不装 requirements.txt pip install requests beautifulsoup4 # 跑通后，把实际用到的版本冻结下来 pip freeze > requirements.lock.txt # 退出环境 deactivate

关键点在「先只装明确 import 的库」。很多脚本的requirements.txt是作者全量导出的，里面几十个包你根本用不到。手动装三五个，跑一遍，报缺什么补什么，最后pip freeze出来的requirements.lock.txt才是这个脚本真正的最小依赖集。lock这个命名是故意的，提醒自己这是锁定版本，换机器复现时用它而不是原始 requirements。

参数说明：python3 -m venv .venv里的.venv是目录名，放在脚本同级目录方便识别；source .venv/bin/activate是 Linux/macOS 写法，Windows 下是.venv\Scripts\activate；pip freeze输出的是包名==版本格式，适合复现。

3.2 Python 2 脚本怎么办：能迁则迁，不能迁就容器化

体检阶段标记出来的 Python 2 脚本，处理方式分两种。逻辑简单、行数少的，直接手动迁到 Python 3，主要改这几处：print加括号、raw_input换input、urllib2换urllib.request、except Exception, e换except Exception as e、字典的iteritems()换items()。用2to3工具能自动改一部分，但别全信它，改完必须人工过一遍。

# 用 2to3 自动转换，先备份原文件 cp old_script.py old_script.py.bak 2to3 -w old_script.py # 转换后重点检查这几类问题 grep -n "print \|raw_input\|urllib2\|iteritems\|has_key" old_script.py

2to3 -w会直接改原文件，所以先cp备份。转换后grep那行是查漏，has_key这种老写法 2to3 有时处理不干净，要手动换成in。如果脚本依赖的库本身就没有 Python 3 版本（比如某些老旧的mechanize分支），别硬迁，用 Docker 跑一个 Python 2.7 镜像，把脚本封进去，用完即弃。

# 用 python:2.7-slim 跑老脚本，挂载当前目录 docker run --rm -it -v $(pwd):/work -w /work python:2.7-slim \ bash -c "pip install -r requirements.txt && python old_script.py"

--rm用完删容器，不留垃圾；-v $(pwd):/work把当前目录挂进去，脚本读写都在宿主机可见；-w /work设工作目录。这种方式适合一次性任务，不适合长期维护，但比在宿主机装 Python 2.7 干净得多。

3.3 用目录约定管理多个环境，避免「我到底在哪个 venv 里」

脚本一多，最容易出的玄学问题是：你以为在 A 环境里，其实终端还激活着 B 环境，跑出来的结果对不上。我的做法是给每个环境配一个激活脚本，并在提示符里显示当前环境名。

# 在 ~/.bashrc 里加一段，激活 venv 时提示符显示环境名 venv_activate() { source "$1/bin/activate" export PS1="(venv:$(basename $(dirname $1))) $PS1" }

这样每次venv_activate .venv之后，提示符前面会带上目录名，一眼就知道自己在哪个环境。别小看这个，排查「为什么昨天能跑今天不行」的时候，十次有三次是环境搞错了。另外，跑脚本前养成which python和pip list | grep 关键库的习惯，确认路径和版本，比事后 debug 省时间。

4. 逐个跑通：从端口扫描到请求构造的实操路径

4.1 先跑 A 档脚本建立信心，再碰 B 档

A 档脚本依赖少，适合用来验证环境没问题。典型的是端口扫描和目录爆破。跑之前先读一遍代码，确认它扫的是你授权的目标，别拿公网 IP 乱扫。我一般用本地起的靶机或者scanme.nmap.org这类明确允许扫描的地址做验证。

# 一个典型的 A 档端口扫描脚本核心逻辑，用 socket 实现 import socket import concurrent.futures def scan_port(host, port, timeout=1): """尝试连接指定端口，返回 (port, is_open)""" try: with socket.create_connection((host, port), timeout=timeout) as sock: return port, True except (socket.timeout, ConnectionRefusedError, OSError): return port, False def scan_range(host, ports, workers=100): """并发扫描端口范围，workers 控制并发数""" results = [] with concurrent.futures.ThreadPoolExecutor(max_workers=workers) as executor: futures = [executor.submit(scan_port, host, p) for p in ports] for future in concurrent.futures.as_completed(futures): port, is_open = future.result() if is_open: results.append(port) return sorted(results) if __name__ == "__main__": open_ports = scan_range("127.0.0.1", range(1, 1025)) print(f"开放端口: {open_ports}")

这段代码的关键参数是timeout和workers。timeout=1秒是内网扫描的常用值，扫公网要适当加大，但太大会拖慢整体速度；workers=100是并发线程数，太高会被目标限流或触发防护，内网可以到 200，公网建议 50 以下。socket.create_connection比裸socket.connect好在它会自动处理 DNS 解析和超时，异常捕获里ConnectionRefusedError和OSError要分开考虑，前者是端口关闭，后者可能是网络不可达，排查时含义不同。

跑通 A 档之后，你对这个合集的质量就有判断了。如果连 A 档都跑不起来，大概率是 Python 版本或基础库问题，先解决环境再往下走。

4.2 B 档脚本的依赖锁定与版本回退

B 档脚本是合集的主体，也是最容易出问题的地方。以scapy为例，它不同版本对网卡权限、Python 版本的要求都不一样。我的流程是：先看脚本 import 了什么，查这个库的当前稳定版，装上去跑，报错就降版本。

# 以 scapy 为例，先装最新稳定版试跑 pip install scapy python arp_scan.py # 如果报 API 相关错误，查脚本里用的方法在哪个版本存在 pip index versions scapy # 回退到指定版本 pip install scapy==2.5.0

pip index versions能列出所有可用版本，比去 PyPI 网页翻快。回退版本时注意，有些库的新版本改了模块路径（比如scapy.all里的某些类被移走），光降版本不够，还要改 import。这种情况我一般先看脚本的注释或 README 里有没有写「基于 scapy x.x 开发」，有就按那个版本装，没有就试最近的两三个大版本。

注意：涉及 raw socket 的脚本（scapy、socket 的SOCK_RAW）需要 root 权限，Linux 下用sudo跑，但sudo会切换 Python 环境，导致 venv 失效。解决办法是用sudo .venv/bin/python script.py指定解释器路径，而不是sudo python script.py。

4.3 请求构造类脚本的参数化改造

合集里大量脚本是「请求构造 + 结果判断」的模式，比如目录爆破、参数 fuzz、简单的注入探测。这类脚本原版往往把目标 URL、字典路径、并发数写死在代码里，直接跑不灵活。我的做法是统一改成命令行参数，用argparse包一层，改完就能复用。

# 把写死目标的脚本改造成命令行工具 import argparse import requests from concurrent.futures import ThreadPoolExecutor def check_path(base_url, path, timeout=5): """请求拼接后的 URL，根据状态码判断路径是否存在""" url = f"{base_url.rstrip('/')}/{path.lstrip('/')}" try: r = requests.get(url, timeout=timeout, allow_redirects=False) # 200/301/302/403 都可能表示路径存在，按需调整 return url, r.status_code, len(r.content) except requests.RequestException: return url, None, 0 def main(): parser = argparse.ArgumentParser(description="目录爆破脚本") parser.add_argument("-u", "--url", required=True, help="目标基础 URL") parser.add_argument("-w", "--wordlist", required=True, help="字典文件路径") parser.add_argument("-t", "--threads", type=int, default=20, help="并发线程数") parser.add_argument("--timeout", type=int, default=5, help="单请求超时秒数") args = parser.parse_args() with open(args.wordlist, encoding="utf-8", errors="ignore") as f: paths = [line.strip() for line in f if line.strip()] with ThreadPoolExecutor(max_workers=args.threads) as executor: for url, code, size in executor.map( lambda p: check_path(args.url, p, args.timeout), paths ): if code and code != 404: print(f"[{code}] {url} ({size} bytes)") if __name__ == "__main__": main()

改造的核心是argparse那几行，把 URL、字典、线程数、超时都变成参数。check_path里allow_redirects=False是故意的，爆破时 302 跳转往往意味着路径存在但需要认证，跟着跳转反而看不到真实状态。状态码判断里404排除，但403要保留，它表示路径存在但禁止访问，对渗透来说是有价值的信息。errors="ignore"处理字典文件里的编码问题，实战中字典来源杂，不加这个容易崩。

参数说明：-t默认 20 是保守值，内网可以调到 50；--timeout默认 5 秒，目标响应慢就加大，但会拖慢整体；executor.map保持输入顺序，输出可读性好，如果追求速度可以用as_completed但输出会乱序。

5. 避坑与排查：那些让我加班到凌晨的坑

5.1 现象：脚本在终端能跑，放进 cron 或后台就失败

原因：环境变量不同。终端里你source过 venv，PATH和PYTHONPATH都对；cron 用的是最小环境，找不到你的 venv，也找不到脚本里相对路径引用的字典文件。

解决：在 cron 里显式指定解释器绝对路径和工作目录，或者写一个 wrapper 脚本先cd再source。

# wrapper 脚本，cron 调用这个而不是直接调 python #!/bin/bash cd /home/user/tools/pt_collection/scanner || exit 1 source .venv/bin/activate python scan.py -u http://target -w ./dict.txt >> /var/log/scan.log 2>&1

cd那行保证相对路径正确，source激活环境，日志重定向方便排查。cron 里写0 2 * * * /home/user/wrapper.sh即可。

5.2 现象：requests 请求 HTTPS 站点报 SSL 证书错误

原因：目标用了自签名证书，或者你的 Python 环境缺少 CA 证书包。渗透场景下经常遇到自签名证书的内网系统。

解决：不要无脑verify=False，那会引入中间人风险且掩盖问题。先确认是证书问题还是环境问题，环境问题就装certifi并更新，确认是自签名再针对性关闭校验，同时关掉警告。

import requests import urllib3 # 确认是自签名证书后，局部关闭校验 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) r = requests.get("https://self-signed.target", verify=False, timeout=5)

disable_warnings只是屏蔽警告，不解决安全问题，仅用于授权测试。生产环境或不确定的场景，正确做法是把目标证书加到信任链，而不是关校验。

5.3 现象：并发脚本跑一会儿就卡死或报「Too many open files」

原因：文件描述符耗尽。每个 socket 连接占一个 fd，并发数高、连接不关闭就会撞上系统限制。

解决：先看当前限制ulimit -n，临时提高ulimit -n 65535，同时在代码里确保连接用完就关（用with语句或显式close）。线程池的max_workers不要设得比 fd 限制还高。

# 查看当前限制 ulimit -n # 临时提高到 65535，只对当前 shell 有效 ulimit -n 65535

永久修改要改/etc/security/limits.conf，但渗透测试一般临时提就行。代码层面，requests用with requests.Session() as s能复用连接并自动管理，比每次新建连接省 fd。

5.4 现象：脚本输出乱码或中文路径报错

原因：Windows 和 Linux 默认编码不同，合集里很多脚本是 Windows 下写的，读文件没指定编码。

解决：所有open()加encoding="utf-8"，输出重定向时设置PYTHONIOENCODING。

# 运行前设置环境变量，强制 UTF-8 export PYTHONIOENCODING=utf-8 export LANG=en_US.UTF-8 python script.py

代码里读字典、读配置的地方统一加encoding="utf-8", errors="ignore"，errors="ignore"能跳过无法解码的字节，避免整个脚本崩掉。

5.5 现象：杀软或 EDR 把脚本当恶意程序删了

原因：脚本里有subprocess调 shell、socket建连、写注册表等行为，特征像恶意软件。

解决：在隔离的测试环境跑，别在主力机上跑来源不明的脚本。虚拟机快照是后悔药，跑之前先打快照。如果必须在本机跑，把脚本目录加入杀软白名单，但前提是你已经读过代码，确认没有恶意逻辑。读代码这一步不能省，合集来源不明时尤其要警惕，有些脚本会偷偷外传数据。

6. 把合集变成自己的工具箱：脚本改造与验证的一个具体技巧

跑通一批脚本之后，真正的价值不在于「我有了这些脚本」，而在于「我能按需改这些脚本」。我最后会做一件事：给每个跑通的脚本写一个最小的验证用例，放在同级目录的test_前缀文件里。这个习惯来自一次翻车——我改了一个爆破脚本的并发逻辑，本地跑没问题，换到目标环境因为超时设置不同，把目标打挂了。从那以后，任何改动我都先写验证用例。

验证用例不需要复杂，核心是「给定已知输入，断言输出符合预期」。以端口扫描为例：

# test_scan.py，验证 scan_range 在已知开放端口上的行为 from scan import scan_range def test_localhost_ssh(): """本地若开了 22 端口，扫描结果应包含 22""" result = scan_range("127.0.0.1", [22], workers=1) # 这里不断言一定开放，因为环境不同，只验证函数不抛异常且返回列表 assert isinstance(result, list) def test_closed_port(): """扫一个几乎不可能开放的端口，结果应为空""" result = scan_range("127.0.0.1", [1], workers=1) assert 1 not in result

test_localhost_ssh故意不硬断言 22 一定开放，因为不同机器环境不同，硬断言会让测试在别人机器上失败。它只验证函数返回类型正确、不抛异常。test_closed_port扫端口 1，这个端口几乎不会开放，断言它不在结果里，能验证扫描逻辑没有把关闭端口误报为开放。这种「弱断言 + 强边界」的写法，适合渗透脚本这种依赖外部环境的场景。

跑测试用pytest，装一下就行：

pip install pytest pytest test_scan.py -v

-v显示每个用例的名字和结果，改完脚本跑一遍，几秒钟就知道有没有改坏。这个习惯让我在后续改造脚本时放心很多，不用每次手动跑一遍完整流程。

另一个技巧是给脚本加--dry-run参数。涉及实际发包、写文件、改配置的脚本，加一个 dry-run 模式，只打印「将要做什么」而不真正执行。改造起来就是在关键操作前加判断：

if args.dry_run: print(f"[DRY-RUN] 将请求 {url}") else: r = requests.get(url, timeout=args.timeout)

这个参数在调试阶段极其有用，能让你在不触碰目标的情况下验证逻辑分支对不对。我现在的习惯是，任何要发到目标网络的脚本，先 dry-run 跑一遍看输出，确认无误再去掉这个参数正式跑。

说到底，一个「Python渗透测试脚本工具合集」的价值，不在于它里面有多少个脚本，而在于你能不能把其中三五个改造成自己顺手、可验证、有测试兜底的工具。我自己的工具箱里常年只维护十来个脚本，每一个都有验证用例和 dry-run 模式，比攒几百个跑不起来的碎片踏实得多。希望帮到你。

本文还有配套的精品资源，点击获取