从告警到溯源：一次真实应急响应的48小时全记录

从告警到溯源：一次真实应急响应的48小时全记录

凌晨2点17分，手机震了一下。不是微信，是SIEM的P0告警推送："异常横向移动——内网主机10.0.3.15向10.0.3.0/24网段发起大量SMB连接。"

我揉了揉眼睛，看了三秒，脑子立刻清醒了——SMB横向移动，大概率是勒索软件的前兆。来不及换衣服，打开笔记本电脑开始远程接入。

整个应急响应过程持续了48小时。把完整经过整理出来，不写教科书上的标准流程，只说实际发生了什么、踩了什么坑、哪些决策是对的、哪些决策事后看是浪费时间。

第一阶段：确认与遏制（0-2小时）

0:20 确认告警真实性

告警内容是10.0.3.15对同网段254个IP的445端口发起连接。第一反应是SMB扫描。

先排除误报——登录EDR控制台查10.0.3.15的进程列表，发现了两个可疑进程：

svchost.exe  PID: 4892  父进程: services.exe  正常
svchost.exe  PID: 7340  父进程: explorer.exe   可疑！！

svchost.exe的父进程应该是services.exe，而不是explorer.exe。这个进程是伪装的。确认：这不是误报，是真实入侵。

0:35 紧急决策：要不要立即断网？

这是应急响应里最纠结的决策。断网能阻止横向移动，但会：

• 丢失内存中的证据（恶意进程、网络连接）
• 打草惊蛇，攻击者可能有备用通道
• 影响业务连续性

最终决定：不断网，但立即隔离。在交换机上把10.0.3.15的端口划到一个独立VLAN，只允许它和取证服务器通信。这样既切断了横向移动，又保留了在线取证的条件。

1:00 内存取证

# 在取证服务器上通过网络获取内存镜像
winpmem_mini_x64.exe --output \\forensics\memdump\10.0.3.15.raw

# 用Volatility分析
volatility -f 10.0.3.15.raw --profile=Win10x64 pslist
volatility -f 10.0.3.15.raw --profile=Win10x64 netscan

内存取证抓到了关键信息：

• PID 7340的svchost.exe加载了一个不在系统目录的DLL：C:\ProgramData\microsoft\db\mss.dll
• 网络连接显示PID 7340向外连接到45.xx.xx.xx:443（C2服务器）

1:30 阻断C2通信

在防火墙上封禁45.xx.xx.xx的出站连接。同时用EDR的网络隔离功能，把10.0.3.15的出站流量全部阻断，只保留取证通道。

⚠️ 踩坑提醒：封C2的IP时手快了，没确认这个IP是否被合法业务使用。后来查了威胁情报平台，确认是恶意IP才放心。但这个确认动作应该在封禁之前做，不是之后。

第二阶段：扩大排查（2-12小时）

2:30 关键问题：攻击者怎么进来的？

入侵的主机是财务部门的一台普通办公机，不是服务器。查EDR日志发现入口点：

2026-05-27 14:23:05  用户 zhangsan 打开邮件附件 "2026年Q2财务报表.zip"
2026-05-27 14:23:08  解压得到 "2026年Q2财务报表.exe"（伪装图标为Excel）
2026-05-27 14:23:09  双击执行，释放恶意DLL到 C:\ProgramData\microsoft\db\
2026-05-27 14:23:15  创建计划任务实现持久化
2026-05-27 14:23:20  连接C2服务器，开始接收指令

钓鱼邮件，老套路了。但他们的邮件网关没拦住，原因是这个样本用了比较新的免杀技术，VirusTotal上检测率只有12/70。

3:00 扩大排查范围

如果一台机器中了，很可能还有其他机器也中了。用IOC做全网扫描：

# 文件IOC
hash: e5f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1  (mss.dll)

# 网络IOC
IP: 45.xx.xx.xx
Domain: update-service.xyz

# 行为IOC
- 计划任务名：MicrosoftEdgeUpdateCore
- 服务名：EdgeUpdateSvc

用SIEM查所有匹配这些IOC的日志，发现还有3台机器有相同的计划任务和DLL文件。这3台机器还没开始横向移动，处于C2待命状态。

6:00 清除与加固

对4台受感染的主机做全面清除：

# 删除恶意计划任务
schtasks /delete /tn "MicrosoftEdgeUpdateCore" /f

# 删除恶意DLL
del "C:\ProgramData\microsoft\db\mss.dll"

# 删除恶意服务
sc delete EdgeUpdateSvc

# 检查注册表持久化
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

⚠️ 踩坑提醒：只删文件不够，还得检查注册表、WMI订阅、启动文件夹等所有持久化位置。第一次清除的时候漏了WMI订阅，导致恶意代码又复活了。

第三阶段：溯源与复盘（12-48小时）

12:00 攻击时间线还原

把所有日志汇总，画出完整的攻击时间线：

时间事件影响 05-27 14:23钓鱼邮件投递zhangsan主机沦陷 05-27 14:25C2通信建立攻击者获得远程控制 05-27 18:00-22:00内网侦察（空闲时段）攻击者摸清内网拓扑 05-28 01:30横向移动尝试SMB扫描254个IP 05-28 02:17SIEM告警触发我们开始响应

从钓鱼到被发现，攻击者在内网潜伏了约12小时。如果SIEM的检测规则没配好，可能潜伏更久。

24:00 复盘会

跟客户团队开了复盘会，总结三个核心问题：

• 邮件网关的沙箱检测能力不足：样本用了比较新的免杀技术，静态检测和沙箱都没拦住。建议增加Sandbox的执行时间（从2分钟改成5分钟）和行为检测规则
• 终端没有应用白名单：explorer.exe直接拉起了伪装的svchost.exe，如果启用了AppLocker或WDAC，这类进程伪装根本执行不了
• SMB横向移动检测规则是后来才加的：如果这个规则早加12小时，攻击者在侦察阶段就会被发现，不会等到真正横向移动

我的5条应急响应教训

• 先遏制再取证，但遏制方式要选对：断网是最后手段，VLAN隔离是更好的选择
• IOC扫描要全面，不能只查已知的那一台：一台中了，全网都得查
• 清除要彻底，持久化位置要逐个检查：漏一个就前功尽弃
• 攻击时间线一定要画：不画时间线，根本不知道攻击者在内网干了多久
• 复盘比修复重要：修完了不复盘，下次还会被同样的方式打穿

写在后面

这次应急响应让我最深的感触是：安全设备不是买了就完事的。SIEM的检测规则、邮件网关的沙箱配置、终端的白名单策略，每一项都需要根据实际环境持续调优。

48小时内完成了从告警到溯源的全流程。如果没有SIEM告警，这个攻击者可能在内网潜伏几周甚至几个月。

安全运营，拼的就是"发现速度"。

---

关注「安全值班室」公众号

每天AI安全早报 + 实战攻防案例 + 网安学习路线连载