微软内部Solorigate调查 - 最终更新

我们相信Solorigate事件是与社区合作、共享信息、加强防御和应对攻击的机会。我们现在已完成对攻击者活动的内部调查，并希望分享我们的发现，这些发现证实我们没有发现访问生产服务或客户数据的证据。调查也未发现任何迹象表明微软的系统被用于攻击他人。由于我们的深度防御保护，攻击者也无法获得特权凭证或利用SAML技术攻击我们的企业域。

附加细节

正如我们之前报告的那样，我们在12月检测到异常活动并采取行动保护我们的系统。我们的分析显示，源代码仓库中文件的首次查看是在11月下旬，并在我们保护受影响的账户时结束。我们持续看到攻击者在2021年1月初尝试访问但未成功，随后尝试停止。

没有任何情况下所有与任何单一产品或服务相关的仓库被访问。绝大多数源代码未被访问。对于几乎所有被访问的代码仓库，只有少数个别文件因仓库搜索而被查看。

对于少数仓库，存在额外的访问，包括在某些情况下下载组件源代码。这些仓库包含以下代码：

• Azure组件的一小部分子集（服务、安全、身份的子集）
• Intune组件的一小部分子集
• Exchange组件的一小部分子集

攻击者使用的搜索词表明他们专注于尝试查找密钥。我们的开发政策禁止在代码中包含密钥，并且我们运行自动化工具来验证合规性。由于检测到的活动，我们立即启动了仓库当前和历史分支的验证过程。我们已确认仓库合规且不包含任何活跃的生产凭证。

经验教训

网络安全行业长期以来都知道，理论上，复杂且资金充足的攻击者能够使用高级技术、耐心并在雷达下操作，但这一事件证明这不仅仅是理论。对我们来说，这些攻击强化了两个关键经验，我们希望强调——采用零信任心态和保护特权凭证。

零信任、“假设已被入侵”的哲学是防御的关键部分。零信任是从隐式信任——假设公司网络内部的一切都是安全的——过渡到假设已被入侵并根据所有可用信号和数据明确验证身份、端点、网络和其他资源的安全状态的模型。我们最近分享了使用零信任原则保护免受像Solorigate这样的复杂攻击的指南。

保护凭证至关重要。在将本地基础设施连接到云的部署中，组织可以将信任委托给本地组件。这创造了组织需要保护的额外接缝。这一决策的后果是，如果本地环境被入侵，这将为攻击者提供针对云服务的机会。我们强烈建议掌握云中的身份，如保护您的M365云服务免受本地攻击中所述。

我们还在《翻过Solorigate的一页，为安全社区开启新篇章》中分享了关于这些最佳实践的更多见解。尽管我们的内部调查即将结束，但这并不意味着我们已经完成。这意味着我们正在维持正常的零信任安全态势，我们的安全团队持续工作以保护用户、设备和数据免受对我们环境的持续威胁。我们与网络安全社区合作保护免受持续威胁的工作仍在继续，并且随着我们了解更多，我们将酌情分享经验和指南。