AWS 威胁情报报告：朝鲜黑客利用开源供应链发起攻击
TL;DR
AWS 威胁情报报告：朝鲜黑客利用开源供应链发起攻击
攻击手段已经改变。与朝鲜有关联的网络攻击者已不再对加固的基础设施进行直接、高难度的攻击，而是转向了一条更隐蔽的路径：开源软件供应链。根据一份最新的威胁情报报告，这些组织正在系统性地“投毒”，将恶意代码注入开发者盲目信任的存储库中。其目标是什么？通过后门潜入企业云环境，特别是那些托管在 Amazon Web Services (AWS) 上的环境。
这是一个针对现代开发运维（DevOps）时代升级的经典“特洛伊木马”场景。攻击者精心制作出看起来和用起来都像合法、高实用性库的软件包。一旦开发者在不知情的情况下将这些受污染的包拉取到构建流水线中，游戏就基本结束了。恶意代码随即触发，抓取环境变量、窃取 API 密钥，并直接从本地机器获取凭证。通过利用我们对第三方依赖项的固有信任，这些攻击者有效地绕过了企业耗资数百万美元维护的重型边界防御系统。
攻击剖析
他们是如何在不触发所有警报的情况下做到这一点的？这是一场多阶段行动，既依赖社会工程学，也依赖技术能力。
这一切始于人设。这些攻击者不仅仅是上传代码，他们还在建立可信度。他们在协作平台上创建虚假的开发者身份，通过为现有项目做出贡献并与社区互动来建立“声誉”。一旦赢得了信任，他们就会发动攻击。
攻击通常按以下方式展开：
- 依赖混淆（Dependency Confusion）： 攻击者向公共存储库上传一个与内部私有库同名的恶意包。如果构建系统配置不当，它会抓取公共（被投毒）版本，而不是私有版本。
- 凭证窃取： 代码执行的瞬间，它就开始搜寻。它会扫描本地开发环境，嗅探 AWS 访问密钥、秘密令牌以及任何其他可能授予云访问权限的配置文件。
- 隐蔽混淆： 他们并非业余选手。恶意代码通常经过深度混淆，专门设计用于绕过团队在 CI/CD 流水线中依赖的自动化静态分析工具和安全扫描器。
- 静默持久化： 一旦进入，他们不会大张旗鼓。他们会部署后门，以便进行长期监控和数据外泄，同时小心翼翼地避开标准的异常检测触发器。
云端风险
真正的危险不仅仅是笔记本电脑被入侵，而是“通往王国的钥匙”被窃。如果开发者的机器被攻破，攻击者就能获得存储在其主目录中的凭证，从而可能直接连通 AWS 管理控制台。从那里开始，爆炸半径将是巨大的。
| 阶段 | 潜在影响 | 安全含义 |
|---|---|---|
| 初始注入 | 低 | 本地开发机器被入侵 |
| 凭证窃取 | 高 | 未经授权访问云基础设施 |
| 权限提升 | 关键 | 修改资源和外泄数据的能力 |
| 持久化 | 关键 | 对云环境的长期控制 |
在零信任世界中进行防御
如果你仍然依赖基础的漏洞扫描来保持供应链的清洁，那么你已经落后了。安全团队需要对每一段外部代码采取“零信任”立场。仅仅检查已知的 CVE 已不再足够，你必须验证代码本身的完整性。
对于那些在 Amazon Web Services (AWS) 上运行基础设施的用户，防御策略需要是主动且分层的：
- 锁定依赖项： 停止拉取“最新（latest）”版本。使用特定的版本哈希，这样你就能确切知道进入环境的代码是什么。
- 镜像一切： 不要直接从外部拉取。使用内部镜像，确保只有经过审查、扫描和批准的软件包版本才能提供给开发者。
- 使用短期凭证： 如果你的 CI/CD 流水线中仍在使用长期静态密钥，请立即停止。实施自动化的短期凭证，在攻击者利用它们之前使其失效。
- 最小权限原则： 开发者的工作站不应拥有整个生产环境的密钥。限制权限，即使机器被入侵，损害也能被控制在一定范围内。
- 监控 API： 使用原生云日志监控你的 API 调用。如果发现来自开发者工作站的异常流量，你需要立即知晓。
更大的图景
这不仅仅是一个技术故障，而是国家支持的网络战的根本性转变。通过针对开发生命周期中的人员和软件要素，这些攻击者正在攻击我们构建和部署软件的基础。他们意识到，渗透开发者比突破云服务商加固的基础设施要容易得多。
当我们展望 AWS re:Invent 2026 等大型行业聚会时，讨论的重点正转向身份和供应链安全。我们正在进入一个验证代码完整性与保护云服务本身同样重要的时代。
可见性是唯一的出路。安全团队需要超越云环境，开始监控代码实际诞生的开发环境。你需要这种整体视角，以便在供应链攻击演变成灾难之前捕捉到细微的危险信号。
寻求加强管控的组织可以探索 AWS Marketplace 中用于自动化威胁检测和安全编排的工具。这些资源可以在不减慢云原生开发速度的情况下，帮助维持主动防御姿态。
归根结底，这是一场文化变革的呼吁。开发者和安全团队不能再各自为政。每一个外部依赖项都必须被视为潜在风险。通过拥抱这种警惕性并采用现代防御性编码实践，组织可以建立起一道抵御这些持久且复杂威胁的坚固防线。我们对全球软件生态系统的信任本身就是一种漏洞——是时候像管理漏洞一样去管理它了。
