一旦对他人的苦难视而不见,苦难就会在我们中间蔓延。——《失明症漫记》
前几天威胁分析同学发现某客户环境中存在挖矿事件告警,本来以为就是个简单的挖矿事件,用杀毒软件扫描下就能解决,但是客户先用某数字杀软查杀后,网络侧仍有挖矿的告警,所以转到应急进行调查和分析。
在应急分析过程发现,挖矿程序利用DLL侧载技术,通过白+黑方式,创建计划任务进行自启动及周期性运行。在分析过程,也花了比较长的时间才定位到问题,下面对本次事件分析过程进行详细说明。
威胁分析同学在网络侧发现挖矿告警,很明显的挖矿特征:
由于之前客户已经用杀软扫描过了,所以直接远程到失陷主机手工排查。先使用process explorer(图忘截了)和Autoruns,结果出乎意料,一切正常:
查看计划任务,也未发现异常:
怀疑是利用WMI事件订阅实现维持访问,排查也未发现异常:
Get-WMIObject -Namespace rootSubscription -Class __EventFilter
Get-WMIObject -Namespace rootSubscription -Class __EventConsumer
Get-WMIObject -Namespace rootSubscription -Class __FilterToConsumerBinding
但网络侧确实还在发送矿池通信请求,而且我们现在已经知道目的IP。接下来的思路就是,找到是哪个进程发起的异常外联请求。既然常规手段找不到,就只能使用非常规手段了。
这里使用sysmon记录进程创建信息,使用CurrPorts记录网络连接信息,并启用任务计划程序的“所有任务历史记录”。等了一会后,CurrPorts里面发现发起恶意外联的进程为TiWorker.exe:
Sysmon日志记录到详细的命令行信息及父进程SH_1.4.93.68.exe的信息:
直接访问对应的文件,会发现文件不存在:
这里,我们需要对文件及目录的属性进行修改:
attrib /s -s -h c:WindowsSysWOW64WindowsPowerShellS-1-5-26*
attrib /s -s -h c:WindowsSysWOW64ComdmpL-1-67-31*
然后将对应的两个文件复制出来,查看签名,发现均为合法程序:
这里稍微怀疑了下是不是这两个应用程序有特殊功能,通信特征符合矿池通信特征,但想了下可能性不大。所以对这2个文件对应的目录进行检查,发现几个可疑的DLL文件,而且时间戳都修改成了系统文件的时间:
将上面发现的DLL在virustotal进行查杀,确认为恶意程序,且存在一定的防御规避能力,:
Riched32.dll:
AppleVersions.dll:
data.dll:
通过简单的样本分析,发现恶意程序是通过dll侧载及白+黑方式运行。
接下来,需要分析确认恶意程序的启动机制。SH_1.4.93.68.exe父进程为svchost.exe,实际对应计划任务进程:
至此,可以判断恶意程序是通过计划任务运行的。
因为我们之前已经启用了任务历史记录,对日志进行检查,发现执行恶意程序的计划任务信息:
通过任务计划程序查看,发现是空白的(已经是管理员权限了):
虽然这里看不到,但无妨,我们可以到注册表里面去看。在注册表的
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTree
下可以看到此计划任务的id:
在
下可以看到具体的配置信息,包括执行的程序:
在进行证据收集后,删除上面2个注册表键值及涉及的exe和dll即可完成清理。
如果不放心,可以重启下计划任务服务,但由于该服务是系统服务,管理员权限也无法重启,所以我们需要使用psexec将权限提升到SYSTEM权限再重启,具体可参考之前的文章:
至于恶意程序是如何落地的,因为时间关系没有详细分析,但因为是个人电脑,且上面存在多个破解软件,推测是通过破解软件传播的。
通过本次事件的分析可以发现,“道高一尺,魔高一丈”,黑灰产团伙的攻击手段也在不断地进步和升级,但是作为防守方,我们却经常处于被动的状态,当事件发生时,经常发现缺少网络侧流量或者终端日志。所以,也希望安全产品的能力,以及安全从业者的能力,能够跟上攻击技术的发展趋势,靠天天炒作和弄虚作假,很难解决实际的安全问题。
希望这篇文章对大家有所帮助,也感谢大家一直以来的支持?。
网络
185.225.17[.]131
185.225.17[.]132
185.225.17[.]242
185.225.17[.]118
185.225.17[.]144
文件
Riched32.dll
3c56069dbc01c1e0a422ee2b14790ff6
fe440ab3f1625ea8436bd2b6793b35ebd4101d76
851e53b5daac9afa4dd5308ef3ec86225d1eed2b2d8e3435de593d2c738fd1c4
AppleVersions.dll
f0c01510a55c70619f997bd4672d43d6
0b652a2fd5369b79bf406de5e7d263afee570608
63cb5e1ad81467e64e0c0c7dcf53987d28a1123bbb6dd0f36d4f9ca93d881300
SH_1.4.93.68.exe
a72e79b12016b789f796ba267cca05a9
01cae738b25a4fcf449d1449df38f1de7b55129d
fc45eb5c9d3f89cb059212e00512ec0e6c47c1bdf12842256ceda5d4f1371bd5
data.dll
d0700e7f38cec366f7e71ab9467346a5
b022cfc13fa17f37c00949091bb8f03ef75b1b1a
db6c293e476ea1e9348faba38ab0ceac4698f03121864c0385c5b2ae2a4c5378
https://github.com/SwiftOnSecurity/sysmon-config
https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
https://www.nirsoft.net/utils/cports.html
原文始发于微信公众号(Desync InfoSec):一次利用DLL侧载挖矿事件应急响应