摘要近期网络安全公司 Darktrace 披露了一起针对流行的人工智能AI网关 LiteLLM 的攻击事件攻击者成功劫持了连接至 Amazon Bedrock 服务的企业级AI网关并将其转变为加密货币“矿机”。这起事件再次凸显了 AI 基础设施在实际部署中所面临的严峻安全挑战。本报告需要特别指出Darktrace 发现的这起攻击与2026年7月初安全社区广泛关注的 LiteLLM 严重漏洞链CVE-2026-47101、CVE-2026-47102、CVE-2026-40217综合 CVSS 评分为9.9是两起截然不同的独立事件。后者是应用层面的远程代码执行漏洞 [[1]][[2]][[3]]而前者则是一次典型的运维层面安全疏忽所导致的入侵其根源在于暴露在公网的 SSH 端口和薄弱的凭证管理。本报告旨在提供一份从攻击复盘、应急响应到长期加固的全方位实战指南。我们将深度剖析攻击者如何利用运维缺口一步步控制服务器提供实用的排查脚本和工具帮助组织自查是否存在类似的供应链及运维风险并最终提供一套详尽的AI基础设施安全基线和加固教程涵盖密钥管理、最小权限原则、网络分段和自动化监控告警旨在帮助企业构建一个更具韧性的 AI 服务环境。第一章攻击链深度剖析从SSH暴露到AI网关沦为“矿机”这起由 Darktrace 发现的攻击事件其攻击链条清晰且经典充分暴露了在快速部署 AI 应用时基础运维安全被忽视所带来的巨大风险。攻击者并未利用任何高深的应用层0-day漏洞而是通过最传统、最直接的方式取得了系统的控制权。1.1. 初始入口被遗忘的SSH端口攻击的第一步始于一个在公网上暴露的 SSH (Secure Shell) 服务端口。在云环境中为了方便远程管理开发者和运维人员常常会为虚拟机或容器宿主机开启 SSH 服务。然而如果缺乏严格的安全配置这个管理入口就会变成对攻击者敞开的大门。攻击者通常使用 Shodan、Censys 等网络空间搜索引擎自动化地扫描全球互联网上开放了标准22端口或其他常见SSH端口的服务器。一旦发现目标他们便会采用以下一种或多种方式尝试突破弱密码/默认密码攻击许多服务器在初始化后仍使用云服务商提供的默认密码或管理员设置了“admin”、“123456”之类的极弱密码。攻击者可利用自动化工具进行大规模字典攻击和暴力破解。凭证泄露利用攻击者可能通过其他渠道如代码仓库泄露、其他平台数据泄露获取了合法的 SSH 用户名和密码或私钥从而直接登录。在这类攻击中攻击者一旦成功登录就获得了在服务器上执行命令的立足点。对于托管着像 LiteLLM 这样关键中间件的服务器而言这意味着整个 AI 服务链路的咽喉要道已经失守。1.2. 横向移动与凭证窃取瞄准云服务密钥LiteLLM 作为一个AI模型网关其核心功能是统一管理和代理对各种大型语言模型LLMAPI的调用 [[4]]。在此次事件中被攻击的网关连接的是 Amazon Bedrock这意味着该服务器上必然存储了访问 Bedrock 服务的 AWS 凭证。攻击者在获得服务器的初始访问权限后其首要目标就是进行信息搜集和权限提升寻找更有价值的凭证。他们会系统性地检查以下位置环境变量printenv或env命令可以列出所有环境变量攻击者会重点查找AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY等敏感变量。配置文件LiteLLM 自身的config.yaml文件或相关启动脚本是凭证存储的重灾区 [[5]][[6]]。开发者为了方便常常将密钥硬编码在这些文件中。Shell 历史记录.bash_history文件可能记录了管理员之前执行过的包含明文密码或密钥的命令。Docker 环境如果 LiteLLM 部署在 Docker 中攻击者会检查 Docker 环境变量 (docker inspect container_id) 或挂载的卷中是否存在敏感文件。AI 网关之所以成为高价值目标正是因为它是一个凭证的“交汇点”。它掌握着通往昂贵、强大的后端 AI 服务的“钥匙”。攻击者窃取这些凭证后不仅可以滥用 Bedrock 服务产生高昂费用甚至可以利用这些凭证在 AWS 账户内进行更深层次的横向移动对企业的整个云环境构成威胁。1.3. 恶意负载部署加密货币挖矿程序的植入与伪装在搜刮完有价值的凭证后攻击者的下一个目标是将服务器的计算资源变现。加密货币挖矿是最直接、最常见的方式之一。攻击者通过以下步骤部署挖矿程序下载恶意软件使用wget或curl等常见命令行工具从他们控制的服务器下载挖矿程序的可执行文件 [[7]][[8]]。这些程序通常会经过打包或混淆以绕过简单的静态检测。赋予执行权限并运行使用chmod x命令赋予文件执行权限然后以后台进程方式运行。根据 Darktrace 的报告在此次事件中攻击者部署了名为NBMiner的挖矿软件 [[9]][[10]]。其执行时使用的命令行参数模式非常典型揭示了其完整的挖矿意图process_name-akawpow-oasia.ravenminer.com:3838-uR9KVhfjiqSuSVcpYw5G8VDayPkjSipbiMb.worker-i60-a kawpow指定了挖矿算法KAWPOW通常用于挖掘 Ravencoin (RVN) 等加密货币。-o asia.ravenminer.com:3838指定了矿池的地址和端口。这明确表示计算资源被用于为ravenminer.com这个公共矿池服务。-u R9KVhfjiqSuSVcpYw5G8VDayPkjSipbiMb.worker这是攻击者的钱包地址和矿工名。所有挖矿收益都将归入这个地址。为了确保持久化和隐蔽性攻击者还会采取一些额外措施例如将挖矿程序写入cron定时任务 [[11]]或者使用技术手段隐藏进程窗口 [[12]]甚至将恶意进程伪装成合法的系统服务名称从而增加检测和清除的难度。至此一个为企业提供 AI 服务的关键网关便彻底沦为了攻击者的“矿机”。第二章应急响应与排查供应链与运维双重检测当发现系统异常如CPU/GPU持续高负载、网络流量异常时必须立即启动应急响应流程。排查应双管齐下既要处理当前由运维疏忽SSH暴露导致的入侵也要同步排查并修复并行的应用层供应链风险。2.1. 第一步排查LiteLLM供应链投毒风险尽管本次挖矿事件的直接原因是 SSH 暴露但我们不能忽视 LiteLLM 在近期爆出的严重应用层漏洞。攻击者完全有可能利用 SSH 入侵作为跳板再去利用应用漏洞进行更深层次的破坏。因此检查并修复 LiteLLM 自身的漏洞是应急响应中至关重要的一环。关键漏洞链 (CVE-2026-47101/47102/40217):CVE-2026-47101 (授权绕过):允许攻击者构造特殊的 API 密钥绕过角色限制将普通用户权限提升至管理员从而完全控制代理服务器 [[13]]。CVE-2026-47102 (权限提升):漏洞链中的一环用于最终提升至proxy_admin权限 [[14]][[15]]。CVE-2026-40217 (沙箱逃逸):另一个在同一周期内修复的严重漏洞 [[16]][[17]][[18]]。CVE-2026-42271 (命令注入):一个已被在野利用并被 CISA 加入 KEV 目录的高危漏洞允许通过特定端点执行任意命令 [[19]][[20]][[21]]。排查与修复步骤检查当前版本登录到您的服务器执行以下命令查看已安装的 LiteLLM 版本。pip show litellm关注输出中的Version字段。如果版本低于1.83.14-stable则您的系统正暴露在上述高危漏洞的风险之下。立即升级LiteLLM 维护方 BerriAI 已在v1.83.14-stable版本中修复了所有相关问题 [[22]][[23]]。请立即执行升级操作pipinstall--upgradelitellm1.83.14验证供应链完整性供应链投毒是严重威胁。除了升级还应采取以下措施验证包的完整性 [[24]][[25]][[26]]锁定依赖版本在您的requirements.txt或pyproject.toml文件中将 LiteLLM 的版本固定为已知的安全版本例如litellm1.83.14防止自动安装到有问题的版本。审查依赖树使用pipdeptree等工具检查 LiteLLM 的传递依赖项确保没有引入其他可疑的包 [[27]]。使用安全扫描工具在CI/CD流程中集成供应链安全工具自动扫描依赖项中的已知漏洞和恶意代码签名 [[28]]。2.2. 第二步SSH暴露端口与安全基线核查解决完应用层风险后必须立即加固导致此次入侵的根本原因——薄弱的SSH服务配置。以下是一个全面的SSH安全加固基线和自动化脚本可用于快速审查和加固您的Linux服务器 [[29]][[30]][[31]]。SSH 安全加固 Shell 脚本示例:#!/bin/bash# LiteLLM Server SSH Hardening Script# Date: 2026-07-12# WARNING: Run with caution. Backup your sshd_config first.SSHD_CONFIG/etc/ssh/sshd_configBACKUP_CONFIG/etc/ssh/sshd_config.bak.$(date%F-%T)echoBacking up sshd_config to${BACKUP_CONFIG}...cp${SSHD_CONFIG}${BACKUP_CONFIG}echoApplying security hardening to${SSHD_CONFIG}...# 1. Change default port (uncomment and set your desired port)# sed -i s/#Port 22/Port 2222/g ${SSHD_CONFIG}# echo SSH port changed. Remember to update your firewall rules.# 2. Disable root loginsed-is/PermitRootLogin yes/PermitRootLogin no/g${SSHD_CONFIG}sed-is/#PermitRootLogin prohibit-password/PermitRootLogin no/g${SSHD_CONFIG}# 3. Disable password-based authentication (ensure you have key-based auth set up!)sed-is/PasswordAuthentication yes/PasswordAuthentication no/g${SSHD_CONFIG}sed-is/#PasswordAuthentication no/PasswordAuthentication no/g# 4. Enable public key authenticationsed-is/#PubkeyAuthentication yes/PubkeyAuthentication yes/g# 5. Set idle timeout intervalifgrep-qClientAliveInterval${SSHD_CONFIG};thensed-is/ClientAliveInterval.*/ClientAliveInterval 300/g${SSHD_CONFIG}elseechoClientAliveInterval 300${SSHD_CONFIG}fiifgrep-qClientAliveCountMax${SSHD_CONFIG};thensed-is/ClientAliveCountMax.*/ClientAliveCountMax 2/g${SSHD_CONFIG}elseechoClientAliveCountMax 2${SSHD_CONFIG}fi# 6. Limit allowed users (uncomment and add your user)# echo AllowUsers your_admin_user ${SSHD_CONFIG}# 7. Disable X11 Forwardingsed-is/X11Forwarding yes/X11Forwarding no/gechoRestarting SSH service to apply changes...# Use systemctl for modern systemsifcommand-vsystemctl/dev/null;thensystemctl restart sshd# Use service for older systemselifcommand-vservice/dev/null;thenservicesshrestartelseechoCould not restart SSH service automatically. Please do it manually.exit1fiechoSSH hardening applied successfully.echoIMPORTANT: Do NOT close your current session until you have tested logging in on a new terminal.注意在运行此脚本前务必确保您已经配置了基于密钥的SSH登录否则PasswordAuthentication no会使您无法登录服务器。2.3. 第三步识别加密挖矿的“蛛丝马迹”Indicators of Compromise, IoCs在应急响应过程中确认系统是否已被植入挖矿程序是关键。以下是具体的检测指标和方法CPU/GPU 资源异常挖矿特征加密货币挖矿特别是基于GPU的挖矿其计算模式是持续、高强度的哈希运算。这会导致 CPU 或 GPU 利用率长时间稳定在 95%-100% 的水平 [[32]]。LLM 推理特征合法的 LLM 推理工作负载通常是“突发性”的。当请求到来时GPU 负载会瞬间飙升完成推理后迅速回落。其负载模式对内存带宽更为敏感因此平均计算单元利用率可能并不高有时甚至低于 30%-70% [[33]][[34]][[35]]。检测方法使用top,htop(CPU) 和nvidia-smi(NVIDIA GPU) 等工具观察资源利用率曲线。如果发现利用率长时间“拉满”且没有明显波动这便是挖矿活动的一个强烈信号。网络连接异常挖矿程序需要连接到矿池才能接收任务和提交结果。这些连接具有明显特征。检测方法使用netstat -anp或ss -tp命令检查网络连接。重点关注那些连接到非业务相关、尤其是国外 IP 的长时间 TCP 连接。根据 Darktrace 的报告应特别警惕到asia.ravenminer.com或其解析IP以及端口为3838的出站连接 [[36]]。可疑进程与命令行这是最直接的证据。攻击者可能会伪装进程名但命令行参数往往会暴露其真实意图。常见进程名nbminer,xmrig,minerd,cpuminer,kdevtmpfsi等 [[37]][[38]][[39]]。命令行特征使用ps aux | grep -v grep | grep -E xmrig|miner|stratum|crypto等命令进行筛选。任何包含-o(矿池地址)、-u(钱包地址)、stratumtcp(挖矿协议) 或常见加密货币名称的命令行都应被视为高度可疑 [[40]][[41]][[42]]。文件系统变更攻击者会在服务器上留下恶意文件。检测方法检查/tmp,/var/tmp等临时目录以及 LiteLLM 的安装目录寻找近期创建的、名称可疑的可执行文件。使用 Linux 内核审计系统 (auditd) 来主动监控关键目录的文件修改。可以添加以下规则来监控 LiteLLM 安装目录的变化 [[43]][[44]][[45]]# 添加审计规则-w 指定路径-p 指定权限(wwrite, aattribute change)-k 是一个易于搜索的键auditctl-w/path/to/your/litellm/installation/-pwa-klitellm_file_changes之后可以使用ausearch -k litellm_file_changes来查看所有相关的修改日志。第三章AI基础设施深度加固构建纵深防御体系应急响应只能解决燃眉之急。为了从根本上杜绝此类事件的再次发生必须对整个 AI 基础设施进行深度加固建立一个多层次的纵深防御体系。3.1. 密钥管理从硬编码到云原生KMS此次攻击中攻击者能够轻易窃取 Amazon Bedrock 凭证根源在于凭证管理方式不当。严禁在任何代码、配置文件或环境变量中以明文形式硬编码任何密钥。推荐方案使用 AWS Secrets Manager 或 AWS Systems Manager Parameter Store将 Bedrock 的 API 密钥等敏感信息存储在这些专门的密钥管理服务KMS中 [[46]][[47]]。这些服务提供加密存储、访问控制和自动轮换功能。采用 IAM 角色进行身份验证为运行 LiteLLM 的 EC2 实例或 ECS/EKS 容器创建一个专用的 IAM 角色。在角色策略中仅授予其调用 Bedrock 服务所需的权限。应用程序通过 AWS SDK 自动从实例元数据服务获取临时凭证完全无需在服务器上存储任何长期密钥 [[48]]。这种方式是 AWS 推荐的最佳实践。凭证轮换即使使用了 KMS也应制定定期的凭证轮换策略。一旦发生任何疑似泄露事件应立即通过 KMS 强制轮换所有相关凭证使被盗的旧凭证失效 [[49]][[50]][[51]]。3.2. 最小权限原则收紧AI网关的每一道门最小权限原则Principle of Least Privilege, PoLP是安全的核心。必须确保系统的每个组件仅拥有完成其任务所必需的最小权限。云层面 (IAM)为 LiteLLM 实例配置的 IAM 角色策略应极其严格。例如如果它只需要使用 Bedrock 的claude-3-sonnet模型策略应如下所示明确拒绝所有其他操作{Version:2012-10-17,Statement:[{Effect:Allow,Action:bedrock:InvokeModel,Resource:arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0}]}应用层面 (LiteLLM)访问控制仔细审查 LiteLLM 的config.yaml。如果不需要通过 API 动态生成新的密钥应考虑通过网关或防火墙规则禁用/key/generate这个管理端点 [[52]][[53]]。速率限制为不同的 API 密钥设置精细的、合理的速率限制如model_rpm_limit,model_tpm_limit这不仅可以控制成本还能在密钥被盗时减缓滥用速度 [[54]]。移除默认用户移除或禁用 LiteLLM 中任何默认的、低权限的账户如internal_user以减少潜在的攻击面 [[55]]。容器层面 (Docker/Docker Compose)非 Root 用户在 Dockerfile 中使用USER指令指定一个非 root 用户来运行应用程序。禁止权限提升在docker-compose.yaml文件中为 LiteLLM 服务添加security_opt防止容器内的进程通过setuid或setgid二进制文件获得新的权限 [[56]][[57]][[58]]。services:litellm:image:ghcr.io/berriai/litellm:main-stable# ... other configurationssecurity_opt:-no-new-privileges:true3.3. 网络分段与出口管制切断矿工与矿池的连接一个有效的网络策略可以极大限制攻击者在入侵成功后的活动范围特别是阻止其与外部 C2 服务器或矿池的通信。微隔离 (Kubernetes Network Policy)如果 LiteLLM 部署在 Kubernetes 中应实施“默认拒绝”Default Deny的网络策略即默认情况下禁止所有 Pod 之间的流量。然后再根据业务需要显式地允许必要的通信。出口Egress规则示例以下 Network Policy 示例仅允许 LiteLLM Pod 访问内部 DNS 服务和外部的 Amazon Bedrock 端点其他所有出站流量都将被阻止 [[59]][[60]][[61]]。apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:litellm-egress-policynamespace:ai-servicesspec:podSelector:matchLabels:app:litellmpolicyTypes:-Egressegress:# 1. Allow DNS lookups-to:-namespaceSelector:{}podSelector:matchLabels:k8s-app:kube-dnsports:-protocol:UDPport:53-protocol:TCPport:53# 2. Allow traffic to AWS Bedrock Endpoints-to:-ipBlock:# Note: Use AWSs published IP ranges for the specific service and region.# Example CIDR for AWS services.cidr:52.94.0.0/19ports:-protocol:TCPport:443云网络防火墙 (AWS Security Groups Network Firewall)安全组Security Group这是最基础的出口管制。为 LiteLLM 所在的 EC2 实例配置安全组将其出站规则设置为默认拒绝。然后仅为 HTTPS (TCP/443) 添加一条出站规则其目标应设为 AWS 为其服务如 Bedrock提供的托管前缀列表 (Managed Prefix List)而不是宽泛的0.0.0.0/0[[62]][[63]]。AWS Network Firewall对于需要更精细控制的场景AWS Network Firewall 是更强大的工具。它可以配置基于完全限定域名FQDN的过滤规则。您可以创建一个规则组只允许出站流量访问*.bedrock-runtime.region.amazonaws.com这样的域名从而彻底阻止任何到未知 IP 或恶意域名如矿池域名的连接企图 [[64]][[65]]。第四章自动化监控与告警让攻击无所遁形主动的、自动化的监控是发现潜在攻击的关键。仅仅依赖被动的防御措施是不够的必须假设系统随时可能被突破并通过监控来及时发现异常。4.1. 资源利用率监控识别“挖矿”心跳配置 Amazon CloudWatch Alarm为托管 LiteLLM 的 EC2 实例创建 CloudWatch 告警。监控指标CPUUtilization。如果实例有 GPU请安装 CloudWatch Agent 来推送自定义的GPUUtilization指标。告警规则示例当CPUUtilization指标在连续的15分钟内平均值持续高于95%时触发一个高优先级的告警并通过 SNS 发送通知给安全团队。这个阈值和时间窗口应根据您正常 LLM 推理负载的基线进行调整。4.2. 网络流量监控捕获恶意通信启用 AWS GuardDutyGuardDuty 是一个托管的威胁检测服务它利用机器学习和集成的威胁情报来持续监控恶意的或未经授权的行为。它能够自动检测多种威胁其中包括CryptoCurrency:EC2/BitcoinTool.B!DNS这类发现即 EC2 实例正在查询与加密货币活动相关的域名 [[66]]。它还会分析 VPC Flow Logs检测与已知恶意 IP包括矿池IP的通信 [[67]][[68]]。启用 GuardDuty 是捕获此类活动最简单有效的方法。分析 VPC Flow Logs启用 VPC Flow Logs 并将其发送到 Amazon S3 或 CloudWatch Logs。您可以使用 Amazon Athena 或 CloudWatch Logs Insights 定期查询这些日志寻找异常模式例如连接到非标准端口的大量出站流量。与大量不同外部 IP 地址的持续性小数据包通信。被安全组或网络ACL拒绝的大量出站连接尝试。利用 AWS Network Firewall 日志如果您部署了 AWS Network Firewall请务必将其警报日志Alert Logs和流日志Flow Logs发送到 CloudWatch 或 Kinesis Data Firehose [[69]][[70]]。配置 CloudWatch 告警当防火墙日志中出现与高风险规则如“阻止到已知恶意IP列表的连接”匹配的条目时立即触发警报。4.3. 应用与系统日志分析发现入侵线索暴力破解与异常登录告警系统日志配置规则来监控/var/log/auth.log或/var/log/secure中的 SSH 登录失败事件。使用fail2ban等工具可以自动阻止在短时间内多次尝试失败的 IP 地址。应用日志将 LiteLLM 的应用日志特别是认证失败的日志发送到 CloudWatch Logs。然后您可以使用 CloudWatch Logs Insights 来查询和告警。CloudWatch Logs Insights 查询示例检测1分钟内来自同一IP的超过5次失败认证fieldstimestamp,message|filtermessagelike/(?i)Failed authentication|Unauthorized/|parsemessageip*asclientIp# Adjust parsing based on your log format|statscount(*)asfailureCountbyclientIp,bin(1m)|filter failureCount5|sortbyfailureCountdesc这个查询的思路来源于通用日志分析方法 [[71]][[72]][[73]]需要根据您 LiteLLM 日志中记录失败认证的具体格式进行调整。关联分析的重要性将不同来源的日志进行关联分析可以发现更隐蔽的攻击模式。例如在系统日志中发现一次来自异常地理位置的成功 SSH 登录紧接着在 LiteLLM 应用日志中观察到该时间点附近有管理员权限的操作如生成了新的 API 密钥这便是一个极强的入侵信号 [[74]][[75]]。SIEM安全信息和事件管理系统是实现这种高级关联分析的理想平台。第五章事件响应与取证恢复从灾难中重建信任当监控系统发出警报确认系统已被入侵后必须遵循一套标准化的事件响应流程以最小化损失、清除威胁并从中吸取教训。5.1. 事件响应标准流程 (IR Playbook)隔离 (Containment)立即行动这是首要步骤。通过修改安全组规则将受感染服务器的出站和入站规则都设置为拒绝所有立即将其与网络隔离。这可以防止攻击者进一步的横向移动或数据外泄 [[76]]。取证 (Forensics)保存证据在对服务器做任何更改之前为其创建一个磁盘快照Volume Snapshot和内存转储Memory Dump。这些是进行后续数字取证、分析攻击者行为和确定根本原因的关键证据。切勿在原始系统上直接操作以免破坏证据 [[77]][[78]][[79]]。根除 (Eradication)确定根本原因基于取证分析确定攻击的入口点如SSH弱密码、攻击者使用的工具和技术以及系统被篡改的范围。恢复 (Recovery)凭证轮换这是恢复阶段最关键、最紧急的任务。立即在 AWS IAM 中轮换或删除所有可能泄露的访问密钥特别是用于访问 Amazon Bedrock 的凭证。同时轮换所有服务器的 SSH 密钥、数据库密码、以及 LiteLLM 自身的所有 API 密钥 [[80]][[81]][[82]]。系统重建绝对不要试图“清理”一个被入侵的系统。攻击者可能留下了难以发现的后门或 rootkit。正确的做法是终止受感染的实例并从一个已知的、干净的、经过安全加固的 AMIAmazon Machine Image或 Docker 镜像重新启动一个全新的实例。应用加固部署在新实例上重新部署 LiteLLM 之前必须确保本报告第三章和第四章中提到的所有安全加固措施都已完全实施。数据恢复从可信的、未受污染的备份中恢复必要的配置和数据。5.2. 供应链投毒的深度核查在恢复过程中必须对软件供应链的完整性进行严格核查以防引入其他潜在风险。完整性校验从 LiteLLM 的官方 PyPI 页面或 GitHub Release 页面下载软件包并使用官方提供的 SHA-256 哈希值对其进行校验确保下载的软件包在传输过程中未被篡改 [[83]][[84]]。依赖审查在部署前使用pipdeptree等工具详细审查 LiteLLM 的所有直接和传递依赖项。检查是否存在任何异常、拼写错误typosquatting或不再维护的库这些都可能是供应链攻击的潜在入口 [[85]]。集成自动化扫描工具将开源容器扫描工具集成到您的 CI/CD 流程中。例如DockerScan这个工具被明确设计用于检测供应链攻击包括扫描容器镜像中是否存在已知的加密货币挖矿程序如 xmrig的签名 [[86]]。这种自动化扫描可以在部署前捕获已知的恶意软件。结论Darktrace 发现的这起 LiteLLM AI 网关被劫持用于加密货币挖矿的事件为所有正在拥抱 AI 技术的组织敲响了警钟。它清晰地表明AI 基础设施的安全是一个涉及应用、运维和云平台的多层次、系统性工程。即使 AI 应用本身如 LiteLLM 的某个安全版本没有已知漏洞一个看似微不足道的运维疏忽——比如一个暴露在公网、使用弱密码的 SSH 端口——也足以让整个系统防线土崩瓦解使宝贵的计算资源和敏感数据暴露在攻击者面前。应对这一挑战组织必须摒弃“单点防御”的思维采取**纵深防御Defense in Depth**的战略。这包括在应用层面持续关注并修复已披露的漏洞并对软件供应链的完整性保持警惕。在运维层面严格遵循最小权限原则加固所有管理入口并实施严格的密钥管理生命周期。在平台层面充分利用云平台提供的网络分段、出口管制和威胁检测能力限制攻击者的活动空间。在流程层面建立自动化的监控告警和快速的事件响应机制确保在攻击发生时能够及时发现、有效遏制并快速恢复。AI 的未来充满机遇但其安全基石必须牢固。只有将安全内建于 AI 基础设施的每一个环节企业才能在享受技术红利的同时有效保护其关键的数字资产。