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

Maersk（馬士基）是全球最大的航運和集裝箱物流綜合公司。我非常榮幸地成為了他們的身份控制和訪問管理（IAM）主題專家（SME），以及后來的 IAM 服務負責人。2017 年，我和公司其他幾十人一起應對了廣為人知的 notPetya 惡意軟件攻擊事件。

這篇文章的目的是分享一些我們的經驗和教訓，以便給后來者參考。攻擊是遲早會發(fā)生的，誠然我們有很多先進的裝備，但很多組織從一開始就做錯了。

這個故事涉及 2015 年到 2019 年我在 Maersk 的經歷，其中包括 notPetya 事件和恢復工作，以及我最后離開前加入控制和保護措施的事情。

我從 2015 年初開始在 Maersk 工作。Maersk 歷史悠久，他們的 IT 部門有一點很有趣，就是他們在整個集團中交付 IT 服務的方式。當時，這個組織分散為服務于不同部門（物流、能源、運輸）的多個業(yè)務部門。以前，每個業(yè)務部門都有自己的 IT。但由于 Maersk 航運公司（運輸業(yè)務）是其中最大的，其 IT 部門自然也最為強大，并已開始向其他業(yè)務部門提供一些共享的 IT 服務。

在經過數(shù)年的政治和權力斗爭后，Maersk 的能源業(yè)務被出售，公司將資源集中在運輸和物流上。與此同時，IT 也逐漸集中化，組織的最高層建立了數(shù)字和云優(yōu)先戰(zhàn)略。

一開始，我參與了一個項目。公司彼時在通過一個著名的身份和訪問管理（IAM）產品將共享的 HR 系統(tǒng)插入 Active Directory，這款產品有一些向導式自定義 Web 服務和數(shù)據庫后端服務來方便集成。項目的參與者包括英國和丹麥的同事，橫跨 IT、HR 等業(yè)務部門，IAM 技術要素則由微軟提供支持。這個項目持續(xù)到 2015 年底，走過了一場艱辛的旅程。我們的資源有限，但在所有人的努力下解決方案的進展很快。

Maersk 有著令人自豪的歷史，它成績斐然，是很好的工作場所，而這個項目讓我感受到了家的溫暖。上線任務是在幾個周末內完成的，我們花了幾個小時進行了一些真正的冒險，包括在凌晨 3 點以物理方式“闖入”存在問題的舊服務器！最終，解決方案成功上線，在大約六萬活躍用戶中，我們只錯誤地刪除了一個帳戶。好樣的！

IAM 項目的成功幫我在第一年的績效評估中獲得了最高分，我還參加了微軟 Ignite 大會，給履歷表又添了漂亮的一筆。

我在 Maersk 的工作主要是（現(xiàn)在稱為）身份驗證和安全項目：身份管理、特權訪問管理、智能卡登錄系統(tǒng)等。IAM 系統(tǒng)現(xiàn)在可以處理典型的就職、調職和離職流程，那么我的下一個任務就是特權訪問管理。在上一個項目中，我發(fā)現(xiàn)舊架構普遍不遵循最小特權原則。航運是一項龐大的業(yè)務，但利潤相對較低。那時，IT 一直被視作成本中心而非業(yè)務推動者。安全控制的優(yōu)先權被高層排在了后面。我們的舊架構有多種安全部門，沒有明確的主管，并且資金有限。

那時，我們本可以并且應該一直在應用一致的安全策略來控制帳戶和訪問的。你可以逐步推進變革。你也可以應用新標準并為它構建服務，然后隨著時間的推移升級更多服務，最后你的舊系統(tǒng)要么煥然一新，要么死掉。你獲得的預算越多，流程就越快。一些控制策略的典型例子包括：

• 服務帳戶不應在多個應用程序中使用；

• 最終用戶生產力帳戶不應在任何位置具有管理員權限；

• 服務器管理員帳戶在工作站上不應具有管理員權限。

列表很長，但這只是基本的 Microsoft 安全基準或分層訪問模型的內容。在此期間，我們的 MSP 試圖推銷一款特權訪問管理（PAM）產品，以對用于訪問我們 MSP 托管系統(tǒng)的 MSP 憑據進行憑據循環(huán)控制；一直以來，我們都在所有 Maersk MSP 托管的服務器上，將一個充滿所有 Maersk 和 MSP 成員的活動目錄（AD）組放入本地管理員組。這還不夠。除了訪問風險（不考慮憑據），那些非 MSP 托管包該怎么辦？因此，我也在同時推動 IAM 解決方案的 PAM 組件作為替代方案。

我一廂情愿地認為公司應該用上一些行業(yè)水平的東西，但敗在了成本管理政策下，畢竟我的后兜里沒有幾百萬美元！

當我在特權訪問項目上四處碰壁時，我們也在同時做其他事情。我們將運營團隊移交給新的供應商；Maersk 收購 Hamburg Sud 時，我們參與了一些有趣的合并活動；郵件自動化正在進行中……生活很美好。

在遙遠的土地上，俄羅斯黑客一直在攻擊烏克蘭。在烏克蘭運營的所有企業(yè)通常都使用某款財務應用程序。攻擊者已經黑掉了應用程序的供應商，并將 notPetya 惡意軟件注入到它的軟件更新中。盡職盡責的財務人員在不知不覺中開門放進了一款破壞力極大的惡意軟件。

在 2017 年 6 月 27 日，問題突然爆發(fā)！

大約上午 10 點，我們正在一個玻璃墻會議室開會。外面的人開始躁動起來，可能發(fā)生了一些小故障。然后，一些憤怒的人走進來把我們揪出去做事，我們才意識到：辦公室里的一些工作站似乎掛掉了。不，不僅僅是我們的辦公室。在全球范圍內，所有設備正在逐漸完蛋。服務器呢？域控制器不見了？天哪……幾個小時內，我們就損失慘重。這影響了地球上每臺加入域的 Windows 筆記本電腦、臺式機、虛擬機和物理服務器。

這家組織剛剛被送回黑暗時代！

Maersk 全球所有設備屏幕上的畫面，2017 年 6 月 27 日

災難臨頭，你會怎么做？對許多人來說，這會是一次滅頂事件。對我們來說，幸運的是，Maersk 有很多資源可用。

讓我大開眼界的是，我們甚至都不是目標。至少對我來說，這是一個巨大的驚喜。我一直認為網絡攻擊在某種程度上是針對性的。但是現(xiàn)代網絡戰(zhàn)極為殘酷，沒有俘虜。因此不要心存幻想，你可能不相信自己正面臨很大的風險，但你遭受的災難甚至可能與你無關。如果你從互聯(lián)網接收數(shù)據（當然是對的），那么最好密切注意所有這些信息。網絡攻擊以前并不罕見，但是在 COVID-19 時代，私人和國家贊助的網絡攻擊已大大增加。這是做一些基本的防御行動的最佳時機。也許你很幸運，從未經歷過嚴重的惡意軟件攻擊，但它們隨時都可能來到你面前。攻擊者不在乎范圍，不在乎容量規(guī)劃或預算，當然也不在乎你。你需要做好準備！

notPetya 惡意軟件很罕見。通常情況下，被惡意軟件入侵時，你會看到設備被加密，并帶有一條消息要求你支付贖金。很多組織（約 50％）會屈服，讓這類攻擊更為猖獗。但 notPetya 并非如此，沒有人需要付費，它的設計純粹是要搞破壞，也的確達成了目標。

在 Maersk，之前沒有一致的安全基準。有一些模糊的書面政策，但基本上被忽略了。使用普通生產力帳戶在工作站甚至服務器上執(zhí)行管理任務的行為很常見。服務器管理員擁有對大量系統(tǒng)的長期管理訪問權限，即使在我們開始采用云 IaaS 的業(yè)務里面管理得更好的部分中也是如此。域管理員不是很多，但它們會被用來在各種設備上執(zhí)行管理任務。服務帳戶通常會被授予本地管理員組成員資格，而不是適當?shù)匚蓹嘞蕖７諑粢矔啥鄠€應用程序共享。這些行為并非 Maersk 所獨有，在你自己的組織中也很可能很普遍。這些現(xiàn)象是許多（即使不是大多數(shù)）組織仍在承擔的風險。

由于 notPetya 已通過財務軟件包更新找到了立足點，因此 notPetya 使用常見的憑據傳遞技術在整個組織中水平擴散，并垂直傳播到服務器和域控制器中。由于組織缺乏標準化和一致的特權訪問控制機制，使 notPetya 得以輕松擊潰 Maersk。

是的，網絡分段之類的方法將有助于減緩傳播速度。SOC 之類的事情將幫助我們在審判日到來之前看到活動。補丁絕對是有幫助的。但是最終，我們未能解決的基本風險是特權訪問的管理機制。

那是不得不咽下的苦藥。我一直在組織內宣傳的控制機制本可以讓 Maersk 免受沖擊。但是我敢打賭，并不是只有我對這件事上心了，而且絕對沒人對我指手畫腳。接下來的幾個月，我加入公司以來就一直希望采取的措施都被開了綠燈。真是令人感慨，嚴重的網絡攻擊竟然能推動那么多事情。

在事件發(fā)生后的前幾周，一切工作都圍繞著恢復 Active Directory 展開。問題是 Active Directory 已在全球范圍內跨數(shù)百個域控制器部署，可是災難恢復流程只應對過一個站點或一個數(shù)據中心的丟失情況。應急計劃中沒有任何內容寫的是“我們一夜之間就在所有位置失去了一切”。

經過 Maersk、微軟和我們合作伙伴的艱苦努力后，我們恢復了目錄服務。這涉及一些源代碼級別的操作，人們帶著各種各樣的數(shù)據和設備在世界各地飛來飛去。這段經歷讓我想起了美劇《24 小時》，只是沒有緊張的配樂罷了，而且用時顯然不止 24 小時！

事件發(fā)生后的幾個月間，加班已是司空見慣

當?shù)谝粋€域控制器恢復時，它是跑在一部 Surface Pro4 上的。當一切恢復到某種程度的常態(tài)時，我們基本上是就把它留在了底座上。

身份驗證服務團隊齊心協(xié)力。來自運營、工程、架構師和經理、合作伙伴和供應商……所有人都在緊密合作。然后，我們分成了幾個戰(zhàn)術小隊，在辦公室拐角處用一塊巨大的白板隔開來。為了完成任務，我們讓人輪班坐在白板旁，對來自業(yè)務或其他應用團隊的問題或需求進行分類，而讓其余團隊成員著手處理當前任務。

目錄本來應該消失了。我敢肯定，大多數(shù)組織都會建立一個全新的目錄，但是我們非常幸運，不必一切從頭來過?？墒撬羞@些都是要付出代價的。人們在辦公室吃飯和睡覺，公司預訂了附近每一個酒店房間。人們因為太累而只能打車上班。對于某些人來說，這種情況持續(xù)了數(shù)周甚至數(shù)月。事件不僅影響了一線人員，還影響了職業(yè)生涯、家庭、生活。

你們不會想經歷同樣的災難的。

在我們恢復服務期間，公司四巨頭之一也下來了。高層人員四處奔波，做筆記，參與會議，影響決策。

微軟還提供了出色的領導力，幫助我們快速部署了 Privileged Access Workstation（PAW）——特權訪問工作站和 Tiered Access Model（TAM）——分層訪問模型。這些技術是微軟網絡安全參考架構（CSRA）的重要功能，組織應對此予以密切關注。而且其成本確實并不是很高。TAM（以及擴展的 PAW）更主要是要建立你缺失的流程，提供清晰度、確定界限和設定期望。你可能還需要少量額外設備來處理訪問權限。

這里的投資收益是不可小覷的。你花的那些錢都會有回報，它們可能阻止了類似攻擊的發(fā)生。

重點在于快速行動。找到正確的人授權他們去做事，出錯也可以快速修正。不要浪費漫長的時間討論快要過時的主題，那樣效率太低了。

當時，一項積極的決策是加速 Windows 10 的部署。在遭受攻擊時，組織已經完成了創(chuàng)建新的 Windows 10 版本的流程。由于所有工作站都需要重建，自然就用不著回退到 Windows 7 了。所有設備都被仔細檢查過，而且所有本地管理員特權實例都消失了。

非常好的是我們在客戶端上建立了安全基準。實際上，不再有人會獲得永久管理權限，壓根就不會拿到這種權限。TAM 正在融入系統(tǒng)。

還好我們之前遷移到了帶有密碼哈希同步（PHS）的 Azure AD 單點登錄（SSO）上。這意味著人們仍然能夠登錄 Azure AD 并訪問 Office365 等基于云的 SaaS 應用程序！

使用帶有 PHS 的 Azure AD SSO，你可以獲得：

• 對你的身份狀態(tài)有更多的保證；

• 配置條件訪問規(guī)則時的更多選項；

• 更好的性能；

• 更高的可用性。

你可能會擔心這一階段的“密碼哈希同步”。其實，哈希在任何意義上都是不可逆的，并且你不是將密碼存儲在云中，不是在同步密碼。

我們很快就構建了 PAW 和 TAM 的基本骨架。這樣一來，當應用程序開始重新進入環(huán)境時，我們就可以發(fā)出權威的聲音了：你需要一級管理員 ID；不，你不應該使用舊的共享服務帳戶，等等。麻煩的是這些要求必須是領導層給出的，而有時領導層并不那么重視安全性，他們更想快點恢復業(yè)務。這是一場漫長的拉鋸戰(zhàn)。

下圖是我們討論事情進展時常用的一張圖：

香腸工廠，改正錯誤

香腸工廠圖顯示了我們是如何部署 TAM 的，其中包括工作站、服務器和域控制器的典型三層架構。我們將域控制器和 Windows 10 資產內置到 TAM 中，并嵌入所有關聯(lián)帳戶。但是，所有要還原的服務器，以及一些虛擬化 Windows 7 系統(tǒng)仍處于不良狀態(tài)。

顯然，我不會討論解決方案的細節(jié)，也不會討論其部署方式。但是我確實需要談一些使我措手不及，并最終導致我離開組織的因素。

notPetya 事件發(fā)生時，我是 IAM 平臺的服務負責人。事件后，高層意識到了“PAM”問題并將其提到了很高的優(yōu)先級上。組織引入了外部影響力，不幸的是它們還能影響最頂層領導的決策。

任何安全控制都不是孤立存在的。為了解決給定的威脅，需要一種分層的方法。美國國家標準技術研究院（NIST）列出了以下五項原則：

識別?保護?檢測?響應?恢復。

顯然，此次攻擊對 Active Directory 和加入域的系統(tǒng)影響最大。缺乏一致應用的安全基準和流程是一個很大的漏洞。公平地說，一旦選擇并部署了 PAM 產品，我們就會盡快保護域管理員、企業(yè)管理員等憑據的密鑰。但是就控制而言，光是有工具是不夠的，還要知道它們已經用在了哪些地方，知道哪些地方沒有用上，并能夠對這些情況做出回應，必須確保你已涵蓋了這五條原則。

我們要建立良好的狀態(tài)，然后將系統(tǒng)過渡進來。我們大力發(fā)展安全信息和事件管理（SIEM）功能，因此“檢測和響應”原則沒什么問題。我們在 AD 中配置各種工件（帳戶、組、組織單位、組策略），然后將系統(tǒng)移入其中并執(zhí)行應用程序級配置。最后，支持流程將處理其余的工作。

舊的管理員帳戶還是可以訪問未遷移到 TAM 中的內容，保留它們純粹是為了訪問尚未修復的“陳舊”系統(tǒng)，然后在不再需要訪問時將其刪除。

我們四大咨詢公司的朋友被催著快點交付。他們有一個在紙面上令人印象深刻的想法——將所有管理帳戶都放到 PAM 解決方案中。這是有問題的：

• 就算將管理帳戶注冊到 PAM 解決方案中，它們也仍然可以使用大量資產，它們造成重大損害的能力不會消失。另外，由于舊賬戶數(shù)量龐大，這一過程會非常耗時耗力，而且不會有明顯的收益。

• 管理帳戶有許多用例。例如，Maersk（Maersk）是一個啟用云的組織，其中許多帳戶是在本地創(chuàng)建的，但直到它們同步到云后才會供外部開發(fā)人員或第三方供應商使用。如果這些人無法訪問 PAM 控制臺，就沒法干活了。

可是這個主意得到了高層認可，反對無濟于事。到 2018 年底，我已經無能為力。2019 年初，我妻子想要來一場旅行，我請假沒成，最后決定辭職。我設法在離開前向高層傳達我的擔憂，想要最后糾正一些事情，只是這些努力最后都失敗了。于是，我和家人開始了歐洲之旅。

你和你的組織可能也有類的經歷。所有類似的攻擊事件背后的原因都差不多。任何組織都不應以自己不會成為下一個目標為前提假設。攻擊者明天就可能上門，不要讓他們輕松得手。管理和保護你的身份和訪問權限。

對于領導層來說，不要只看同行或中層管理人員的那些美好的故事。坐下與一線員工交流，傾聽他們真實的想法。這將在組織上下建立信任。你需要相信專業(yè)人士，而人們則需要相信領導者能夠理解并代表他們。

組織對 IT 的重視程度越低，相關人員的話語權就越少。IT 安全措施是培養(yǎng)員工過程的一部分。聽取員工的意見來幫助和保護他們，保持公開對話。

關鍵在于做出決定并采取行動。決策不必一成不變，事情不一定是完美的。這就是行業(yè)現(xiàn)在的運作方式。

無論你處于組織的哪個級別，都可以做一些事情來為最壞的情況作準備。

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

基礎工作很簡單。設置規(guī)則，按照這些規(guī)則構建系統(tǒng)，并逐步遷移或淘汰舊系統(tǒng)。但是不要光說不練，見到火星就應該撲滅它。

為所有人啟用 MFA 并強制執(zhí)行，不要亡羊補牢。在 2020 年，它是抵御當今威脅的基本保護措施。那些已有 20 年歷史的 Active Directory 密碼策略都是自欺欺人。

Azure AD 密碼保護是一種簡單的、維護成本較低的方法。它將檢測出用戶使用公用密碼的企圖并阻止他們。

強制執(zhí)行 MFA 并設置了密碼保護后，NCSC 和微軟現(xiàn)在建議我們不用再要求密碼復雜度了。我們可以移除密碼過期限制并將密碼長度縮短到 8 個字符。

• 啟用密碼哈希同步。

• 啟用 Azure AD SSO，這比使 AD FS 的速度更快。如果 AD 掛掉，云資源將仍然可以訪問。

• 啟用 Azure AD 設備注冊，這不會影響你管理設備的方式，但你會知道設備肯定是加入域的。在啟用 Azure AD SSO 之前，請勿執(zhí)行此操作，否則你將陷入對 AD FS 的依賴。

• 確保擁有一些 Windows Server 2016 或更高版本的域控制器，并將域控制器證書更新為啟用了替代舊域證書的域控制器身份驗證（Kerberos）模板。如果有系統(tǒng)加入了 Windows 2003 SP2 甚至 XP SP3 之前的域，則需要先刪除這些內容，然后再繼續(xù)操作。對于你的共享設備人員（例如前線工作人員），你會遇到受信任保護模塊（TPM）芯片容量限制，所以需要 FIDO2 密鑰。對于高級主管和 AD 域管理員或 Azure AD 全局管理員，請考慮將 FIDO2 密鑰與生物特征選項結合使用。

• 安排好你的臨時帳戶流程。

如果你有預算，請申請 AAD P2 或 M365 E5 許可證。如果登錄看起來很奇怪，即使在通常不需要 MFA 的情況下它也會強制執(zhí)行 MFA。如果憑據被泄漏到了暗網，那么它就會強制重置密碼。如果你預算不夠，至少要有 compromised creds report，讓人每天看一遍報告。但這里的前提是需要啟用 Azure AD 密碼哈希同步（PHS）。

如果你的管理員習慣于隨時訪問所有內容，那么現(xiàn)在正是他們改掉壞習慣的時候了。

Windows 的所有版本都有一套稱為用戶帳戶控制的基本策略。你需要在整個組織中一致地使用這些控制策略。至少你應該：

• 確保管理員、服務和應用程序帳戶專用于工作站、服務器或域控制器。

• 如果可能，請為這三個類別提供特定類別的管理工作站。至少要有“管理工作站”的概念。

• 確保刪除了這些策略中的某些默認條目。

• 確保管理員一次都不具有對所有工作站或所有服務器的管理員訪問權限。不要讓你的組織機構對任何一個帳戶開放。將權限分成較小的組，按需開放。

• 限制對應用程序級別組的訪問。不能有“ALL DATACENTRE X”類型組或“ALL SQL SERVER”類型組。

• 限制服務 / 應用程序帳戶。拒絕它們交互式登錄。禁止它們進入本地管理員組。使用你的報告系統(tǒng)捕獲那些本地管理員組更改事件。

• 通過策略強制本地管理員組。如果你不這樣做，并且沒有設置規(guī)則，你將面臨巨大風險。

• 使用 LAPS！你的環(huán)境中不需要過時的本地管理員密碼，LAPS 可以為你料理這些事情。而且，你能輕松控制誰可以訪問這些密碼。人們使用管理員賬戶登錄時應該有記錄，不應該是匿名的。

• 不要同步你最重要的帳戶。域管理員沒有業(yè)務登錄到 Azure。控制你的“爆炸區(qū)域”。

• 高特權的組要盡量精簡。在 Domain 或 Global Admin 級別組中，你只需要少數(shù)幾個帳戶。對于那些 Global Admin 和具有類似功能的 Azure AD 組，我強烈建議 Azure AD Privileged Identity Management 限制對這些角色的訪問。是的，它需要 AAD P2 或 M365 E5 許可證，但只有添加這些功能強大的角色的帳戶才需要。

要做的工作總是很多的，但我建議你將上述策略作為一個不錯的起點。是的，這些聽起來很困難，很昂貴，需要很長時間。是的，我們隨時都需要訪問這訪問那。

但失去一切的后果更為嚴重，將付出更多代價，并且將花費更長時間，讓人們的工作和人際關系變得更糟。這些是基礎工作，就像鎖上前門，或在銀行卡上輸入 PIN 碼一樣。不管怎樣，更新這些規(guī)則，安排好你的流程。在幾十年的權限濫用之后，人們已經習慣了無限制地不斷訪問所有內容。在 2017 年 6 月，Maersk 為此付出了慘痛代價。很多組織依舊在重蹈覆轍，但改變其實是很簡單的，只要開始行動就夠了。擁有的權限越多，承擔的責任也就越重，遲早令人無法承受。

我敢打賭，你的組織并沒有什么不同。濫用權限為用戶帶來了不錯的體驗，但也對壞人敞開了大門。你的用戶和管理員需要了解他們的帳戶對組織構成了明顯的威脅，并且每個人都需要介入以幫助限制這些威脅。

這篇文章專注于身份和訪問控制主題。但是安全環(huán)境的其他方面也是同樣重要的：

• 維護關鍵業(yè)務應用程序列表。當涉及到連續(xù)性計劃和安全措施時，請優(yōu)先考慮表上的內容。這并不是說只對關鍵系統(tǒng)采取措施，對其他系統(tǒng)不聞不問。這里說的是建立一致的基準。關鍵的東西一旦經過測試，就應該先獲得“更好的措施”。

• IT 組織應該把淘汰過時的操作系統(tǒng)當作自己的優(yōu)先任務，尤其是那些服務于核心業(yè)務的系統(tǒng)。這些系統(tǒng)不僅會有嚴重漏洞，而且很可能使你無法采用其他更現(xiàn)代的功能。

• 不要延遲補丁和更新。安全補丁、AV 定義等——請勿等待，快速部署它們。設置最大增量。任何未打補丁的系統(tǒng)都應考慮采用自動隔離程序。讓應用程序負責人負起自己的責任。

• 使用數(shù)據。沒有數(shù)據，就不可能證明問題的嚴重性，沒法做計劃。一種糟糕的方法是使用中心化工具來收集數(shù)據。應該用去中心化的方法，單獨管理各個系統(tǒng)的報告。通過這種方式，你可以將整個環(huán)境對特定帳戶的影響最小化。

原文鏈接：

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