奇安信攻防社区-【实战】记一次“Log4j勒索病毒”事件的应急响应

【实战】记一次“Log4j勒索病毒”事件的应急响应

一次关于某医院“Log4j勒索病毒”事件的应急响应

事件背景
----

在`Apache Log4j`漏洞刚爆出的一段时间，`Log4j`漏洞席卷整个互联网，勒索团伙也在此时将漏洞武器化，在互联网上大肆撒网，开展有针对性的勒索攻击。此次事件便是勒索团伙在`Log4j`漏洞爆发初期武器化利用，针对医疗行业的一次大肆勒索攻击。

事情开端
----

一个正常工作日临近下班的18:35，一通急匆匆的电话响起，被告知某医院服务器被勒索，用户数据遭到加密，导致互联网业务完全无法使用，需要立即前往现场开展应急响应，排查取证，并对攻击路径和攻击方法进行分析，恢复业务系统。

到达现场后，通过与管理运维人员沟通了解事件原委：客户收到用户反馈，医院公众号缴费等功能均无法使用，服务器返回500后无法打开。于是上服务器查看，发现服务器数据均被`"xxxx.locked"`后缀加密。运维人员意识到服务器可能中了勒索病毒，于是马上将相关服务器组进行物理隔离，暂不清楚是否有内网横向的影响主机。

应急排查
----

在简单和相关人员沟通后，找了一台报废机进行上机排查，提取到被加密文件样本、勒索预留`README.html`文件、勒索程序样本，应用程序源码文件进行分析。

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-d6cf28195b06bddeab68cab97e91da9d1cc1a14a.png)

日志文件等均被加密

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-e8d37f9d51e6dd21cd59aee6a931f71d01183403.png)

通过对勒索预留`README.html`文件预留邮箱等关键词进行搜索，暂定为`Tellyouthepass`勒索团伙，该团伙主要利用漏洞公开到修复的时间差进行批量扫描攻击，由于漏洞已具有完整的`POC`，使其具有集成快、覆盖范围广、攻击时难以感知的特点。与常规的勒索病毒攻击相比，此类攻击的受影响较大的是存在漏洞的服务器，暂不具有内网自动横向的功能，但加密后数据无法直接解密，同样面临高额的勒索赎金。

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-7df85e5acc28c691c5f124d640af32f16cd94f8f.png)

对勒索程序样本进行分析，程序执行后会与后台IP（158.x.x.x）进行通信，然后停止数据库等关键服务，扫描文件路径，写入勒索文件。此处发现比较有意思的地方，由于勒索程序加密和扫描全盘目录写的双线程，由于发现的比较及时，造成部分日志文件未被完全加密成功，在对`Nginx`错误日志中发现了可疑IP（158.x.x.x）的访问时间区间为12月16日13点41分32秒至12月16日13点38分41秒，该时间范围内可能为黑客攻击利用；

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-4908032b57922aab6d20d57b3bc9a5879e8dcb53.png)

此时有同事在防火墙事件信息中发现有利用`log4j`攻击行为，防火墙的动作是丢弃并未进行拦截。

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-dcf250c3473f5640b8113dc959231e8874724d98.png)

通过查询158.x.x.x的威胁情报，发现存在恶意攻击历史活动，符合黑产相关特征，可作为后续追查的切入点和参考；

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-2bf14d9e95b6b51162ad90efde0440c88e9fa3e1.png)

恶意团伙利用`CVE-2021-44228`漏洞进行批量扫描攻击利用，攻击成功后便会远程代码执行下载勒索病毒文件到`/tmp/bash`并执行；

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-9e1d92ae10954970d3b37f94e626a0bbc7f2dfb8.png)

对`bash`文件提取并进行逆向分析，程序执行后会与后台IP（158.x.x.x）进行通信，然后停止数据库等关键服务，扫描文件路径，然后写入ssh公钥，写入勒索文件，加密数据文件，索要赎金。勒索程序样本时间均为12月16日13点41分上下。

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-7d1cd03ca0ab514173db6972601226802c003caf.png)

停止`MySQL`等关键服务

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-3d302eb9a203dcab30c5179f01a20368a9dbd679.png)

程序执行完后会生成了几个文件，有`README.html、public.txt、encfile.txt`和`showkey.txt`文件，其中有`ssh`行为，`public.txt`文件为写入的`ssh`公钥，`encfile.txt`文件为所有被加密的文件列表，`showkey.txt`文件为经过加密后的`key`信息等。

![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-eabac5be3fbe0b2787d0718242afa3a3ff260351.png)

漏洞验证
----

1、针对被勒索的两台服务，通过搭建本地环境，进行`log4j`漏洞验证，确认存在相关漏洞；  
2、针对`log4j`漏洞编写对应的排查脚本，对60余台服务器进行全量排查，最终共发现两台`linux`服务器被勒索，分别为掌上医院、测试服务器。  
3、涉及使用`log4j`组件漏洞影响的服务器，已将其运行的`java`服务暂时关闭，待系统对应开发人员前来进行`log4j`版本升级。

业务恢复
----

1、由涉及系统的开发单位，在新分配的服务器资源上进行系统的重新部署，调试，在部署期间依据基线加固方案对系统所部署的服务器进行安全加固；  
2、开发人员在次日凌晨4.40完成业务程序部署之后，在内网试运行，并对其使用`log4j`漏洞进行复测，经测试`log4j`已修复成功。  
3、随后将互联网全面开通，业务恢复正常运行，同时部署态势感知设备，待设备经过流量、漏洞测试后，发现可有效监测`log4j`漏洞攻击，由此开展实施监控。  
![image.png](https://shs3.b.qianxin.com/attack_forum/2023/02/attach-95f5f42ebb4b98c56dac00ecd6409a4efd958e0a.png)  
4、持续直到次日18时，并未再次发生任何安全攻击事件，此次事件初步告一段落。

总结
--

【被攻击服务器】：两台`Linux`服务器，分别为掌上医院正式服务器与测试服务器；  
【攻击链路】：攻击者利用新爆发的`log4j（CVE-2021-44228）`漏洞进行攻击；  
【勒索病毒类型】：`tellyouthepass`勒索病毒，经分析无横向传播能力。  
【安全设备运行情况】：外网防火墙由于规则库未更新，导致被`log4j`最新变种利用绕过；  
【业务恢复情况】：经开发对业务进行重新部署以及调试，已于此时凌晨完成业务恢复上线，并通过`log4j`漏洞复测。  
【持续监控】：通过部署态势感知设备，对恢复后的网站持续监测，直到次日下午并未发生再次攻击事件。

发表于 2023-02-21 09:00:02
阅读 ( 9209 )
分类：应急响应

【实战】记一次“Log4j勒索病毒”事件的应急响应

0 条评论