2026年10月开发与基础设施平台连环入侵事件回顾

今年十月（2026年），在针对开发和基础设施平台的一系列平台入侵事件中，我帮助了许多受害者。我平时很少有这么多的应急响应工作，所以这次对我来说非同寻常。 我想分享一些回顾性的思考，谈谈本可以如何预防这些事件！ 如果你所在的领导层对“面对黑色十月我们能做些什么”感到好奇，并愿意做出实质性的改变，以下这些方向可能有用。 简而言之：一批为开发或基础设施提供支持的公司在一个短时间内接连被入侵。它们的密钥控制平面和/或客户环境遭到攻陷。 这形成了“中心辐射”模式：中心被攻破意味着攻击者突然就能访问大量辐射节点（即中心的受害客户）。大量凭据在短时间内被泄露（GitHub个人访问令牌、长期AWS密钥、AI平台密钥等等）。 我主要与辐射节点合作：也就是这些中心的下游公司，它们曾信任中心并交出了长期有效的凭据。 所幸的是，每家公司都有动力去整体提升安全资源投入。但他们也想讨论与自身事件相关的实质性、可立即推进的项目。 每个受害公司的工程师都问了同一个问题：在事件被控制住之后，我们该聚焦什么？ 这些事件大多数始于受影响的新云厂商的凭据泄露。据我估计，在我观察到的各起事件中，最初泄露的凭据有90%（可能更多）属于那些本可以通过基于网络的允许列表来限制的应用程序，从而限制攻击者的远程使用。 这些泄露的凭据大多随后导致了反复的横向移动，转向其他凭据，主要是通过GitHub令牌获取对存放更多密钥的内部仓库的访问权。这些凭据大多同样支持允许列表。 如果对网络、策略和凭据进行配置，使其能够感知网络使用情况，或许本可以阻止我十月处理的所有事件。至少，攻击者需要比泄露凭据更多的访问权限。 在我个人观察到的所有案例中（除一个之外），被暴露的凭据都是从远程的、不熟悉的网络被利用的。在我观察到的几乎所有案例中，除非攻击者还找到了从熟悉网络发起请求的方法，否则这些凭据对他们来说毫无用处。 我在这里使用“全栈”这个含义丰富的词，是因为并不存在单一的瓶颈来实施网络策略；而且为了做到彻底，你应该把同样的分段隔离思路应用到凭据之外的领域。（网络、应用程序、认证门户等等。） 黑色十月期间泄露的一些凭据让其所有者措手不及。 这使得轮换变得困难。你不能盲目地轮换密钥。通常，这些密钥根本不需要存在，本可以用基于角色的凭据或Workload Identity Federation来替代。这些方案可以提供短期凭据，无需手动轮换长期密钥，而且也能受益于网络限制。 秉持“没有不受管理的密钥”的基础设施理念，你可以把任何能以明文形式找到的密钥都视为问题。当密钥的获取是一个受管理的过程时，你就更容易确定它们在哪里被使用。 日志本身不能预防事件，但它们的存在会大大改善事件响应中每个人的心情。 对我来说，日志准备情况是响应工作需要多长时间的有力预测指标。我处理的一些黑色十月事件在几天内就披露了，有些则花了数周。我可以很有把握地说，这种差异源于日志的可获取性。 把与安全相关的日志集中到一个地方，并确保它们可用。响应者应该能够快速基于取证指标进行追踪，并构建出谁在何时何地做了什么事的清晰时间线。 受害者不得不向他们的客户做出披露。披露的效果从积极到极其难看都有。有证据支持的说明，加上分享入侵指标（IOC）和战术、技术与程序（TTP），对让客户保持满意大有帮助。在入侵发生后，你实际上仍然可以让客户满意。要我说，这取决于你能分享多少。 最好的办法显然是完全不发生入侵，但一旦发生了，就尽可能多地分享。日志让这一点成为可能。 这些都是高投入的项目，但与我上个月观察到的情况非常契合。如果你在寻找更全面的安全方法，我在scrty.io上的其他文章可能有用。