一、事件核心全貌：打破认知的反向供应链攻击
2026年3月，全球爆发连环开源供应链投毒事件，绝大多数企业安全团队初期完全失察。本次攻击发起者为TeamPCP黑客组织，两名核心成员已于近期被澳大利亚联邦警方逮捕，面临十余项刑事指控。警方与跨境安全机构联合取证数据显示，该组织攻击周期长、链路完整、针对性极强，累计入侵全球1000+政企、互联网、科技机构，窃取50万组各类权限凭据，泄露、窃取数据总量达300GB。
本次事件区别于普通npm、PyPI单点包投毒，最核心的颠覆点在于：攻击者没有瞄准普通业务依赖库，而是精准拿下了企业用来做安全自检、漏洞扫描、合规检测的核心工具链。Trivy容器漏洞扫描器、Checkmarx KICS代码合规扫描工具、LiteLLM AI大模型网关，三类产品是当下DevSecOps体系的标准基建，几乎覆盖90%以上的云原生、AI研发企业。
传统供应链攻击，是恶意依赖库被业务代码引入，被动触发风险。TeamPCP的攻击逻辑完全反向：企业主动在CI/CD流水线、本地研发环境、服务器运维环境中，主动下载、安装、运行被投毒的安全工具。防御工具本身变成入侵入口，企业的安全自检流程，直接变成黑客的窃密、留后门、横向移动通道。
同时本次事件完全区别于同期ChainDrop蠕虫攻击。ChainDrop以npm包自我复制、批量传播为核心，攻击门槛低、覆盖面广、破坏力弱。TeamPCP全程采用凭证劫持+链式渗透+静默驻留的高阶打法，从上游安全工具源码仓库、CI流水线配置、包管理平台权限层层突破，逐级收割下游资产，攻击精准、隐蔽、持久，危害等级远超普通蠕虫传播。
很多企业事后复盘发现，自身早已被入侵数月，但常规安全设备、扫描工具、审计日志均未告警。核心原因就是企业默认信任官方安全工具，不会对Trivy、KICS这类合规工具做恶意行为审计，形成天然防御盲区。
二、TeamPCP完整攻击链路可视化溯源
本次连环攻击不是单次漏洞利用，而是一套完整的五阶段杀伤链，从权限劫持、工具投毒、环境窃密、凭证收割、横向扩散到持久驻留，形成闭环攻击体系。下面通过架构流程图完整还原攻击全路径。
2.1 整体攻击架构流程图
2.2 分阶段技术细节深度拆解
整个攻击链路环环相扣，每一个环节的技术手法都针对企业现有防御机制做了规避设计，这也是本次攻击大范围泛滥的核心原因。
第一阶段：核心安全工具Trivy全面沦陷
TeamPCP最先突破的是Aqua Security旗下Trivy漏洞扫描工具。攻击者通过社工、爆破、弱口令复用组合方式，获取Trivy官方仓库高权限维护凭据，直接接管GitHub仓库、Docker Hub镜像仓库、版本标签管理权限。
本次劫持并非修改单个版本，而是批量篡改trivy-action、setup-trivy仓库共计76个版本标签，仅一个老旧版本未被篡改。绝大多数企业CI/CD流水线采用固定版本标签部署，而非固定commit哈希值，只要流水线重启、工具更新，就会自动拉取攻击者控制的恶意版本。同时攻击者在Docker Hub推送无官方备案的恶意镜像v0.69.5、v0.69.6，覆盖主流部署场景。
恶意Trivy二进制文件具备极强的隐身能力：运行过程中会正常执行漏洞扫描逻辑，输出合规扫描报告，完全不影响企业正常研发流程。后台静默执行五阶段恶意载荷，读取GitHub Actions运行内存、服务器本地文件、环境变量，批量采集Git Token、云厂商AK/SK、SSH私钥、数据库密码、K8s配置凭据，采集完成后通过RSA-4096加密回传至攻击者C2服务器，全程无明文传输，规避基础流量审计。
第二阶段：横向渗透Checkmarx KICS，击穿代码合规防线
攻击者通过Trivy流水线窃取的企业与开源项目维护凭据，完成横向移动，成功入侵Checkmarx KICS开源静态代码扫描工具。KICS是企业代码合规、漏洞自查的核心工具，广泛用于金融、政企、大型互联网公司的代码审计流程。
这一阶段的攻击逻辑彻底打破企业分区防御思维。企业普遍认为，业务系统、对外服务是风险重点，内部安全工具、审计工具绝对可信。攻击者利用这种固有认知，将恶意代码植入合规扫描工具，让企业的代码审计流程主动执行恶意载荷，实现内网环境的深度扎根。此阶段攻击进一步收割各类研发团队私有凭据，为后续AI中间件入侵铺垫权限基础。
第三阶段：精准打击LiteLLM，实现全局Python环境沦陷
LiteLLM是当下最主流的AI大模型网关中间件，日下载量340万次，月下载量超9500万次，大量AI创业公司、企业AI业务、开源项目均依赖该组件统一对接OpenAI、Anthropic、通义千问等大模型接口。
TeamPCP利用前两阶段收割的PyPI维护者Token，伪造官方发布流程，推送1.82.7、1.82.8两个恶意版本。两个版本的恶意逻辑分层设计，杀伤力逐级递增。1.82.7版本仅在库被导入时触发窃密逻辑，1.82.8版本新增核心杀伤手段——植入litellm_init.pth文件。
绝大多数开发者不了解Python.pth机制：site-packages目录下的.pth文件，会在Python解释器启动瞬间自动加载执行，无需业务代码import对应库，无需手动调用任何接口。服务器Python脚本、自动化任务、CI构建、本地开发调试、Jupyter笔记，只要启动Python进程，恶意代码就会自动触发。这意味着只要安装恶意LiteLLM版本，整台服务器、研发设备的Python环境彻底失守。
第四阶段：多维度数据窃取与集群横向控制
恶意载荷启动后，会执行三阶段攻击逻辑，覆盖凭据窃取、集群控制、持久驻留三大能力。第一，批量扫描系统环境、配置文件、隐藏目录，采集50类以上敏感凭据，包含AI大模型API密钥、云资源密钥、K8s集群证书、SSH密钥、数据库账号密码。第二，加载K8s横向移动工具包，读取集群kubeconfig配置，获取集群管理员权限，窃取容器镜像、业务配置、核心数据，控制整个业务集群。第三，写入持久化后门，保证即使恶意LiteLLM版本被卸载，后门依然留存，持续接收攻击者远程指令。
第五阶段：数据变现与规模化收割
攻击者将窃取的50万组凭据、300GB脱敏原始数据整理打包，在暗网挂牌拍卖，针对政企、金融、AI企业数据定向溢价销售。同时利用留存后门持续监控受害企业研发动态、业务数据、权限变更，实现长期潜伏，持续窃取资产。澳大利亚警方最终通过资金链路、暗网交易日志、C2服务器溯源，锁定两名核心嫌疑人并实施抓捕。
三、TeamPCP攻击核心技术难点深度解析
本次攻击能够大规模泛滥、长期不被发现，核心在于攻击者利用了大量开发者、安全人员的认知盲区与工具底层机制漏洞，并非依靠高危CVE漏洞，传统漏洞库、IPS、WAF设备完全无法识别拦截。
3.1 Python .pth文件无感知触发机制（核心高危点）
常规Python恶意包投毒，必须依赖业务代码import对应库，触发条件有限，企业可以通过依赖审计、代码扫描规避风险。TeamPCP使用的.pth驻留机制，彻底绕过所有常规检测逻辑。
Python解释器启动流程固定：初始化环境 - 加载site模块 - 遍历site-packages下所有.pth文件 - 逐行执行文件内代码 - 启动业务进程。整个过程不依赖任何业务调用，属于解释器底层固有逻辑。
恶意版本植入的litellm_init.pth体积34KB+，内置加密载荷、C2通信模块、凭据采集规则、持久化逻辑。所有Python进程启动都会静默执行恶意代码，包括离线本地脚本、内网自动化任务、后台守护进程，完全脱离外网业务监控范围。
3.2 安全工具信任链崩塌逻辑
DevSecOps体系的核心信任逻辑是：官方开源安全工具 = 绝对可信。企业所有安全策略、审计规则、白名单机制，都会默认放行Trivy、KICS这类主流工具的所有行为。
攻击者精准利用这一信任机制，让恶意代码以“安全审计工具”的身份运行。工具的文件读取、网络请求、内存扫描、进程拉起行为，都会被安全设备判定为合法运维行为，不会触发告警。企业相当于主动给黑客开放了内网最高权限入口。
3.3 链式凭证劫持的传播逻辑
本次攻击不是单点投毒，是典型的链式传染。攻陷Trivy获取CI/CD凭据，利用CI凭据攻陷KICS，利用KICS维护权限收割PyPI Token，最终攻陷LiteLLM。每一级攻击获取的权限，都成为下一级渗透的跳板，风险层层放大，从单一工具漏洞演变为全链路供应链崩塌。
这种攻击模式的最大危害是：企业单点整改完全无效。只卸载LiteLLM恶意版本、只更新Trivy工具，无法清除前期被窃取的各类凭据，攻击者依然可以通过被盗权限二次入侵。
四、企业全场景批量检测实战脚本（可直接复制）
针对TeamPCP攻击特征，编写三套落地检测脚本，分别适配服务器环境、Python研发环境、CI/CD流水线环境，所有脚本无依赖、可直接执行、输出清晰结果，适配CentOS、Ubuntu、MacOS系统。
4.1 Python环境恶意版本与.pth后门查杀脚本
#!/usr/bin/env python3# TeamPCP LiteLLM恶意版本 + .pth后门查杀脚本# 适配所有Python环境，全局检测，一键执行importosimportsysimportsite# 定义恶意版本与后门文件特征MALICIOUS_VERSIONS=["1.82.7","1.82.8"]BACKDOOR_PTH="litellm_init.pth"C2_DOMAIN_FEATURE="models.litellm.cloud"defcheck_litellm_version():try:importlitellm current_ver=litellm.__version__ifcurrent_verinMALICIOUS_VERSIONS:print(f"[高危] 检测到恶意LiteLLM版本:{current_ver}")returnTrueelse:print(f"[正常] 当前LiteLLM版本:{current_ver}")returnFalseexceptImportError:print("[无害] 未安装LiteLLM组件")returnFalsedefcheck_pth_backdoor():site_paths=site.getsitepackages()has_backdoor=Falseforpathinsite_paths:pth_path=os.path.join(path,BACKDOOR_PTH)ifos.path.exists(pth_path):print(f"[高危] 发现后门文件:{pth_path}")# 读取文件检测C2特征withopen(pth_path,"r",encoding="utf-8",errors="ignore")asf:content=f.read()ifC2_DOMAIN_FEATUREincontent:print(f"[致命] 后门文件包含TeamPCP专属C2域名")has_backdoor=Trueifnothas_backdoor:print("[正常] 未检测到.pth后门文件")returnhas_backdoordefmain():print("===== TeamPCP Python环境安全检测开始 =====")v_res=check_litellm_version()p_res=check_pth_backdoor()print("===== 检测完成 =====")ifv_resorp_res:print("[紧急告警] 当前环境存在TeamPCP攻击残留，需立即清理并轮换密钥")sys.exit(1)else:print("[安全] 当前环境无TeamPCP恶意特征")sys.exit(0)if__name__=="__main__":main()4.2 服务器环境Trivy恶意镜像/版本检测脚本
#!/bin/bash# TeamPCP 恶意Trivy镜像/版本检测脚本# 适配Linux服务器、Docker环境set-eecho"===== 开始检测恶意Trivy资产 ====="# 检测恶意镜像版本MALICIOUS_TRIVY=("0.69.4""0.69.5""0.69.6")forverin${MALICIOUS_TRIVY[@]};doifdockerimages|grep-q"$ver";thenecho"[高危] 发现恶意Trivy镜像版本:$ver"fidone# 检测本地Trivy二进制版本ifcommand-vtrivy>/dev/null2>&1;thenTRIVY_VER=$(trivy--version|head-n1|awk'{print $2}')if[["${MALICIOUS_TRIVY[@]}"=~"${TRIVY_VER}"]];thenecho"[高危] 本地Trivy为恶意投毒版本:$TRIVY_VER"elseecho"[正常] 本地Trivy版本安全:$TRIVY_VER"fielseecho"[提示] 本地未安装Trivy"fi# 检测Docker Hub异常镜像缓存echo"===== 检测Docker异常缓存镜像 ====="dockerimages|grep-E"trivy|aquasec"|grep-v"official"echo"===== 检测结束 ====="4.3 CI/CD流水线凭据泄露风险检测脚本
#!/bin/bash# CI/CD环境敏感凭据泄露风险检测# 检测被TeamPCP重点窃取的凭据类型echo"===== CI/CD环境敏感凭据检测 ====="LEAK_KEYS=("GITHUB_TOKEN""PYPI_TOKEN""DOCKER_HUB_TOKEN""AWS_SECRET""ALIYUN_SK""KUBE_CONFIG""SSH_PRIVATE_KEY")forkeyin${LEAK_KEYS[@]};doif[-n"${!key}"];thenecho"[风险] 环境变量存在高危凭据:$key，疑似被窃取风险，需立即轮换"fidone# 检测流水线历史日志残留echo"===== 检测流水线日志敏感信息 ====="find./-name"*.log"-o-name"*.out"|xargsgrep-l"token\|secret\|key\|password"2>/dev/null|head-10echo"===== 检测完成 ====="五、分场景应急清理与修复落地流程
检测出风险后，不能仅简单卸载恶意组件，必须按照「清理后门-重置权限-轮换密钥-加固防御」的流程闭环处置，否则攻击者可通过留存权限二次入侵。下面是适配所有企业场景的标准化修复流程。
5.1 个人/研发设备应急修复
1. 执行上述Python查杀脚本，确认恶意LiteLLM版本与.pth后门文件位置，手动删除litellm_init.pth；2. 强制卸载恶意版本，安装安全干净版本1.82.6；3. 清空Python site-packages缓存、pip缓存；4. 轮换本机所有SSH密钥、云工具凭据、本地开发Token；5. 重启所有Python进程、终端、开发服务，确保后门完全失效。
# 一键清理恶意版本pip uninstall-ylitellm pipinstalllitellm==1.82.6# 清理缓存与后门rm-rf~/.cache/pipfind/-name"litellm_init.pth"-delete2>/dev/null5.2 服务器/生产环境修复
1. 停止所有Python业务进程、自动化任务、CI常驻进程；2. 批量查杀.pth后门文件，删除所有恶意LiteLLM版本；3. 清理恶意Trivy镜像、二进制文件，重新拉取官方签名镜像；4. 重置服务器所有环境变量凭据、kubeconfig配置、数据库密钥；5. 检查服务器定时任务、开机自启项，排查持久化后门；6. 重启服务器，确保所有恶意进程彻底终止。
5.3 CI/CD流水线全局修复（最关键）
1. 暂停所有流水线构建任务，阻断恶意代码执行链路；2. 批量轮换GitHub、GitLab、PyPI、Docker Hub所有发布Token、仓库权限密钥；3. 修改所有流水线配置，放弃版本标签引用，强制锁定commit哈希值部署；4. 开启流水线构件签名校验、来源溯源审计；5. 清理流水线历史日志、缓存构件，删除所有可疑构建产物；6. 最小化流水线运行账号权限，禁止流水线读取全局环境变量密钥。
六、企业长效供应链防御加固方案（可直接落地）
TeamPCP攻击暴露的不是单一工具漏洞，是企业供应链防御体系的系统性缺陷。常规的依赖漏洞扫描、版本更新无法抵御此类高阶攻击，必须从信任机制、权限管控、运行隔离、审计溯源四个维度重构防御体系。
6.1 打破安全工具固有信任链
企业必须摒弃“安全工具绝对可信”的固有思维。所有第三方开源工具，无论是否是主流安全产品，全部纳入同等安全审计范围。Trivy、KICS、SonarQube这类审计工具，运行时必须开启行为监控、网络拦截、文件读取审计，禁止工具无限制读取环境变量、密钥文件、系统配置。
6.2 CI/CD权限最小化硬核加固
1. 所有流水线账号禁止配置全局高权限Token，按需授权、单次有效；2. 流水线运行环境与生产环境、密钥存储环境物理隔离，禁止互通；3. 禁止使用latest、固定标签版本部署工具，全部锁定精准commit哈希；4. 所有第三方工具、依赖包强制开启签名校验、溯源校验；5. 流水线输出日志脱敏，禁止明文输出任何密钥、Token信息。
6.3 Python环境专项防护（规避.pth类后门）
1. 生产环境禁止随意安装开源Python包，所有依赖统一内部私有仓库托管、审核；2. 新增.pth文件监控告警规则，一旦检测到陌生.pth文件自动拦截告警；3. 禁用Python解释器全局自动执行权限，业务环境隔离运行；4. 定期批量扫描site-packages目录可疑文件，建立常态化巡检机制。
6.4 供应链风险常态化巡检机制
每周执行批量依赖版本审计、工具镜像溯源审计、凭据权限轮换审计，将本文检测脚本纳入自动化运维任务，定时全网扫描。针对AI中间件、安全工具、CI组件等高风险资产，建立单独的风险台账，重点监控版本更新、权限变更、网络外联行为。
七、本次攻击带来的行业前瞻性思考
TeamPCP攻击是AI时代软件供应链攻击的标志性事件，预示着未来黑客攻击方向的彻底转变。早期供应链攻击瞄准业务漏洞、普通依赖库，未来攻击会持续向底层基建、安全工具、AI中间件、研发基础设施转移。
AI行业的快速发展让LiteLLM这类中间件成为全网通用基建，海量企业高度依赖，一旦沦陷即可实现全网规模化入侵。同时企业安全团队普遍不熟悉Python底层机制、CI/CD运行逻辑、包发布链路，存在大量认知盲区，防御能力完全滞后于攻击手段。
更关键的是，本次攻击泄露的50万组凭据，会长期存在于暗网流通，后续会衍生出批量撞库、二次入侵、钓鱼攻击。企业即使完成本次修复，未来半年内依然存在极高的次生风险，必须持续做好密钥轮换、权限审计、行为监控。
未来企业供应链安全的核心竞争力，不再是漏洞扫描数量、合规报告完整性，而是对可信边界的管控能力、对未知攻击的感知能力、对基础设施的溯源能力。放弃固有信任认知，建立零信任供应链体系，是唯一的长效防御手段。
八、互动讨论
1. 你的企业CI/CD流水线是否还在使用版本标签部署Trivy、KICS等安全工具？是否完成commit哈希锁定整改？
2. 你们团队是否有针对Python .pth文件的专项监控策略？日常运维中是否关注过解释器底层执行风险？
