LLMjacking攻击解析：API密钥泄露的隐形代价

过去几年，有一个话题始终萦绕在全球技术从业者心头：AI。

AI 不再只是技术栈中的一员，而是正迅速成为整个技术栈的基石。客户服务、数据分析管道等核心业务功能正在向大语言模型（LLM）迁移，企业对 LLM 的依赖也与日俱增。这种依赖性已经被攻击者注意到了。随着 LLM 愈发深入核心业务流程，它们本身也成了极具价值的目标。

本文将解释 LLMjacking 是如何运作的、攻击可能带来的风险和代价，以及如何检测和防范此类攻击。

什么是 LLMjacking？

LLMjacking 指攻击者劫持对你的 LLM 的访问权限。LLM 的广泛采用虽然是近几年的事，但 LLMjacking 本身只是对一种熟悉攻击手法的翻新：获取被盗或泄露的凭证。在 LLM 时代之前，犯罪分子通常寻找 AWS 或 GCP 访问密钥，这些密钥可能让他们获得计算资源、存储空间和敏感的公司信息。

凭证被盗和泄露的后果已经够严重了，但 LLMjacking 对企业和客户造成的潜在伤害（无论是财务上还是声誉上）都要大得多。LLM 的使用通常是按量计费且价格不菲，因此滥用会直接转化为经济损失。如果密钥绑定了自定义模型、内部提示词或敏感数据管道，风险就不再仅仅是计算资源的问题了。与被盗的云密钥不同，被破解的 LLM 凭证可以让攻击者获取远不止原始数据的东西。

LLMjacking 会造成什么危害？

LLMjacking 事件的影响远不止意外的 API 使用量或飙升的账单。它可以迅速升级为重大经济损失、日常运营中断，以及敏感公司或客户数据的泄露。

深入了解这些风险非常重要，因为潜在后果涉及业务的多个方面。

LLMjacking 的财务影响

这通常是你注意到"出了问题"的第一地方。如果你在账单上看到了 LLMjacking 的影响，那说明攻击很可能已经造成了重大损害。攻击者如果对你的 LLM API 拥有无限制访问权，可以轻易地利用它来生成垃圾邮件模板、网络钓鱼网站，甚至为自己开发恶意软件。

如果你设置了用量和账单限额，你可能会认为自己很安全。攻击者用你的 LLM 毕竟也做不了太多，对吧？然而，任何依赖该 LLM 的下游智能体流程或自动化工作流也会受到影响。这可能对企业造成更大的财务影响，特别是当这些流程与关键业务功能绑定时。

自定义模型的恶意使用

有些企业严重依赖自定义模型——通常基于内部文档和业务流程进行训练，以帮助模型更好地理解企业的运作方式。越来越多的这类模型被用作新老员工的某种"百科全书"。如果你不确定如何处理某个特定文档，或者不知道某个具体情况应该找哪位员工，只需使用自定义模型问问 LLM 即可。

然而，如果攻击者获得了该模型的访问权，他们可能获取到本不希望公开的企业信息。这类信息可能被用来进一步扩大他们在网络中的立足点，或者让攻击者在暗网上出售这些信息。

在某些环境中，这些自定义模型还会不断使用新的组织或财务数据进行精调和训练。如果攻击者获得了训练数据或自定义模型训练方法的访问权，就可能为数据投毒创造机会。

攻击者可以随时间推移逐步影响模型，使其向员工提供误导性或有偏见的回答。虽然这是一种更耗时的手段，但让他们得以左右决策、呈现虚假信息或操纵内部流程。对模型做出的任何更改通常都非常细微，因此难以察觉。

不同的攻击向量

如前所述，LLMjacking 并不是什么新花样。这些攻击向量与攻击者此前用于获取 AWS/GCP/Azure 访问权限的手法类似。区别在于，这些指向你 LLM 的 API 密钥可能对你的企业造成更大的伤害。

在实践中，LLMjacking 通常涉及攻击者通过钓鱼、源代码泄露、配置错误的环境或暴露的客户端代码获取 API 密钥。

钓鱼

尽管 AI 辅助的攻击手段日益复杂，但攻击者仍然依赖最古老的手段之一：说服某人直接交出凭证。钓鱼活动仍然是获取 LLM 资源访问权的一种非常有效的方式，因为这些活动针对的是人，而不是技术。

一个精心炮制的钓鱼页面可能是大多数攻击者获取你凭证的最简单途径。所有老套路依然有效：制造紧迫感的假象，或伪造平台通知，所有这些都是为了给用户施压使其快速行动。

云端或应用程序配置不当

配置不当的云环境仍然是攻击者获取敏感凭证最便捷的途径之一，LLM 集成也不例外。API 密钥通常存储在环境变量、配置文件、容器镜像、CI/CD 管道或日志系统中，而这些本不应被公开访问。过于宽松的 S3 存储桶、暴露的 Kubernetes 控制台，或安全性不足的 Git 仓库，都可以让攻击者获得所需的一切，而无需直接利用漏洞。

现代技术栈中 LLM 集成的部署速度之快，使这种攻击向量的潜在影响更加严重。团队往往会优先考虑功能而非安全最佳实践。凭证就是这样泄露的，给潜在攻击者提供了对你 LLM 完全、无过滤的访问权。

如何监控和检测 LLMjacking 攻击？

检测 LLMjacking 事件与其说是发现单一明显的入侵（尽管你仍应留意），不如说是识别异常的用量模式。

被盗的 API 密钥通常以模仿合法使用的方式被使用，这使得传统安全监控工具可能更难发现异常。

首先为企业的 LLM 使用建立基线

在能够检测异常行为之前，你需要了解企业的"正常"是什么样子的。这意味着要建立 API 请求量、令牌消耗和常用 API 端点的基线。这个基线还应该跨越不同时间段建立。你们在月底通常会有用量高峰吗？每隔一周的周二呢？

可靠的基线可以帮助区分有机的用量变化和潜在的滥用。这个基线应该被用来持续对比当前的用量模式，一旦发现异常应立即调查，以确定是合法的用量高峰还是更恶劣的行为。

监控账单用量警报

账单用量警报可能是你发现环境内出现"异常"情况的第一信号。如果攻击者以"低调缓慢"的方式混入并滥用你的 LLM，你可能无法察觉。

然而，大多数攻击者可能会尽可能多地使用你的 LLM 资源，因为他们担心在完成所需操作之前就失去访问权。这不可避免地会触发账单用量警报，在这种情况下，你应该尽快调查并采取行动。

如何防御 LLMjacking？

防御 LLMjacking 很大程度上在于首先让凭证更难被获取。由于攻击通常依赖于有效的 API 密钥而不是利用模型本身，传统的防火墙和其他安全硬件实际上派不上用场。相反，有效的防御依赖于强凭证管理、严格的访问控制，以及对你系统中这些凭证使用情况的持续可见性的组合。

强制执行良好的凭证卫生

这是限制 LLMjacking 事件影响最有效的方法之一。它缩短了攻击者在你的某个密钥泄露后的可乘之机。定期轮换 API 密钥可以确保任何泄露的凭证都有有限的寿命。

特定于工作负载的密钥增加了另一层重要的隔离。不是用一个共享凭证跨多个服务授予广泛访问权，而是每个应用、服务或环境都有自己作用域狭窄的身份。这样应该会使滥用更容易被检测和隔离，因为异常用量可以追溯到特定的工作负载，而不是混入常规流量中。

特定于工作负载的密钥还有一个额外好处：减少被泄露密钥的爆炸半径。这些密钥应该只能访问特定端点进行特定操作。

应用最小权限原则

特定于工作负载的密钥是实现最小权限原则的一种方式。应用最小权限原则实际上是要抵制给每个集成"以防万一"级别访问权限的诱惑。如果一个 API 密钥可以访问多个模型、环境或下游系统，那么窃取它的人实际上继承了该密钥本不应拥有的更多能力。

这些原则同样应该应用于你的人类用户。营销部门的 Carol 真的需要访问生产环境提示词、客户数据管道和你的微调法律摘要模型吗？可能不需要。同样，通过将权限严格限定到特定的工作负载、端点甚至模型，你可以确保被泄露的密钥将限制攻击者可能从该密钥中获得的能力。

基本安全原则

有时候我们会忘记，基本安全措施也能帮助你抵御 LLMjacking 攻击。LLMjacking 并不是一种新奇的高级漏洞，威胁要搞垮你的整个组织。以下几点将有助于加强你的整体安全态势，并帮助你检测和防止 LLMjacking 事件。

使用适当的密钥管理平台，如 Hashicorp Vault。这对于自动化轮换特定于工作负载的密钥特别有用，从而最大限度地减少被泄露密钥的效用。

GitHub 在所有仓库中默认启用了推送保护，在包含密钥的提交到达代码库之前就会将其拦截。确保在你的仓库设置中没有将其禁用。这并不意味着密钥不会漏过去。如果真的发生，务必将该密钥视为已泄露，立即轮换。

集中化你的审计和访问日志，例如使用 SIEM 解决方案。这有助于创建你的初始基线，以及从集中位置监控异常情况。

LLMjacking 是新的；但它利用的漏洞不是

资源劫持对许多网络安全专业人员来说是一个熟悉的故事。攻击者窃取凭证，然后为了自己的利益利用这些凭证，损失由受害者承担。LLMjacking 只是这个故事中较新的一章，而且潜在风险比之前更高。有了 LLMjacking，攻击者获得与你的系统和员工相同级别的访问权。这可能导致财务损害，并有可能暴露你公司和客户的敏感数据。

这一威胁尤其令人担忧，因为 LLM 深度嵌入现代技术栈。它们不再是孤立的工具，而是影响决策、自动化流程并实时与数据交互的组件。

防御 LLMjacking 不需要花哨的安全机制；而是需要把基础工作做好。把那些 API 密钥当作高价值资产来对待，限制它们的作用范围，并有目的地监控它们的使用。虽然这些密钥背后的技术是新的，但被利用的弱点是众所周知的，也是充分理解的。