全球最大航运企业马士基被黑事件之“痛煞我也”

6月27日，一种类似于“WannaCry”的新型勒索病毒“Petya”席卷欧洲，其网络攻击范围已从俄罗斯和乌克兰，迅速遍及全球。不仅纽约和鹿特丹的港口运营商受到影响，甚至基辅的政府系统也受到干扰，运营因此中断的公司包括俄罗斯石油公司(Rosneft)、乌克兰银行、英国广告公司WPP Plc。全球最大航运企业马士基集团(A.P.Moller-Maersk)也已证实IT系统遭到网络黑客攻陷!

马士基旗下的APM Terminals多个终端遭遇系统问题，包括美国东海岸最大的港口纽约和新泽西港以及欧洲最大的海港荷兰鹿特丹。

马士基在其网站上表示：

1、“由于网络黑客攻击，我们可以确认马士基IT系统在多个站点和业务部门崩溃，我们会继续评估情况。此次攻击很可能是一个全球性的问题。”

2、“我们员工、业务以及客户信息安全是我们的首要任务，如有最新进展我们会持续更新。”

马士基集团在声明中表示，公司的客户目前已无法使用其在线预订工具，且公司的内部系统也已宕机。马士基集团发言人表示，此次网络攻击影响到公司的多个网站和部门，包括港口运营、石油和天然气生产等部门。

鉴于之前网络上铺天盖地的Not-Petya病毒的分析和解说，本文就略过所有这些病毒的技术细节，我们来谈谈作为全球航运业领头羊“马士基”到底是如何大面积感染导致全面业务中断!所谓以史为鉴，以史为镜，通过对本文的剖析，相信大家应该会有更加成熟的运维方案。

先谈外网，马士基作为全球最大航运业公司，信息化基建不可能不成熟，标准的防火墙配置自然存在，先暂且不管他到底是采用哪家防火墙，不管是CheckPoint, Juniper还是PaloAlto防火墙，基本不会开放445端口的，所以在WannaCry时代，“永恒之蓝”的SMB攻击基本无效。

再谈基建，针对之前感染的情况来看，马士基部分服务器应该是基于Windows平台，起码域环境大部分都是Windows平台，针对Windows平台到目前为止，最成熟的系统管理方案莫过于微软的SCCM(Microsoft System Center Configuration Manager)。SCCM2007构建在 SMS 2003 R2的基础之上,为 Microsoft 平台提供了一个针对变化和配置管理的综合的解决方案.SCCM2007使企业能够快速和低成本地为 Microsoft 和非Microsoft 供应商用户提供相关的软件和更新。SCCM前身就是大家耳熟能详的SystemManagementr Server，这是一款非常优秀的桌面管理软件.它可以收集硬件和软件清单，在客户机上发布软件;它可以管理客户机更新，甚至可以拒绝没有及时更新修补程序的客户机访问网络;它还可以在裸机上部属操作系统;远程控制客户机;统计软件的使用次数。。。

Windows客户端基本都被SCCM进行管理，微软的补丁管理自然不会例外，MS17-010补丁就算之前没有推送到全球客户端，但是相信在WannaCry之中甚至之后，马士基怎么都把MS17-010推送并安装到所有或者大部分Windows客户端了。绝不是网上所流传的未打MS17-010补丁的缘故!

那么后面马士基又是如何中招，如何感染全球的呢?

还是先来看看马士基的信息基建工作和IT人员是如何运营的。

前提条件一，相信大部分公司都应该是用RDP来进行远程服务器管理的，总所周知，在服务器上面需要跑各种各样的JOB，各种各样的Service，那么不可避免的出现一种情况，服务器上Administrators管理组里面可能包含了一个或多个本地管理员账号或者是域账号，那么这个域账号可能在域服务器上面仅仅是普通用户权限，但是在本地或者其他服务器上面都是作为本地管理员存在的。此为前提条件一，这个条件是几乎所有公司都存在的模式，除非采用了Privilige Account Management Solution。

前提条件二，尽管越来越多的程序或者系统已经WEB化，但由于微软Windows本身的限制，”Users”组或者”PowerUsers”组是有很多限制条件的，他们无法做到很多额外的工作，比如运行某些特定的应用程序，或者修改某些权限，设置安装微软的补丁，这些都需要依赖于管理员权限，对于一家大型依赖于信息化的企业来说，是不可能像小公司那样赋予所有用户本地管理员权限的，那么势必存在两个方案：方案A，本地管理员即administrator在全球所有用户电脑保持密码一致，方便使用，坏处是密码一旦被人知道，全球密码都需要修改，管理方面非常麻烦;方案B，本地管理员密码不唯一，但是本地管理员组存在一域用户账号，该域用户账号在全球所有用户电脑的管理员组存在，好处显而易见，密码修改容易，管理方便。那么依托于这两种方案任一一种方案的应用程序就可以使用RUNAS的方法临时提升本机权限进行软件，补丁的安装和管理。比如使用LogonScript进行提权自动安装，或者打包生成含管理员密码的exe/msi程序分发给用户进行手动安装，或者提权使用比如本地一些需要高权限的应用程序。(不是有SCCM吗?为什么还要手动做?这是因为SCCM的推送几乎没有可能保证100%的成功率)

那么依托于上述两个条件，我们可以浪费一些文字来重新介绍Mimikatz

Mimikatz是一款能够从Windows认证(LSASS)的进程中获取内存，并且获取明文密码和NTLM哈希值的工具，攻击者可以借此漫游内网。在这里，就不再为Mimikatz做过多的介绍，BUF中间的相关文章已经太多太多，相应的防御手段也巴拉巴拉说了一大堆的，但是，说再多也没用，为啥?这个问题或者这个漏洞目前是无解的!!!所有文章中提到的都是通过安装补丁和限制Wdigest明文密码保存，但是!忽略了Mimikatz可以偷取SSP和Credman的明文密码，用通俗的话来说就是Mimikatz可以获取到计划任务中保存的密码，可以获取到用户网络盘映射密码，可以偷取到应用程序背后加载的服务项密码，可以偷取到RDP密码。。。而这，所有Windows版本均有效!

重头戏来了，当一台普通用户机因点击钓鱼邮件或者其他原因而中招，Not-Petya感染该机后，使用Mimikatz获取到本机运行过的管理员密码，不管是上述文章中的方案一还是方案二，即拥有了使用WMIC远程控制目标机器的能力，接下来Not-Petya使用该权限传播到一台IT人员的电脑，而该IT人员或许很久之前使用过RDP登录过服务器，或者有用MMC，不管什么，Not-Petya都在该IT人员的内存中获取到了一个服务器有效密码;接下来，Not-Petya传播进入服务器，服务器上一般有跑多个任务，比如备份作业，比如计划任务，比如后台服务，甚至有域管理员登录过，那么该应用或者Session使用过的服务器上的密码被Not-Petya获取到后，开始感染其他有权限登录的服务器，最后获取到域管理员密码，从而感染AD服务器，数据库服务器，后果就是整个公司的网络环境崩溃。

整整7天，或者说到7天后，马士基才开始恢复一部分业务，桌面电脑要重装，服务器要重装，数据要恢复，BCP计划受损。这是马士基整个IT的崩溃。由此可见，说再多的攻防技术也抵不过运维的重要性，堡垒往往都是从内部攻破的!一个成熟的，富有经验的运维管理层是必不可少的!

编者注： 本文是根据网络资源对马士基事件进行的猜测还原，如有雷同，纯属虚构。