一、背景

近日,我们实验室接到国内某大型炼钢厂的应急求救，据其描述其内网高炉车间主机于2019年1月8日开始出现蓝屏和一分钟倒计时重启两种现象，烧炉车间主机于2月14日也开始出现蓝屏和倒计时重启，在发生现象以后其有自行安装过杀毒软件进行扫描杀毒,但是问题还是时有发生,于是通过渠道联系到我们,希望得到彻底的定位与解决。

在接到通知后，粗略了解事件原委之后，我们内部应急响应小组立即就现场支持召开会议进行讨论,然后确定由我和另一名成员前往进行现场支持。根据我们之前的现场应急经验，我们怀疑这有可能是内网中了勒索蠕虫，蠕虫发动内网攻击导致，我们随即准备了内部勒索专杀工具以及应急响应专用U盘(含一键取证脚本)连夜赶往该炼钢厂。

二、取证与定位分析

第二日早晨我们来到炼钢厂高炉中控室,首先与负责人进行交流,再次确认现象，然后在他们的允许下对发生问题的几台备用的机器进行信息取证(在不影响生产的前提进行应急响应)，基于异常现象为导向,我们主要针对主机和网络两个层面进行取证，主机层面主要从windows日志、系统信息、进程、服务、蓝屏dump等关键地方入手;网络层面主要抓取内网流量包，通过主机信息分析，我们发现当前主机中一可疑进程 mssecsvc.exe和可疑服务mssecsvc2.0,根据我们的分析经验以及威胁情报,我们很快断定该主机感染了Wannacry勒索蠕虫(mssecsvc.exe是Wannacry勒索母体),在系统目录下我们也发现该勒索母体、勒索模块tasksche.exe以及勒索模块的副本qeriuwjhrf:

通过流量包能看出此感染主机正不断对内网和外网随机IP发送漏洞利用攻击包:

那么问题来了,既然已经感染了Wannacry为什么磁盘文件没有被加密?

继续分析,我们在日志中发现勒索模块tasksche.exe启动失败的信息:

经过分析我们发现,与之前的Wannacry样本对比，该样本是被修改过的，其资源节中的勒索程序打包存在错误，导致勒索程序不能正常有效运行,因此炼钢厂“幸运”地逃过真正的勒索,避免了巨大的损失:

我们都知道Wannacry勒索蠕虫利用的是“永恒之蓝”MS17-010漏洞，其会通过445端口向目标机器SMB服务器发送漏洞攻击包，对srv.sy驱动进行堆溢出，一旦利用失败便会导致驱动崩溃，造成蓝屏,通过蓝屏dump我们也确认了这一点:

而对于倒计时重启主要是因为当漏洞利用成功后,将执行shellcode并通过APC将攻击载荷注入到系统关键进程lsass.exe，企图实现无文件攻击，但一旦注入失败，便会导致lsass.exe进程崩溃，弹出一分钟倒计时重启的提示框。为了便于读者理解，我们绘制了如下流程图:

如上图所示，在整个攻击过程中，只有漏洞利用和进程注入均执行成功，才不会引起蓝屏或重启现象，进而释放勒索模块tasksche.exe,而该模块又是“无效的”,所以就不会表现出任何明显的现象，这也解释了为什么内网有的机器出现过现象、有的机器没有出现过现象，没有出现过现象不代表没有问题，恰恰是Wannacry攻击成功了，这个从日志、系统进程与服务以及相关特征文件上可以得到确认。

随后我们对发生过蓝屏和倒计时重启的主机所在的两个车间(高炉和烧炉)进行了全面排查与取证，在排查的过程中我们通过实例向负责人解释了“同样的系统配置为什么有的机器从没有发生过蓝屏重启”的疑问，最后我们确认了高炉车间网络于2019年1月8日凌晨3点多开始感染该勒索病毒,烧炉车间网络于2019年2月7日下午3点多开始感染，二者网段不通，由于windows日志记录时长较短，加之内网没有部署任何审计或防护软件，对于溯源到初始入侵向量比较困难,据负责人介绍整个炼钢厂内网与外网完全隔绝,我们推测可能是有操作人员有意或无意通过u盘等可移动存储器进行拷贝文件安装运行导致染毒，感染内网。

另外在全面排查与取证的过程中，我们发现客户有几台主机部署了某国内安全厂商的工业控制安全软件,在询问客户关于该工业安全软件的时候，客户问起:“你看，我们这几台机器部署了他们的工业安全软件，为什么还发生蓝屏与重启呀，是不是没防住?” 我们笑着告诉客户:“哈哈，的确是没防住，不是这不是它无能，而是漏洞利用超出了他防御的范围，该安全软件主要基于进程白名单的思想进行防御，防止白名单外的进程执行，区别于传统杀软的黑名单思想,然而该病毒在漏洞利用攻击过程中是没有进程产生的，其通过执行内存shellcode进行无文件攻击,所以其实漏洞利用和进程注入2个动作对它来说都是透明的，但是到后面释放勒索模块并执行的时候它就起作用了，你看，它的日志里这不是记录着进程拦截信息嘛” 客户听了，挠了挠头略带疑问的说:”那到底该怎么在内网防范这种病毒攻击呀”，我们回答道:“这种勒索蠕虫的强大之处在于它的网络传播模块也就是蠕虫模块，其会利用漏洞迅速地在内网和外网中传播，并且漏洞利用攻击包一般杀软难以检测到，需要部署专业网络层的防护，比如防火墙/审计、IDS/IPS等，然后再结合主机层的工业安全软件等进行组合拳式的立体防护。” 客户听后,点头表示明白了。随后客户又提起一事:“对了,我们在试用他们这工业安全软件的时候发现也有出现过蓝屏，是在系统启动的过程蓝屏的,您看看是否有时间也帮我们分析一下?” 我们连忙回道:”好，咱们先解决问题，这个回头我们帮你分析一下哈”; 客户露出了满意的表情J

综上,经过我们的全面排查与取证分析，我们得出这样的结论:高炉车间和烧炉车间网络均已在不同时间点感染该变种Wannacry勒索蠕虫，并且在内网不断对外发送漏洞攻击包进行内网感染，现象主要是蓝屏和倒计时重启。

在取证与定位分析结束以后,我们向对方负责人进行汇报,经讨论一致,准备进入下一阶段:清除与恢复。

三、清除与恢复

在该阶段,我们主要是针对内网中的可操作的主机一台一台地进行“断网隔离+手工杀毒+补丁免疫+重启恢复”，原则是不影响生产且不安装额外软件等,很快便对车间内所有可操作的主机完成了病毒清除与生产恢复,随后我们给了客户一个内部病毒自动查杀与免疫工具,交待客户在其空闲的时候对其他没有处理的主机进行清除与恢复并反馈给我们结果,客户反馈结果良好。

四、蓝屏风波又起？某工业安全卫士惹的祸！

就在前几天炼钢厂负责人又联系我们说,我们处理过的某台机器在系统重启后登陆桌面的过程中又发生了蓝屏，而且这台机器装有某厂工业安全软件, 跟客户要来蓝屏dump后我们立即联合之前的dump进行综合分析,通过对之前客户反馈的启动过程中发生的蓝屏dump进行分析,我们发现其确实是由机器上安装的某工业安全卫士的驱动AntiTP.sys引发:

32位机器:

然后再对客户刚发过来的登陆桌面过程产生的蓝屏dump进行分析,发现栈回溯、错误代码等与之前的一致：

客户一开始怀疑是不是病毒没有处理干净或者又有新的病毒,我们赶紧回复：“没有,病毒已经清除了,这次蓝屏是由你们安装的那个工业安全卫士的一个驱动导致的，而且之前你提到的启动过程发生的蓝屏均是由它导致的!”，客户感叹道:“这软件有bug啊,得赶紧告诉他们开发加班修改！”

五、驱动蓝屏根源探索

为了搞清楚驱动为何频频导致蓝屏，我们决定一探究竟，Windbg载入蓝屏dump如下:

可以看到栈回溯显示的调用路径跟之前的dump都是一致,都是在内核态字符串转换函数RtlUnicodeStringToAnsiString的内部调用路线中发生崩溃的，而且BugCheck分析提示我们当前函数的调用者所处的中断优先级(IRQL)太高，2是DISPATCH_LEVEL.查看MSDN中关于RtlUnicodeStringToAnsiString函数的说明我们可以看到微软指明该函数需要在PASSIVE(0)中断级别下进行使用:

然后从栈回溯我们看到最后一次调用的是nt!KiTrap0E，这是windows内核中的缺页异常处理函数,也就是说发生了缺页中断,为什么会发生缺页中断？因为驱动的想要访问的代码数据页不在真实内存(非分页内存)中，需要从虚拟内存(分页内存)中换出，故会触发缺页中断,然后我们看到堆栈回溯显示，RtlUnicodeStringToAnsiString内部调用了内核态内存分配函数ExAllocatePoolWithTag:

PVOID ExAllocatePoolWithTag(

__drv_strictTypeMatch(__drv_typeExpr)POOL_TYPE PoolType,

SIZE_T NumberOfBytes,

ULONG Tag

);

而且其PoolType参数为1 即分页内存PagedPool:

我们又发现MSDN中特别强调ExAllocatePoolWithTag的调用者如果处于DISPATCH_LEVELA(2)的中断级别的时候只能使用非分页内存，只有中断级别小于DISPATCH_LEVEL(或<=APC_LEVEL(1))的时候才可使用任意Pool Type:

然而dump给我们的信息是驱动在调用ExAllocatePoolWithTag的时候处于DISPATCH中断级别,而且使用的是分页内存..这不是无视微软权威嘛..为了更一步确认驱动代码逻辑,我们开始通过windbg + IDA对AntiTP.sys进行逆向,通过IDA代码交叉引用很快能定位到字符串匹配函数StringMatchW(),该函数主要是将当前进程和白名单中进程的Unicode路径字符串转换成Ansi字符串,然后再进行比较,来到StringMathW的上一层调用函数FindExistInAllowProcessList(),我们发现其在进行字符串匹配函数StringMatchW调用之前，使用了windows自旋锁来进行内核同步(自旋锁是一种在内核定义，只能在内核态下使用的同步机制。自旋锁用来保护共享数据或者资源，使得并发执行的程序或者在高优先级IRQL的对称多处理器的程序能够正确访问这些数据。)

这与dump提供给我们的信息一致，发生问题的时候IRQL确实是2,然后我们用windbg结合vmware进行win7内核的双机调试，加载AntiTP.sys然后在关键地方下断点来到ExAllocatePoolWithTag的函数内部，发现该函数默认分配的是分页内存：

而该驱动在调用RtlUnicodeStringToAnsiString之前又没有手动进行非分页内存的分配,且IRQL已经提高到DISPATCH级别，故容易导致蓝屏死机。说到这里，读者可能会有如下2个问题：

问题1:为什么分页内存在DPC级别下容易导致蓝屏?

因为驱动的字符串转换相关代码数据是存放在分页内存中的，当驱动需要调用相关函数或者访问该代码页时,如果该页内存数据不在物理内存中，也就是被交换到了虚拟内存页面文件中，将触发内存缺页中断, windows将会试图访问虚拟内存页面文件pagefile.sys，把被交换出的数据读入物理内存中,然而windows的缺页中断处理程序是运行在DISPATCH_LEVEL的级别的，我们的驱动此刻也是运行在DISPATCH_LEVEL级别,故这里我们的驱动不会被缺页中断打断进行内存页的读取， EIP就会访问到一个错误的内存地址（很可能读/写到了其他进程，也可能是系统中重要的数据）上,用户层的程序内存访问违例的异常操作系统能捕捉到反馈给用户，而在驱动内核层内存访问错误,这是一个很严重的问题,操作系统发现立即就以蓝屏的方式处理了。

问题2: 为什么不是必现,只是偶尔发生且主要在启动过程中?

其实不是没有问题，而是驱动的代码数据虽然是分页内存，但是没有被交换出去，还是在物理内存中，访问时不会引发缺页中断,也就没有表现出问题，但是，一旦某一刻当windows发现物理内存不够了，根据内存调度算法恰好把你的代码数据页交换到虚拟内存页面,这个时候基本就会引发蓝屏！而且启动加载过程中，驱动的相关代码数据处于虚拟内存中的概率较大(尚未完全加载)，这时候只要进行相关操作也就容易引起缺页中断致蓝屏！

六、驱动bug修改建议

1. 在调用字符串RtlUnicodeStringToAnsiString的时候降低IRQL，使其<2

2. 不降低IRQL,在调用字符串函数RtlUnicodeStringToAnsiString之前手工分配非分页内存!这里我们推荐方法2,比较符合安全编码的规范,驱动开发一定要谨慎！

七、事件总结

近几年工业安全事件频发, 由于受工业企业自身生产业务以及企业安全管理意识与缺乏的制约, 工业内网终端主机常常是处于“无补丁”、“无防护”、“裸奔”的脆弱状态,对于联网的工业内网来说，极其容易遭受黑客入侵,染毒感染大片工业厂区内网;对于与外网隔绝的工业内网来说,由于主机缺乏有效的终端安全防护措施(主机安全卫士等), 加之对于u盘等可移动存储设备的使用缺乏安全管理与限制，极容易出现“内部员工到互联网不正规网站下载带毒的应用软件，然后通过u盘拷贝至内网终端主机上进行安装，进而感染整个内网”的现象。去年8月全球最大的半导体芯片厂商台积电爆发的内网Wannacry勒索感染事件,后来经证实属于内部员工安装新设备存有疏忽导致。

工业环境不同于传统的网络环境,发生问题的主机常常承载着生产业务，而且有的还没有备份机,因此针对工业安全事件的应急响应事件要格外谨慎,对案发现场把握“尽可能不影响生产” 、“绿色多维取证”、“简单快捷高效”、 “顺藤摸瓜”等原则进行事件响应, 以问题或现象为导向，进行关联分析与溯源定位，复盘攻击路径与攻击画像。

针对目前国内工控环境存在的安全现状,我们实验室给工业企业如下的安全防护建议:

1.对员工进行安全教育,全面提高企业整体的安全意识

2.使用最小特权原则，减少“内鬼”进行”恶意”操作的概率

3.部署工业内网终端主机安全软件和内网威胁管理系统等解决方案

4.调整内网不同厂区网络架构,部署工业防火墙等网络层防护方案

5.及时备份数据,做好容灾备份、及时更新系统与软件补丁，禁用高危端口等

6.与安全厂商进行合作,定期进行安全检查与攻防演练培训等

八、参考链接

1、https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-exallocatepoolwithtag

2、https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-rtlunicodestringtoansistring

3、https://blog.csdn.net/yw1621/article/details/64185513

4、https://www.xianjichina.com/news/details_66443.html