“劫后余生”：全球最大航运公司遭勒索病毒攻击后的事

本文最初发布于 gvnshtn.com 网站，经原作者授权由 InfoQ 中文站编译并分享。

Maersk（马士基）是全球最大的航运和集装箱物流综合公司。我非常荣幸地成为了他们的身份控制和访问管理（IAM）主题专家（SME），以及后来的 IAM 服务负责人。2017 年，我和公司其他几十人一起应对了广为人知的 notPetya 恶意软件攻击事件。

这篇文章的目的是分享一些我们的经验和教训，以便给后来者参考。攻击是迟早会发生的，诚然我们有很多先进的装备，但很多组织从一开始就做错了。

这个故事涉及 2015 年到 2019 年我在 Maersk 的经历，其中包括 notPetya 事件和恢复工作，以及我最后离开前加入控制和保护措施的事情。

2015 年

我从 2015 年初开始在 Maersk 工作。Maersk 历史悠久，他们的 IT 部门有一点很有趣，就是他们在整个集团中交付 IT 服务的方式。当时，这个组织分散为服务于不同部门（物流、能源、运输）的多个业务部门。以前，每个业务部门都有自己的 IT。但由于 Maersk 航运公司（运输业务）是其中最大的，其 IT 部门自然也最为强大，并已开始向其他业务部门提供一些共享的 IT 服务。在经过数年的政治和权力斗争后，Maersk 的能源业务被出售，公司将资源集中在运输和物流上。与此同时，IT 也逐渐集中化，组织的最高层建立了数字和云优先战略。

蜜月

一开始，我参与了一个项目。公司彼时在通过一个著名的身份和访问管理（IAM）产品将共享的 HR 系统插入 Active Directory，这款产品有一些向导式自定义 Web 服务和数据库后端服务来方便集成。项目的参与者包括英国和丹麦的同事，横跨 IT、HR 等业务部门，IAM 技术要素则由微软提供支持。这个项目持续到 2015 年底，走过了一场艰辛的旅程。我们的资源有限，但在所有人的努力下解决方案的进展很快。

关系巩固

Maersk 有着令人自豪的历史，它成绩斐然，是很好的工作场所，而这个项目让我感受到了家的温暖。上线任务是在几个周末内完成的，我们花了几个小时进行了一些真正的冒险，包括在凌晨 3 点以物理方式“闯入”存在问题的旧服务器！最终，解决方案成功上线，在大约六万活跃用户中，我们只错误地删除了一个帐户。好样的！

2016 年

IAM 项目的成功帮我在第一年的绩效评估中获得了最高分，我还参加了微软 Ignite 大会，给履历表又添了漂亮的一笔。

最高特权原则

我在 Maersk 的工作主要是（现在称为）身份验证和安全项目：身份管理、特权访问管理、智能卡登录系统等。IAM 系统现在可以处理典型的就职、调职和离职流程，那么我的下一个任务就是特权访问管理。在上一个项目中，我发现旧架构普遍不遵循最小特权原则。航运是一项庞大的业务，但利润相对较低。那时，IT 一直被视作成本中心而非业务推动者。安全控制的优先权被高层排在了后面。我们的旧架构有多种安全部门，没有明确的主管，并且资金有限。

失去机会

那时，我们本可以并且应该一直在应用一致的安全策略来控制帐户和访问的。你可以逐步推进变革。你也可以应用新标准并为它构建服务，然后随着时间的推移升级更多服务，最后你的旧系统要么焕然一新，要么死掉。你获得的预算越多，流程就越快。一些控制策略的典型例子包括：

• 服务帐户不应在多个应用程序中使用

• 最终用户生产力帐户不应在任何位置具有管理员权限

• 服务器管理员帐户在工作站上不应具有管理员权限

列表很长，但这只是基本的 Microsoft 安全基准或分层访问模型的内容。

在此期间，我们的 MSP 试图推销一款特权访问管理（PAM）产品，以对用于访问我们 MSP 托管系统的 MSP 凭据进行凭据循环控制；一直以来，我们都在所有 Maersk MSP 托管的服务器上，将一个充满所有 Maersk 和 MSP 成员的活动目录（AD）组放入本地管理员组。这还不够。除了访问风险（不考虑凭据），那些非 MSP 托管包该怎么办？因此，我也在同时推动 IAM 解决方案的 PAM 组件作为替代方案。

我一厢情愿地认为公司应该用上一些行业水平的东西，但败在了成本管理政策下，毕竟我的后兜里没有几百万美元！

2017 年

当我在特权访问项目上四处碰壁时，我们也在同时做其他事情。我们将运营团队移交给新的供应商；Maersk 收购 Hamburg Sud 时，我们参与了一些有趣的合并活动；邮件自动化正在进行中……生活很美好。

在遥远的土地上，俄罗斯黑客一直在攻击乌克兰。在乌克兰运营的所有企业通常都使用某款财务应用程序。攻击者已经黑掉了应用程序的供应商，并将 notPetya 恶意软件注入到它的软件更新中。尽职尽责的财务人员在不知不觉中开门放进了一款破坏力极大的恶意软件。

notPetya

在 2017 年 6 月 27 日，问题突然爆发！

大约上午 10 点，我们正在一个玻璃墙会议室开会。外面的人开始躁动起来，可能发生了一些小故障。然后，一些愤怒的人走进来把我们揪出去做事，我们才意识到：办公室里的一些工作站似乎挂掉了。不，不仅仅是我们的办公室。在全球范围内，所有设备正在逐渐完蛋。服务器呢？域控制器不见了？天哪……几个小时内，我们就损失惨重。这影响了地球上每台加入域的 Windows 笔记本电脑、台式机、虚拟机和物理服务器。

这家组织刚刚被送回黑暗时代！

Maersk 全球所有设备屏幕上的画面，2017 年 6 月 27 日

灾难临头，你会怎么做？对许多人来说，这会是一次灭顶事件。对我们来说，幸运的是，Maersk 有很多资源可用。

让我大开眼界的是，我们甚至都不是目标。至少对我来说，这是一个巨大的惊喜。我一直认为网络攻击在某种程度上是针对性的。但是现代网络战极为残酷，没有俘虏。因此不要心存幻想，你可能不相信自己正面临很大的风险，但你遭受的灾难甚至可能与你无关。如果你从互联网接收数据（当然是对的），那么最好密切注意所有这些信息。网络攻击以前并不罕见，但是在 COVID-19 时代，私人和国家赞助的网络攻击已大大增加。这是做一些基本的防御行动的最佳时机。也许你很幸运，从未经历过严重的恶意软件攻击，但它们随时都可能来到你面前。攻击者不在乎范围，不在乎容量规划或预算，当然也不在乎你。你需要做好准备！

notPetya 恶意软件很罕见。通常情况下，被恶意软件入侵时，你会看到设备被加密，并带有一条消息要求你支付赎金。很多组织（约 50％）会屈服，让这类攻击更为猖獗。但 notPetya 并非如此，没有人需要付费，它的设计纯粹是要搞破坏，也的确达成了目标。

苦药

在 Maersk，之前没有一致的安全基准。有一些模糊的书面政策，但基本上被忽略了。使用普通生产力帐户在工作站甚至服务器上执行管理任务的行为很常见。服务器管理员拥有对大量系统的长期管理访问权限，即使在我们开始采用云 IaaS 的业务里面管理得更好的部分中也是如此。域管理员不是很多，但它们会被用来在各种设备上执行管理任务。服务帐户通常会被授予本地管理员组成员资格，而不是适当地委派权限。服务帐户也会由多个应用程序共享。这些行为并非 Maersk 所独有，在你自己的组织中也很可能很普遍。这些现象是许多（即使不是大多数）组织仍在承担的风险。

由于 notPetya 已通过财务软件包更新找到了立足点，因此 notPetya 使用常见的凭据传递技术在整个组织中水平扩散，并垂直传播到服务器和域控制器中。由于组织缺乏标准化和一致的特权访问控制机制，使 notPetya 得以轻松击溃 Maersk。

是的，网络分段之类的方法将有助于减缓传播速度。SOC 之类的事情将帮助我们在审判日到来之前看到活动。补丁绝对是有帮助的。但是最终，我们未能解决的基本风险是特权访问的管理机制。

那是不得不咽下的苦药。我一直在组织内宣传的控制机制本可以让 Maersk 免受冲击。但是我敢打赌，并不是只有我对这件事上心了，而且绝对没人对我指手画脚。接下来的几个月，我加入公司以来就一直希望采取的措施都被开了绿灯。真是令人感慨，严重的网络攻击竟然能推动那么多事情。

重新立足

在事件发生后的前几周，一切工作都围绕着恢复 Active Directory 展开。问题是 Active Directory 已在全球范围内跨数百个域控制器部署，可是灾难恢复流程只应对过一个站点或一个数据中心的丢失情况。应急计划中没有任何内容写的是“我们一夜之间就在所有位置失去了一切”。

经过 Maersk、微软和我们合作伙伴的艰苦努力后，我们恢复了目录服务。这涉及一些源代码级别的操作，人们带着各种各样的数据和设备在世界各地飞来飞去。这段经历让我想起了美剧《24 小时》，只是没有紧张的配乐罢了，而且用时显然不止 24 小时！

事件发生后的几个月间，加班已是司空见惯

当第一个域控制器恢复时，它是跑在一部 Surface Pro4 上的。当一切恢复到某种程度的常态时，我们基本上是就把它留在了底座上。

身份验证服务团队齐心协力。来自运营、工程、架构师和经理、合作伙伴和供应商……所有人都在紧密合作。然后，我们分成了几个战术小队，在办公室拐角处用一块巨大的白板隔开来。为了完成任务，我们让人轮班坐在白板旁，对来自业务或其他应用团队的问题或需求进行分类，而让其余团队成员着手处理当前任务。

目录本来应该消失了。我敢肯定，大多数组织都会建立一个全新的目录，但是我们非常幸运，不必一切从头来过。可是所有这些都是要付出代价的。人们在办公室吃饭和睡觉，公司预订了附近每一个酒店房间。人们因为太累而只能打车上班。对于某些人来说，这种情况持续了数周甚至数月。事件不仅影响了一线人员，还影响了职业生涯、家庭、生活。

你们不会想经历同样的灾难的。

做事

在我们恢复服务期间，公司四巨头之一也下来了。高层人员四处奔波，做笔记，参与会议，影响决策。

微软还提供了出色的领导力，帮助我们快速部署了 Privileged Access Workstation（PAW）——特权访问工作站和 Tiered Access Model（TAM）——分层访问模型。这些技术是微软网络安全参考架构（CSRA）的重要功能，组织应对此予以密切关注。而且其成本确实并不是很高。TAM（以及扩展的 PAW）更主要是要建立你缺失的流程，提供清晰度、确定界限和设定期望。你可能还需要少量额外设备来处理访问权限。

这里的投资收益是不可小觑的。你花的那些钱都会有回报，它们可能阻止了类似攻击的发生。

重点在于快速行动。找到正确的人授权他们去做事，出错也可以快速修正。不要浪费漫长的时间讨论快要过时的主题，那样效率太低了。

Windows 10

当时，一项积极的决策是加速 Windows 10 的部署。在遭受攻击时，组织已经完成了创建新的 Windows 10 版本的流程。由于所有工作站都需要重建，自然就用不着回退到 Windows 7 了。所有设备都被仔细检查过，而且所有本地管理员特权实例都消失了。

非常好的是我们在客户端上建立了安全基准。实际上，不再有人会获得永久管理权限，压根就不会拿到这种权限。TAM 正在融入系统。

具有密码哈希同步的 Azure AD 单点登录

还好我们之前迁移到了带有密码哈希同步（PHS）的 Azure AD 单点登录（SSO）上。这意味着人们仍然能够登录 Azure AD 并访问 Office365 等基于云的 SaaS 应用程序！

使用带有 PHS 的 Azure AD SSO，你可以获得：

• 对你的身份状态有更多的保证

• 配置条件访问规则时的更多选项

• 更好的性能

• 更高的可用性

你可能会担心这一阶段的“密码哈希同步”。其实，哈希在任何意义上都是不可逆的，并且你不是将密码存储在云中，不是在同步密码。

恢复正常（计划延迟了）

我们很快就构建了 PAW 和 TAM 的基本骨架。这样一来，当应用程序开始重新进入环境时，我们就可以发出权威的声音了：你需要一级管理员 ID；不，你不应该使用旧的共享服务帐户，等等。麻烦的是这些要求必须是领导层给出的，而有时领导层并不那么重视安全性，他们更想快点恢复业务。这是一场漫长的拉锯战。

2018 年

下图是我们讨论事情进展时常用的一张图：

香肠工厂，改正错误。

香肠工厂

香肠工厂图显示了我们是如何部署 TAM 的，其中包括工作站、服务器和域控制器的典型三层架构。我们将域控制器和 Windows 10 资产内置到 TAM 中，并嵌入所有关联帐户。但是，所有要还原的服务器，以及一些虚拟化 Windows 7 系统仍处于不良状态。

显然，我不会讨论解决方案的细节，也不会讨论其部署方式。但是我确实需要谈一些使我措手不及，并最终导致我离开组织的因素。

PAM 成为一件大事

notPetya 事件发生时，我是 IAM 平台的服务负责人。事件后，高层意识到了“PAM”问题并将其提到了很高的优先级上。组织引入了外部影响力，不幸的是它们还能影响最顶层领导的决策。

计划

任何安全控制都不是孤立存在的。为了解决给定的威胁，需要一种分层的方法。美国国家标准技术研究院（NIST）列出了以下五项原则：

识别∙保护∙检测∙响应∙恢复。

显然，此次攻击对 Active Directory 和加入域的系统影响最大。缺乏一致应用的安全基准和流程是一个很大的漏洞。公平地说，一旦选择并部署了 PAM 产品，我们就会尽快保护域管理员、企业管理员等凭据的密钥。但是就控制而言，光是有工具是不够的，还要知道它们已经用在了哪些地方，知道哪些地方没有用上，并能够对这些情况做出回应，必须确保你已涵盖了这五条原则。

我们要建立良好的状态，然后将系统过渡进来。我们大力发展安全信息和事件管理（SIEM）功能，因此“检测和响应”原则没什么问题。我们在 AD 中配置各种工件（帐户、组、组织单位、组策略），然后将系统移入其中并执行应用程序级配置。最后，支持流程将处理其余的工作。

旧的管理员帐户还是可以访问未迁移到 TAM 中的内容，保留它们纯粹是为了访问尚未修复的“陈旧”系统，然后在不再需要访问时将其删除。

vs 现实

我们四大咨询公司的朋友被催着快点交付。他们有一个在纸面上令人印象深刻的想法——将所有管理帐户都放到 PAM 解决方案中。这是有问题的：

1. 就算将管理帐户注册到 PAM 解决方案中，它们也仍然可以使用大量资产，它们造成重大损害的能力不会消失。另外，由于旧账户数量庞大，这一过程会非常耗时耗力，而且不会有明显的收益。

2. 管理帐户有许多用例。例如，Maersk（Maersk）是一个启用云的组织，其中许多帐户是在本地创建的，但直到它们同步到云后才会供外部开发人员或第三方供应商使用。如果这些人无法访问 PAM 控制台，就没法干活了。

可是这个主意得到了高层认可，反对无济于事。到 2018 年底，我已经无能为力。

2019

2019 年初，我妻子想要来一场旅行，我请假没成，最后决定辞职。我设法在离开前向高层传达我的担忧，想要最后纠正一些事情，只是这些努力最后都失败了。于是，我和家人开始了欧洲之旅。

学到东西

你和你的组织可能也有类的经历。所有类似的攻击事件背后的原因都差不多。任何组织都不应以自己不会成为下一个目标为前提假设。攻击者明天就可能上门，不要让他们轻松得手。管理和保护你的身份和访问权限。

对于领导层来说，不要只看同行或中层管理人员的那些美好的故事。坐下与一线员工交流，倾听他们真实的想法。这将在组织上下建立信任。你需要相信专业人士，而人们则需要相信领导者能够理解并代表他们。

组织对 IT 的重视程度越低，相关人员的话语权就越少。IT 安全措施是培养员工过程的一部分。听取员工的意见来帮助和保护他们，保持公开对话。

关键在于做出决定并采取行动。决策不必一成不变，事情不一定是完美的。这就是行业现在的运作方式。

无论你处于组织的哪个级别，都可以做一些事情来为最坏的情况作准备。

做好基础工作

这可能是全文最重要的部分……

1.少说话，多做事

基础工作很简单。设置规则，按照这些规则构建系统，并逐步迁移或淘汰旧系统。但是不要光说不练，见到火星就应该扑灭它。

2.强制执行 MFA

为所有人启用 MFA 并强制执行，不要亡羊补牢。在 2020 年，它是抵御当今威胁的基本保护措施。那些已有 20 年历史的 Active Directory 密码策略都是自欺欺人。

3.防止人们使用通用密码

Azure AD 密码保护是一种简单的、维护成本较低的方法。它将检测出用户使用公用密码的企图并阻止他们。

强制执行 MFA 并设置了密码保护后，NCSC 和微软现在建议我们不用再要求密码复杂度了。我们可以移除密码过期限制并将密码长度缩短到 8 个字符。

4.以正确的方式进行身份验证

• 启用密码哈希同步。

• 启用 Azure AD SSO，这比使 AD FS 的速度更快。如果 AD 挂掉，云资源将仍然可以访问。

• 启用 Azure AD 设备注册，这不会影响你管理设备的方式，但你会知道设备肯定是加入域的。在启用 Azure AD SSO 之前，请勿执行此操作，否则你将陷入对 AD FS 的依赖。

• 确保拥有一些 Windows Server 2016 或更高版本的域控制器，并将域控制器证书更新为启用了替代旧域证书的域控制器身份验证（Kerberos）模板。如果有系统加入了 Windows 2003 SP2 甚至 XP SP3 之前的域，则需要先删除这些内容，然后再继续操作。对于你的共享设备人员（例如前线工作人员），你会遇到受信任保护模块（TPM）芯片容量限制，所以需要 FIDO2 密钥。对于高级主管和 AD 域管理员或 Azure AD 全局管理员，请考虑将 FIDO2 密钥与生物特征选项结合使用。

• 安排好你的临时帐户流程。

5. 保护这些身份

如果你有预算，请申请 AAD P2 或 M365 E5 许可证。如果登录看起来很奇怪，即使在通常不需要 MFA 的情况下它也会强制执行 MFA。如果凭据被泄漏到了暗网，那么它就会强制重置密码。如果你预算不够，至少要有 compromised creds report，让人每天看一遍报告。但这里的前提是需要启用 Azure AD 密码哈希同步（PHS）。

6.处理好特权访问基准

如果你的管理员习惯于随时访问所有内容，那么现在正是他们改掉坏习惯的时候了。

Windows 的所有版本都有一套称为用户帐户控制的基本策略。你需要在整个组织中一致地使用这些控制策略。至少你应该：

• 确保管理员、服务和应用程序帐户专用于工作站、服务器或域控制器。

• 如果可能，请为这三个类别提供特定类别的管理工作站。至少要有“管理工作站”的概念。

• 确保删除了这些策略中的某些默认条目。

• 确保管理员一次都不具有对所有工作站或所有服务器的管理员访问权限。不要让你的组织机构对任何一个帐户开放。将权限分成较小的组，按需开放。

• 限制对应用程序级别组的访问。不能有“ALL DATACENTRE X”类型组或“ALL SQL SERVER”类型组。

• 限制服务/应用程序帐户。拒绝它们交互式登录。禁止它们进入本地管理员组。使用你的报告系统捕获那些本地管理员组更改事件。

• 通过策略强制本地管理员组。如果你不这样做，并且没有设置规则，你将面临巨大风险。

• 使用LAPS！你的环境中不需要过时的本地管理员密码，LAPS 可以为你料理这些事情。而且，你能轻松控制谁可以访问这些密码。人们使用管理员账户登录时应该有记录，不应该是匿名的。

• 不要同步你最重要的帐户。域管理员没有业务登录到 Azure。控制你的“爆炸区域”。

• 高特权的组要尽量精简。在 Domain 或 Global Admin 级别组中，你只需要少数几个帐户。对于那些 Global Admin 和具有类似功能的 Azure AD 组，我强烈建议 Azure AD Privileged Identity Management 限制对这些角色的访问。是的，它需要 AAD P2 或 M365 E5 许可证，但只有添加这些功能强大的角色的帐户才需要。

要做的工作总是很多的，但我建议你将上述策略作为一个不错的起点。是的，这些听起来很困难，很昂贵，需要很长时间。是的，我们随时都需要访问这访问那。

但失去一切的后果更为严重，将付出更多代价，并且将花费更长时间，让人们的工作和人际关系变得更糟。这些是基础工作，就像锁上前门，或在银行卡上输入 PIN 码一样。不管怎样，更新这些规则，安排好你的流程。在几十年的权限滥用之后，人们已经习惯了无限制地不断访问所有内容。在 2017 年 6 月，Maersk 为此付出了惨痛代价。很多组织依旧在重蹈覆辙，但改变其实是很简单的，只要开始行动就够了。拥有的权限越多，承担的责任也就越重，迟早令人无法承受。

我敢打赌，你的组织并没有什么不同。滥用权限为用户带来了不错的体验，但也对坏人敞开了大门。你的用户和管理员需要了解他们的帐户对组织构成了明显的威胁，并且每个人都需要介入以帮助限制这些威胁。

其他措施

这篇文章专注于身份和访问控制主题。但是安全环境的其他方面也是同样重要的：

• 维护关键业务应用程序列表。当涉及到连续性计划和安全措施时，请优先考虑表上的内容。这并不是说只对关键系统采取措施，对其他系统不闻不问。这里说的是建立一致的基准。关键的东西一旦经过测试，就应该先获得“更好的措施”。

• IT 组织应该把淘汰过时的操作系统当作自己的优先任务，尤其是那些服务于核心业务的系统。这些系统不仅会有严重漏洞，而且很可能使你无法采用其他更现代的功能。

• 不要延迟补丁和更新。安全补丁、AV 定义等——请勿等待，快速部署它们。设置最大增量。任何未打补丁的系统都应考虑采用自动隔离程序。让应用程序负责人负起自己的责任。

• 使用数据。没有数据，就不可能证明问题的严重性，没法做计划。一种糟糕的方法是使用中心化工具来收集数据。应该用去中心化的方法，单独管理各个系统的报告。通过这种方式，你可以将整个环境对特定帐户的影响最小化。

延伸阅读：

微软无密码策略

零信任理念

微软网络安全参考架构

原文链接：

https://gvnshtn.com/maersk-me-notpetya/