LiteLLM SANDCLOCK供应链攻击实战复盘:漏洞自查、密钥轮换、全域防御清单

📅 2026/8/21 20:20:55
LiteLLM SANDCLOCK供应链攻击实战复盘:漏洞自查、密钥轮换、全域防御清单
前言打破表象直击本次攻击的底层逻辑绝大多数安全团队对Python供应链攻击的认知还停留在“恶意包被手动安装、代码被导入后触发”的传统逻辑里。SANDCLOCK行动彻底颠覆了这个认知这也是本次攻击能大规模爆破、骗过绝大多数企业安全审计的核心原因。攻击者没有利用LiteLLM本身的代码漏洞没有挖掘系统权限缺陷而是利用企业安全体系的底层信任漏洞行业普遍信任主流安全工具、默认开源项目官方发布权限可信、CI/CD流水线依赖不做哈希校验、开发环境密钥裸奔。本次攻击最致命的设计不是窃取凭证而是无感知触发、全域搜刮、长效危害。恶意LiteLLM版本不需要开发者手动调用、不需要业务代码导入只要Python解释器启动后门就静默运行。短短40分钟的恶意包上架时间击穿了全球数千家企业的AI研发安全防线泄露的LLM密钥、云凭证、集群Token至今仍被黑产批量利用。本文基于一线应急实战经验完整复盘SANDCLOCK攻击全链路拆解攻击者的战术细节提供可直接落地的批量自查脚本、容器镜像检测方案、密钥轮换全流程、CI/CD防御加固清单从开发者、安全运维、架构三个维度解决AI供应链投毒的自查、处置、长效防御问题。一、事件全景还原SANDCLOCK行动完整经过1.1 事件时间线精准实战版2026年3月24日威胁团伙TeamPCP启动SANDCLOCK供应链多级投毒攻击整套攻击链路经过长期铺垫并非临时突击1. 前置渗透阶段团伙攻陷开源安全扫描工具Trivy的官方CI/CD发布流水线篡改工具编译逻辑植入权限窃取后门2. 权限窃取阶段利用Trivy在LiteLLM官方发布流程中的依赖调用关系窃取LiteLLM官方PyPI发布Token3. 恶意投毒阶段使用正版发布权限向PyPI官方仓库推送两个带后门的正式版本 litellm-1.82.7、litellm-1.82.84. 窗口期扩散阶段40分钟公开窗口期内全球数万开发机、CI流水线、容器镜像拉取恶意版本5. 官方处置阶段LiteLLM官方监测到异常紧急下架恶意版本、重置所有发布权限、推送修复版本6. 风险遗留阶段大量企业未及时轮换密钥攻击者持续利用泄露凭证访问目标AI资源、云服务、业务集群。1.2 核心危害拆解真实落地风险很多团队误以为“包下架就安全”这是本次事件最大的认知误区。恶意包存在时间极短但凭证泄露的危害是永久性的。攻击者通过后门批量采集的敏感资产覆盖企业AI研发全链路1. AI核心资产OpenAI、Anthropic、Gemini、阿里云百炼、腾讯混元、百度文心一言全平台API密钥2. 云基础设施资产AWS、GCP、阿里云、腾讯云AccessKey、SecretKey、临时权限凭证3. 容器集群资产K8s ServiceAccount Token、kubeconfig集群配置、命名空间权限凭证4. 研发运维资产Git仓库私人令牌、SSH私钥、服务器登录密钥、数据库账号密码5. 流水线资产CI/CD流水线环境变量密钥、自动化部署凭证、镜像仓库登录令牌。截至目前全网监测到的异常访问行为超10万次大量中小企业的AI服务接口被批量调用、云资源被恶意挖矿、代码仓库被拖库。二、SANDCLOCK攻击链深度拆解附架构流程图本次攻击属于典型的多级级联供应链攻击区别于单一包投毒攻击者利用“安全工具→开源项目→下游用户”的信任链路逐层突破每一环都是企业安全体系的常规盲区。下面完整拆解四层攻击链路并附上可视化流程架构。2.1 完整攻击链路流程图攻陷Trivy CI/CD流水线篡改Trivy编译逻辑LiteLLM官方发布调用Trivy扫描窃取LiteLLM PyPI发布Token投递恶意版本1.82.7/1.82.8至PyPI企业开发机/CI/容器拉取恶意包Python解释器启动触发.pth后门全域搜刮主机/环境敏感凭证RSA加密凭证回传C2服务器落地持久化后门实现常驻K8s集群横向移动权限扩散长期窃取AI/云/集群核心资源2.2 每一层攻击细节实战拆解第一层攻破安全基石反向利用信任关系所有主流开源项目的发布流程都会接入Trivy做漏洞扫描、恶意代码检测LiteLLM也不例外。企业和开源社区默认Trivy是安全工具不会对其做版本锁定、代码校验这是攻击者选中它的核心原因。攻击者篡改Trivy的流水线编译脚本让工具在运行扫描任务时自动读取当前运行环境的所有环境变量。LiteLLM的发布流水线中环境变量存放着可直接推送PyPI包的最高权限Token。安全工具本是防御屏障最终变成了权限窃取的突破口。第二层正版权限投毒绕过所有源站校验这是本次攻击最具迷惑性的点。恶意包不是第三方伪造包是使用官方合法权限发布的正版包。PyPI的源站校验、签名校验、开发者校验全部通过常规的依赖安全扫描工具无法识别异常。两个恶意版本采用了差异化后门设计规避基础检测1. litellm-1.82.7恶意代码嵌入核心业务文件 proxy_server.py用户启动LiteLLM代理服务时触发凭证窃取2. litellm-1.82.8新增 litellm_init.pth 启动项文件实现无差别触发无需启动业务服务、无需导入库只要本机Python启动后门自动执行。第三层PTH机制滥用实现零感知静默入侵Python的.pth路径加载机制是本次攻击的核心技术支点。正常场景下.pth文件用于配置Python模块搜索路径Python解释器初始化阶段会自动遍历解析所有.pth文件。攻击者在恶意.pth文件中嵌入多层Base64混淆的执行代码绕过静态代码扫描。文件无异常命名、无明显恶意特征静态审计、依赖扫描、木马检测工具均无法拦截。后门执行后不会产生弹窗、不会报错、不会占用高资源全程后台静默运行完成全维度凭证搜刮覆盖环境变量、隐藏配置文件、系统密钥目录、集群凭证路径。第四层加密外传持久化横向扩散实现长效控制攻击者采集所有敏感凭证后通过内置RSA公钥加密处理再回传至专属C2域名 models.litellm.cloud。加密传输的设计让网络流量审计无法抓取明文凭证规避流量检测设备。单次入侵不会终止后门会在用户主机写入 ~/.config/sysmon/sysmon.py 持久化脚本实现开机自启。同时检测当前运行环境若处于K8s集群内会自动读取集群配置尝试横向访问集群内所有节点、容器、配置项扩散攻击范围。三、恶意版本精准识别IOC指标与风险判定标准很多企业排查时只核对版本号忽略间接依赖、残留文件、持久化后门导致排查漏报。本节提供完整可落地的IOC特征、风险判定标准区分高危、低危、无风险场景。3.1 版本风险清单精准判定高危恶意版本必处置、必轮换密钥litellm-1.82.7、litellm-1.82.8安全基线版本可正常使用1.82.6及以下旧稳定版本、1.83.7及以上官方修复版本隐形风险场景极易漏报项目未直接引入LiteLLM但依赖CrewAI、DSPy、LangGraph、PydanticAI等AI Agent框架上述框架间接依赖恶意版本。3.2 完整IOC特征库文件IOC1. 恶意启动文件litellm_init.pth2. 恶意业务文件哈希proxy_server.py SHA256 a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b3. 持久化后门路径~/.config/sysmon/sysmon.py网络IOC恶意C2域名models.litellm.cloud所有出站访问该域名的主机、容器均为失陷资产代码特征IOCPython站点目录下.pth文件包含Base64编码、exec动态执行、subprocess系统调用、网络外传代码片段。四、全域自查工具主机容器CI流水线全套可执行脚本网上多数自查脚本仅检测版本号无法扫描残留后门、间接依赖、容器镜像层风险。本节提供三套实战脚本分别适配本地主机应急排查、Python环境深度检测、容器镜像静态扫描全部可直接复制执行。4.1 深度Python环境自查脚本完整可运行脚本功能精准检测恶意版本、扫描可疑.pth后门、校验恶意文件哈希、排查持久化后门、输出风险报告仅检测不修改业务文件。#!/usr/bin/env python3# LiteLLM SANDCLOCK 全域自查脚本 V2.0# 适配开发机、服务器、Python运行环境# 检测维度恶意版本、可疑pth后门、恶意proxy文件、持久化后门importimportlib.metadataimportsiteimportosimporthashlibimportglob# 恶意版本定义MALICIOUS_VERSIONS{1.82.7,1.82.8}# 恶意文件哈希MAL_PROXY_SHA256a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b# 可疑代码特征SUSPICIOUS_RULES[base64,exec(,subprocess,requests.post,socket.connect]# 持久化后门路径PERSIST_BACKDOORos.path.expanduser(~/.config/sysmon/sysmon.py)defcheck_litellm_version():检测当前环境Litellm版本try:verimportlib.metadata.version(litellm)returnver,verinMALICIOUS_VERSIONSexceptimportlib.metadata.PackageNotFoundError:returnNone,Falsedefscan_pth_backdoor():扫描所有站点目录下可疑.pth后门文件suspicious_files[]site_pathssite.getsitepackages()forpathinsite_paths:pth_filesglob.glob(os.path.join(path,*.pth))forpthinpth_files:try:withopen(pth,r,encodingutf-8,errorsignore)asf:contentf.read()ifany(ruleincontentforruleinSUSPICIOUS_RULES):suspicious_files.append(pth)exceptException:continuereturnsuspicious_filesdefverify_mal_proxy():校验恶意proxy_server.py文件哈希site_pathssite.getsitepackages()target_files[]forpathinsite_paths:proxy_pathos.path.join(path,litellm,proxy,proxy_server.py)ifos.path.exists(proxy_path):target_files.append(proxy_path)hit_files[]forfileintarget_files:sha256hashlib.sha256(open(file,rb).read()).hexdigest()ifsha256MAL_PROXY_SHA256:hit_files.append(file)returnhit_filesdefcheck_persist_backdoor():检测本地持久化后门returnos.path.exists(PERSIST_BACKDOOR)defmain():print(*60)print(LiteLLM SANDCLOCK 供应链攻击深度自查工具)print(*60)# 版本检测ver,is_malcheck_litellm_version()ifnotver:print(\n[正常] 当前环境未安装Litellm组件)else:print(f\n[信息] 当前Litellm版本{ver})ifis_mal:print([严重风险] 检测到恶意受攻击版本立即隔离主机并处置)else:print([低风险] 版本号无异常仍需排查间接依赖与残留文件)# PTH后门检测pth_resultsscan_pth_backdoor()ifpth_results:print(f\n[严重风险] 发现{len(pth_results)}个可疑.pth后门文件)forfinpth_results:print(f -{f})else:print(\n[正常] 未扫描到可疑.pth后门载荷)# 恶意代理文件检测proxy_resultsverify_mal_proxy()ifproxy_results:print(f\n[严重风险] 发现{len(proxy_results)}个恶意proxy_server.py文件)forfinproxy_results:print(f -{f})else:print(\n[正常] 未匹配恶意proxy文件哈希)# 持久化后门检测persist_statuscheck_persist_backdoor()ifpersist_status:print(f\n[严重风险] 检测到持久化后门{PERSIST_BACKDOOR})else:print(\n[正常] 未检测到本地持久化后门)print(\n*60)print(自查完成高危项需立即隔离、清理、轮换全部密钥)print(*60)if__name____main__:main()4.2 Shell快速应急排查命令生产秒用适用于服务器、CI Runner、容器临时应急排查无需安装依赖直接执行# 1. 查看当前Litellm版本pip show litellm# 2. 全局扫描可疑.pth恶意文件find$(python3-cimport site;print( .join(site.getsitepackages()))) -name *.pth -exec grep -lE base64|exec|subprocess {} \; # 3. 检测持久化后门文件 ls -la ~/.config/sysmon/sysmon.py # 4. 排查C2域名外联记录 grep -r models.litellm.cloud /var/log/ /tmp/ ~/.cache/2/dev/null4.3 Docker容器镜像静态检测脚本大量风险藏在历史容器镜像中镜像缓存的恶意版本不会随本地卸载消失本条脚本用于批量扫描本地镜像风险#!/bin/bash# 容器镜像Litellm恶意版本检测脚本IMAGES$(dockerimages-q)forimgin$IMAGES;doecho正在检测镜像$imgdockerrun--rm$imgbash-cpip show litellm 2/dev/null | grep -E 1.82.7|1.82.8if[$?-eq0];thenecho[高危] 镜像$img包含恶意Litellm版本立即废弃fidone五、事件响应SOP失陷资产完整处置流程对抗式安全的核心是只要存在风险暴露窗口默认凭证全部泄露。不要心存侥幸不要以“没发现恶意文件”为依据跳过密钥轮换。本节是可落地的企业标准化处置流程适配所有规模团队。5.1 第一步资产隔离阻断扩散1. 所有检测出风险的开发机、服务器、CI Runner立即断开外网禁止重启主机防止持久化后门触发自启扩散2. 暂停所有AI项目CI/CD构建任务冻结容器镜像仓库防止恶意镜像持续分发3. 封禁C2域名 models.litellm.cloud 出站流量在防火墙、WAF、主机安全组全局拦截。5.2 第二步恶意文件全量清理# 卸载恶意包pip uninstall litellm-y# 清理所有恶意pth文件find$(python3-cimport site;print( .join(site.getsitepackages()))) -name litellm_init.pth-execrm-f{}\;# 删除持久化后门rm-rf~/.config/sysmon/# 清空pip缓存与临时构建文件pip cache purgerm-rf/tmp/pip-* ~/.cache/pip/build/*5.3 第三步全维度密钥轮换清单必做以下所有凭证只要环境运行过恶意版本必须全部作废重建无例外1. AI大模型凭证OpenAI、Anthropic、Gemini、国内全平台大模型API Key全部撤销重生成2. 云服务凭证阿里云、腾讯云、AWS、GCP所有AccessKey、IAM子账号密钥轮换3. 容器集群凭证K8s所有ServiceAccount Token、kubeconfig配置、集群管理员凭证重置4. 代码仓库凭证GitHub、GitLab、Gitee私人访问令牌、部署令牌全部作废5. 运维登录凭证所有服务器SSH私钥、跳板机密钥对重新生成清理全网authorized_keys6. 业务数据库凭证MySQL、PostgreSQL、Redis等核心数据库、缓存密码重置7. CI/CD凭证Jenkins、GitLab CI、GitHub Actions所有环境变量密钥、流水线Secret重建。5.4 第四步流水线与镜像回溯整改1. 回溯2026年3月24日前后所有CI构建日志统计受影响的项目、分支、镜像版本2. 销毁所有缓存恶意依赖的容器镜像、构建缓存、Runner临时环境3. 临时锁定所有AI项目依赖版本禁止自动更新第三方Python包。六、AI供应链长效防御清单生产落地版基于第一性原理复盘本次攻击的根源不是单个漏洞是企业AI供应链的信任失控、依赖管控失效、权限体系裸奔。本节从依赖管控、CI/CD加固、运行时监控、架构优化四个维度给出可直接落地的防御规范。6.1 依赖管控杜绝模糊版本与无校验引入1. 生产环境禁止使用、^、~等模糊版本号所有Python依赖固定精准版本错误写法litellm1.80.0正确写法litellm1.83.72. 生产构建强制开启哈希校验杜绝篡改包、投毒包安装pipinstall--require-hashes-rrequirements.txt3. 搭建企业私有PyPI镜像仓库外部开源包设置7天冷却窗口期新发布版本禁止直接接入生产4. 接入pip-audit、Snyk、Dependabot自动化扫描重点检测间接依赖供应链风险5. 所有CI流水线使用的安全工具、扫描工具、编译工具全部锁定固定版本禁止latest标签。6.2 CI/CD安全加固封堵权限窃取核心入口1. 废弃所有长期静态发布Token、部署密钥统一使用云厂商OIDC临时短时效身份认证2. CI/CD Runner采用一次性销毁机制构建任务结束立即销毁容器/虚拟机不保留任何缓存与密钥3. 所有流水线密钥禁止写入环境变量明文统一接入密钥管理系统Vault、云密钥服务动态注入4. 防火墙限制CI节点出站流量仅允许业务必要域名访问拦截未知外连行为5. 拆分开发、测试、生产三套独立流水线环境杜绝研发环境密钥泄露影响生产。6.3 运行时监控精准捕获后门异常行为1. 主机安全系统新增监控规则监控Python解释器启动时.pth文件新增、修改行为2. 全网拦截 models.litellm.cloud 等恶意域名外联实时告警异常网络请求3. 云平台开启密钥异常访问告警监测陌生IP、陌生地区调用LLM API、云服务接口4. 定期扫描主机隐藏目录、用户配置目录排查持久化后门文件。6.4 架构层面优化缩小攻击爆炸半径1. AI网关统一代理所有大模型调用业务服务不直接持有LLM原生密钥网关统一鉴权、签发短期临时Token2. 隔离AI研发环境与生产云资源权限研发环境密钥禁止具备生产资源访问权限3. 核心云资源、集群资源开启最小权限原则杜绝全局超级密钥、通配权限。七、底层复盘AI供应链安全的核心盲区传统安全防护聚焦业务代码漏洞、主机漏洞、网络攻击几乎所有企业都忽略了工具链供应链安全。SANDCLOCK行动最核心的启示企业信任的安全工具、开源组件、CI插件是当前黑产最优先突破的入口。AI生态的特殊性放大了风险绝大多数AI项目高度依赖LiteLLM这类统一网关组件一旦网关被投毒全网AI密钥批量泄露。同时AI Agent框架层层嵌套间接依赖风险传播范围呈指数级扩散排查难度远超传统业务系统。很多团队的安全整改只停留在“删包、升级版本”忽略凭证长效泄露的风险。在供应链攻击中代码修复只是基础密钥轮换、权限重置、架构加固才是闭环。只要泄露的密钥未作废攻击者可以持续潜伏入侵企业的安全整改完全无效。文末互动提问1. 你们团队的AI项目依赖是否还在使用模糊版本号、latest有没有做过间接依赖供应链安全审计2. 你的企业CI/CD流水线是否使用长期静态密钥、未做出站流量白名单管控