Log4j勒索病毒事件应急响应实战教学文档

1. 事件背景与概述

1.1 事件背景

• Apache Log4j漏洞(CVE-2021-44228)爆发初期被勒索团伙武器化利用
• 针对医疗行业的有针对性勒索攻击
• 攻击导致医院服务器数据被加密，互联网业务完全无法使用

1.2 攻击特点

• 利用漏洞公开到修复的时间差进行批量扫描攻击
• 集成快、覆盖范围广、攻击时难以感知
• 主要影响存在漏洞的服务器，暂不具备内网自动横向传播能力

2. 事件发现与初步响应

2.1 事件发现

• 用户反馈医院公众号缴费等功能无法使用，服务器返回500错误
• 运维人员检查发现服务器数据被"xxxx.locked"后缀加密
• 立即采取物理隔离措施

2.2 初步响应措施

• 使用报废机进行上机排查
• 提取关键样本：
  • 被加密文件样本
  • 勒索README.html文件
  • 勒索程序样本
  • 应用程序源码文件

3. 攻击分析与取证

3.1 勒索团伙识别

• 通过README.html文件预留邮箱等关键词搜索
• 确认为Tellyouthepass勒索团伙

3.2 攻击时间线

• Nginx错误日志中发现可疑IP(158.x.x.x)的访问：
  • 时间区间：12月16日13点38分41秒至13点41分32秒
• 防火墙事件信息中发现利用log4j攻击行为(动作为丢弃未拦截)

3.3 威胁情报分析

• 158.x.x.x IP存在恶意攻击历史活动
• 符合黑产相关特征

3.4 攻击链还原

1. 利用CVE-2021-44228漏洞进行批量扫描攻击
2. 攻击成功后远程代码执行
3. 下载勒索病毒文件到/tmp/bash并执行

4. 勒索程序分析

4.1 程序行为

• 与后台IP(158.x.x.x)进行通信
• 停止数据库等关键服务(如MySQL)
• 扫描文件路径
• 写入SSH公钥(public.txt)
• 加密数据文件

4.2 生成文件

• README.html：勒索说明文件
• public.txt：写入的SSH公钥
• encfile.txt：所有被加密文件列表
• showkey.txt：经过加密后的key信息

4.3 加密特点

• 双线程操作(加密和扫描全盘目录同时进行)
• 部分日志文件因发现及时未被完全加密

5. 漏洞验证与排查

5.1 漏洞验证方法

1. 搭建本地环境进行log4j漏洞验证
2. 确认存在相关漏洞

5.2 全量排查

• 编写log4j漏洞排查脚本
• 对60余台服务器进行全量排查
• 确认两台Linux服务器被勒索：
  • 掌上医院正式服务器
  • 测试服务器

5.3 临时措施

• 关闭受影响服务器上运行的Java服务
• 等待开发人员进行log4j版本升级

6. 业务恢复流程

6.1 系统重新部署

1. 在新分配的服务器资源上重新部署系统
2. 依据基线加固方案进行安全加固
3. 开发人员完成业务程序部署和调试

6.2 漏洞修复验证

• 对修复后的系统进行log4j漏洞复测
• 确认漏洞已成功修复

6.3 网络恢复

1. 内网试运行
2. 确认正常后开通互联网访问

6.4 持续监控

• 部署态势感知设备
• 验证设备能有效监测log4j漏洞攻击
• 持续监控至次日18时，未再发生攻击事件

7. 事件总结与关键发现

7.1 受影响系统

• 两台Linux服务器：
  • 掌上医院正式服务器
  • 测试服务器

7.2 攻击链路

• 利用log4j(CVE-2021-44228)漏洞进行攻击

7.3 勒索病毒类型

• Tellyouthepass勒索病毒
• 无横向传播能力

7.4 安全设备问题

• 外网防火墙规则库未更新
• 导致被log4j最新变种利用绕过

7.5 恢复情况

• 业务重新部署调试完成
• 通过漏洞复测
• 业务恢复正常上线

8. 应急响应最佳实践

8.1 预防措施

• 保持安全设备规则库及时更新
• 对高危漏洞及时打补丁
• 建立漏洞预警机制

8.2 响应流程

1. 立即隔离受影响系统
2. 收集关键证据和样本
3. 分析攻击路径和方法
4. 全量排查受影响范围
5. 制定恢复方案
6. 验证修复效果
7. 部署持续监控

8.3 恢复策略

• 优先考虑重建而非解密
• 确保新环境安全加固
• 验证所有安全控制措施

9. 技术要点总结

1. Log4j漏洞利用窗口期极短，需建立快速响应机制
2. 勒索病毒可能不会完全加密所有文件，取证时需注意部分加密文件
3. 防火墙等安全设备需保持规则库最新才能有效防护新型攻击
4. 态势感知设备对持续监控和攻击发现至关重要
5. 应急响应需多部门协作(运维、开发、安全团队)