转载

内网安全（一）：从一封钓鱼邮件开始

* 本文原创作者：xysky，本文属FreeBuf原创奖励计划，未经许可禁止转载

0×01 前言

这是一个真实的案例，发生在某大型企业内网中（以下简称M公司，M公司在全国及海外都有其分支机构），笔者有幸作为外部顾问全程参与整个事件的分析与处置过程，整理成文与大家分享，共同探讨。

0×02 安全事件回顾

2016.2.2号18：48分，M公司在海外的某分公司（以下简称X分公司）IPS在SOC上报了一笔事件，内容如下：

[IPS][001026]2 二月 2016 18:48:00 CST Src(30.80.21.172) Dst(30.80.3.31) BTP is low high risk attack. Name:BACKDOOR: Windows Command Shell Running .AgentName:McafeeNSMDB-20.80.31.1-bu-szdc-SC16

IPS相关同事邮件发给X分公司IT负责人跟进，这笔事件在IPS上看数据包返回了Microsoft Windows [Version 6.0.6002字样，命中command shell特征，确实比较可疑。

第二天即2016-02-03 12:02，类似的IPS报警再次触发，内容如下：

[IPS][001026]3 二月 2016 12:02:30 CST Src(30.80.21.172) Dst(30.80.3.10) BTP is low high risk attack. Name:BACKDOOR: Windows Command Shell Running .AgentName:McafeeNSMDB-20.80.31.1-bu-szdc-SC16

注意两次攻击的目标服务器不同，第二次30.80.3.10是域服务器。这台域服务器还触发了SEP告警，内容如下：

[SEP][032015]3 Feb 2016 12:22:20 CST Security risk found:C:/DELL/24.txt . Virus type: Hacktool.Mimikatz on HKDC2N(30.80.3.10)

随后还有大量的蜜灌事件，内容如下：

[HoneyPot][008001]3 Feb 2016 13:33:45 CST SrcIP(30.80.21.172) access to the honeypotIP(30.80.3.18) Port(445)
[HoneyPot][008001]3 Feb 2016 16:18:26 CST SrcIP(30.80.3.31) access to the honeypotIP(30.80.3.18) Port(23)
[HoneyPot][008001]3 Feb 2016 16:18:26 CST SrcIP(30.80.3.31) access to the honeypotIP(30.80.3.18) Port(3389)
[HoneyPot][008001]3 Feb 2016 16:18:26 CST SrcIP(30.80.3.31) access to the honeypotIP(30.80.3.18) Port(80)
[HoneyPot][008001]3 Feb 2016 16:18:26 CST SrcIP(30.80.3.31) access to the honeypotIP(30.80.3.18) Port(445)

基于以上事件，我们紧急联系X分公司，让其将源头机器30.80.21.172进行断网处理，并开始着手分析处理。

0x03中间分析经过

一封可疑邮件

30.80.21.172这台机器使用人回忆最近收到一封奇怪的邮件并打开了附件，于是我们从邮件网关中将其取回来进行了一定的分析，如下图：

内网安全（一）：从一封钓鱼邮件开始

邮件特别之处在于：

1.是压缩并且加密的附件；

2.密码写在邮件中；

3.解压出来是个.cpl的文件

4.双击以上cpl文件会释放出一个doc文档并调用office程序打开。

花费较多时间在搭建适合的环境运行这个cpl文件，在office2003环境无法正常打开文件，在office2007打开了但未出现其它可疑进程或网络访问（中间出现几个IP后确认是微软本身的）。

我们提交给防病毒厂商Symantec进行分析，厂商第二天提供的报告说没有发现问题。

可疑上网行为记录

在上网行为上调取30.80.21.172相关的记录，主要有以下几点发现：

1. 机器上可能安装了sogou相关的东西，一直不断的向sogou服务器提交信息；

2. 用户浏览了一些与财经相关的网站，特别是搜狐财经网站，注意SEP也报了一个关于cookie的病毒，但是X分公司另一台机器；

3. 除此外就是大量请求两个无法解析的域名相关的网站，8bvcxyz.gov和kyz这两个可疑网站的443端口，但不知道具体的IP地址。

30.80.3.31机器相关行为分析

该机器是部署在X分公司的安全客户端后台服务器。在X分公司主要用途是审计U盘拷贝文件，未限制USB的员工暂未部署安全客户端，上面30.80.21.172就没有部署。

从前面IPS报的事件看，我们知道30.80.21.172访问了99.8.3.31这台机器的9443端口触发command shell警告，于是我们上来就看这个端口相关的信息如下：

C:/Users/hoadmin>netstat.exe -ano|findstr 9443
  TCP    30.80.3.31:9443        30.80.21.172:62427     ESTABLISHED     10000
C:/Users/hoadmin>tasklist.exe |findstr 10000
sv.exe                       10000 Services                   0      1,716 K

进一步分析可以发现这个sv.exe是由psexec相关的服务起的，根据经验psexec需要账号密码来远程执行命令，我们在安全日志中找到了相关的记录：

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2/2/2016 5:23:51 PM
Event ID:      4697
Task Category: Security System Extension
Level:         Information
Keywords:      Audit Success
User:          N/A
hina.cn
Description:
A service was installed in the system.
Subject:
Security ID: XOFFICE/SUAdminhk_zxxyy
Account Name: SUAdminhk_zxxyy
Account Domain: XOFFICE
Logon ID: 0x7330520
Service Information:
Service Name: PSEXESVC
Service File Name: %SystemRoot%/PSEXESVC.exe
Service Type: 0x10
Service Start Type: 3
Service Account: LocalSystem

继续追查更多事件，可以知道，30.80.21.172一直在用SUAdminhk_zxxyy这个账号登录30.80.3.31并执行相关命令。

同时，在该机器上也发现了黑客留下的可疑文件，sv.exe以及运行所需的dllr.dll文件，还有一个netscan.exe，以及在用户目录留下一个netscan.exe扫描后产生结果的xml文件，这个文件的内容部分如下：

SoftPerfect Network Scanner 30.80.21.0-30.80.21.255,30.80.3.0-30.80.3.255 2016-02-03T16:21:12.422+08:00

….更多忽略

该机器上发现的可疑可执行文件相关信息如下：

3bbc51cfc5c1c1d51a26f61f3c0182bf  Admin/dllr.dll
a85292ef9d40964f8d68cf56dd262b7b  Admin/sv.exe
edb1c480295250dd1a38f3aa1357deae  netscan.exe

Netscan.exe这个就不多说了，一个扫描器，网上都能找到。我们在测试环境中运行这个sv.exe，有如下特别的发现：

exe刚启动的时候只加载很少的模块，同目录下的dllr.dll是不会加载的，即删除这个dll执行exe也能正常运行并且过一会自动退出，中间没有任何报错；

过了大约2分钟，才会加载这个dll文件以及其它模块，同时开始监听9443端口； 从远端机器telnet上去这个9443端口，会得到一个cmdshell，可以执行一些命令。

将进程sv.exe结束掉之后，已经从远端连接上来的连接是不会断的，依然可以执行命令，只是无法再新建连接而已。 只有当将sv.exe调用的cmd.exe结束后才能真正中断已有连接。

中间分析的详细数据如下：

2016-2-16 18:47:51    创建新进程    允许
进程: c:/windows/explorer.exe
目标: c:/documents and settings/administrator/桌面/hackfile/sv.exe
命令行: "C:/Documents and Settings/Administrator/桌面/hackfile/sv.exe" 
规则: [应用程序]*
2016-2-16 18:53:05    从其他进程复制句柄    允许
进程: c:/windows/system32/svchost.exe
目标: c:/documents and settings/administrator/桌面/hackfile/sv.exe
句柄: (File) C:/WINDOWS/system32/cmd.exe
规则: [应用程序]c:/windows/system32/svchost.exe
2016-2-16 18:53:11    创建新进程    允许
进程: c:/documents and settings/administrator/桌面/hackfile/sv.exe
目标: c:/windows/system32/cmd.exe
命令行: cmd
规则: [应用程序]*
2016-2-16 18:53:13    访问网络    允许
进程: c:/windows/system32/cmd.exe
目标: TCP [本机 : 9443] <-  [30.0.64.165 : 64792]
规则: [网络]任意协议 [本机 : 任意端口] <-> [任意地址 : 任意端口]

做了更多进一步的分析，暂未发现其它问题。出于安全考虑，已经进行了系统重装。

30.80.3.10机器相关行为分析

这是域服务器，前面的SEP已经告诉我们黑客尝试留下后门被删，于是我们到c:/DELL目录发现时间有变化，而且C:/DELL/AppAssure这个目录时间也有变化，进去就发现了同样的后门文件sv.exe及dllr.dll。最后还发现黑客在C:/windows/目录下放了一个sys64.exe文件，很狡猾，这是我们发现的第二个后门。在该机器上发现的可疑可执行文件相关信息如下：

f2214577c920c2eb2fe455368a02dc5a  C:/windows/sys64.exe
3bbc51cfc5c1c1d51a26f61f3c0182bf  C:/DELL/AppAssure/dllr.dll
a85292ef9d40964f8d68cf56dd262b7b  C:/DELL/AppAssure/sv.exe

Sv.exe及dllr.dll前面分析过，重点分析sys64.exe，在测试环境运行后，我们发现其会尝试反弹连接一个德国的IP地址： 82.211.30.195 的443端口。于是我们又在上网行为中检查这个IP地址的请求，发现只有30.80.21.172访问过，而且其对应的域名就是前面发现的可疑请求 https:// kyz ，而且每隔5分钟一次。

分析安全事件，的确30.80.21.172一直在不断的用SUAdminhk_zxxyy登录而且都是成功的，而且也被psexec远程执行过命令（会在系统事件中留下痕迹）。

继续分析安全事件，发现SUAdminhk_zxxyy的账号除了在30.80.21.172、30.80.3.31上登录过之后，还在30.80.21.17上登录过，后与其确认是那天中午在该员工机器上卸载office并重装使用，正常。

暂未发现其它问题，但由于sys64.exe这个后门文件的功能还不是特别清楚，虽然没能成功连出，建议还是重装系统。

30.80.3.9机器相关行为分析

这个机器相对比上面一台机器更少受影响，从登录的次数与文件修改的情况就可以确认。C:/DELL目录下的sv.exe及dllr.dll文件，同样也被psexec远程执行过命令，这些都体现在系统事件中了，不再重复。

另外，发现除了前面已知的机器用SUAdminhk_zxxyy账号登录此域，还有30.80.4.5、30.80.31.1这两台机器，后面与赖敏文都确认是正常维护产生。该机器上的可疑可执行文件信息如下：

3bbc51cfc5c1c1d51a26f61f3c0182bf  C:/DELL/dllr.dll
a85292ef9d40964f8d68cf56dd262b7b  C:/DELL/sv.exe

与前面的文件一样，就不再多说了。

再次分析可疑邮件

在前面这些明显被黑的机器上，得到的信息无法反推出黑客到底怎么进来的？

念念不忘，必有回响。春节过后，我再次在虚拟机里进行分析这个文件，发现当双击这个cpl文件后，虽然office2003还是出现打不开显示乱码的画面，但是我们关掉office之后，rundll32.exe会去尝试访问网络（ 经反复测试，出现乱码后要隔一段时间才会有网络访问请求触发 ），访问一个192.169.6.151的443端口，相关的测试数据如下：

内网安全（一）：从一封钓鱼邮件开始

可能我们在春节前分析的时候看到的 几个IP中把这个192.169的习惯性的选择了忽略 ， 其实它是一个真实存在的美国IP地址。 回过头在上网行为中查，发现其就是 我们前面对应到的8bvcxyz.gov，而且只有这个IP访问过 。

后面在朋友的帮助下，对该cpl时行了逆向分析，得到如下结论：

木马文件的加载方式：

控制面板在执行的时候会加载System32目录下的所有*.CPL文件

注册表启动项中加入RunDll32 shell32.dll、Contorl_RunDll muma.cpl

该木马可疑行为：

Dllmain中没有功能逻辑

只有一个导出函数CPlApplet

导出函数被调用后，会释放资源数据并本地生成名称为ABOUT_US.doc的word文件，执行打开该文档文件后， 延后1617ms ，木马会对 192.169.6.151 地址发送网络请求。

至此，成功找到入侵的源头，来源于这封可恶的邮件！

30.80.21.172机器相关行为分析

春节后，收到X分公司提供的该机器的系统盘GHOST文件，用工具进行了一些文件提取，发现如下：

1. 在C盘intels、Temps目录留有大量的黑客工具而且全部免杀，其文件名和MD5值分别如下：

2c88a3f11bff94ae0f6a7b5d4da4035d  Temps/svchst.exe
9653b90c8b5abe4277cf06ebcbe21021  Temps/32.dll
649647dbdf024f1c565f380777c0c65e  intels/procdump.exe
9f31027bf7c3f9fa54eb2793d4d4377c  intels/195/svchst.exe
2f3853d8c93bdad0846c5c4223c9f4d2  intels/195/32.dll
d0df366711c8b296680002840336b6fd  intels/psexec.exe
424872148d3e84ed99cedd5bfbb8740c  intels/runas.exe
f2214577c920c2eb2fe455368a02dc5a  intels/sys64.exe
db34ce686d2b911589667cbcae3a920c  intels/64.exe
fb28f92f24570c117f34b6917f405da0  intels/dllr.dll
a85292ef9d40964f8d68cf56dd262b7b  intels/sv.exe
2c88a3f11bff94ae0f6a7b5d4da4035d  intels/svchst.exe
3bbc51cfc5c1c1d51a26f61f3c0182bf  intels/c/dllr.dll
a85292ef9d40964f8d68cf56dd262b7b  intels/c/sv.exe
9653b90c8b5abe4277cf06ebcbe21021  intels/32.dll
edb1c480295250dd1a38f3aa1357deae  intels/netscan.exe
9b56ae417e5c4dd46342bff2a50d1186  intels/myfile
12613ac87e6e550057ab5eb770f98f35  intels/32.exe

所留的文件最多，前面服务器上发现的文件基本上这都已经包含了，这也印证其是攻击的源头所在。

我们分析Temps目录下这两个文件svchst.exe及32.dll，发现一些特别之处：

exe刚启动的时候是不会加载这个32.dll的，即把32.dll删除也能运行，不存在强制依赖关系；

exe刚运行时加载的模块很少， 过4分钟后才会加载这个32.dll以及其它模块，并会出现相关网络访问，还是访问美国那个IP地址， 详细数据如下：

2016-2-16 17:44:53    创建新进程    允许
进程: c:/windows/explorer.exe
目标: c:/documents and settings/administrator/桌面/temps/svchst.exe
命令行: "C:/Documents and Settings/Administrator/桌面/Temps/svchst.exe" 
规则: [应用程序]*
2016-2-16 17:48:57    访问网络    允许
进程: c:/documents and settings/administrator/桌面/temps/svchst.exe
目标: TCP [本机 : 1117] ->  [192.169.6.151 : 443 (https)]
规则: [网络]任意协议 [本机 : 任意端口] <-> [任意地址 : 任意端口]

与这两个文件md5值相同的文件就不再分析，但还有个文件名相同但md5值不同的文件即 intels/195/svchst.exe和intels/195/32.dll，其与上面的特征类似， 也是要过大约4分钟才会加载一些模块并请求访问网络，只是这回访问的网络IP地址变成了德国的IP地址 ，具体测试信息如下：

2016-2-16 19:24:22    创建新进程    允许
进程: c:/windows/explorer.exe
目标: c:/documents and settings/administrator/桌面/intels/195/svchst.exe
命令行: "C:/Documents and Settings/Administrator/桌面/intels/195/svchst.exe" 
规则: [应用程序]*
2016-2-16 19:28:47    访问网络    允许
进程: c:/documents and settings/administrator/桌面/intels/195/svchst.exe
目标: TCP [本机 : 1149] ->  [82.211.30.195 : 443 (https)]
规则: [网络]任意协议 [本机 : 任意端口] <-> [任意地址 : 任意端口]

注意，连德国IP的443的后门目前有两个版本，一个是启动即开始连接的sys64.exe不带dll文件，一个是这里发现的带dll并且延时访问的。

C:/intels/c目录下的sv.exe、dllr.dll文件，与前面发现的文件有些关联，exe是同一个文件，但dll不同是一个文件。经分析功能是一样的，也是延时加载dll并监听9443，提供一个cmdshell。

黑客上传的文件中，有几个是微软提供的，包括psexec、runas、procdump，procdump的本意是用来监控应用程序的CPU异常动向生成dump文件的，而黑客却可以利用它来抓密码。 用procdump获取lsass进程的内存dump，然后用mimikatz离线分析可以得到密码，这中间是不会触发防病毒告警的 。32.exe和64.exe分别是mimikatz alpha版本的32位和64位程序，注意是免杀的版本。

0x04 快速止血

基于前面的分析结论，进行了快速止血操作：对X分公司全网段进行内网端口9443扫描，确认没有机器被感染；在X分公司上网行为上排查出现的两个恶意IP地址，只有30.80.21.172访问过，确认没有其它机器被控制；在总公司及所有分公司上网行为中将这两个恶意IP进行拦截并记录；对涉及到的几台机器进行重装处理；对涉及到的IT管理员账号密码进行了重置。

0x05黑客行动推演

有了前面的分析，黑客的行动就大概知道了，我们按时间线来排列如下：

1. 2016-02-01 17:13:27

黑客通过其邮箱avion.com.hk@gmail.com给目标用户hkcorpsxxx@M.com发送了一个特殊的邮件，加密的压缩包，里面是个cpl文件（注意，黑客仅发送了一封邮件到我司邮件服务器）；

2. 2016-02-01 17:39:36

目标用户打开了这个邮件，最终触发了机器上的rundll32.exe请求美国IP地址192.169.6.151的443端口；‎2016‎-0‎2-01 ‏‎17:40:17，svchst.exe及32.dll这两个文件下载到机器上的c:/Temps目录；2016‎-0‎2-0‎1 ‏‎17:43:35又下载了一次这两文件到c:/intels目录；2016-02-01 18:21:37下载了同名但md5值不同的文件到c:/intels/195目录；

3. ‎2016-02-01 18:22分左右

黑客执行了c:/intels/195下的反弹后门文件，与我们在上网行为上看到从2016-02-01 18:26:29开始持续访问德国IP地址82.211.30.195的443端口符合。这个德国IP经过简单测试发现是个Windows机器，反弹后门的主控端在上面运行。

4. 被控制的机器下班关机了，期间无事件，一直到第二天开机

后门程序都在正常工作，开始不断请求上面两个IP的443端口；

5. 2016-02-02 11:39开始

黑客下载了不少可执行文件到c:/intels目录，包括psexec.exe、sys64.exe、runas.exe、sv.exe、dllr.dll、procdump.exe，以及c:/intels/c目录下sv.exe、dllr.dll。黑客通过procdump抓到了包含账号登录信息的lsass.exe进程的内存dump，进而搞到了域管理员密码之后。有了这个密码之后，可以用runas切换用户执行，也可以psexec到远程域服务器上执行命令。至此，两台域服务器都被控制。