1. 事件背景与应急响应启动那天下午办公室的网络突然变得异常缓慢紧接着几台关键业务服务器的屏幕上开始弹出刺眼的红色弹窗上面用蹩脚的英文写着“你的所有文件都已被加密请在72小时内支付0.5个比特币到指定地址否则密钥将被销毁。” 空气瞬间凝固了。这不是演习我们遭遇了勒索病毒攻击。作为团队的安全负责人我立刻意识到这不仅仅是几台电脑中招那么简单。从弹窗的样式、加密文件的后缀名.solar_lock以及攻击的精准度来看这很可能是一起针对性的攻击而非广撒网的随机感染。我们迅速启动了最高级别的应急响应预案。第一步不是慌乱地拔网线而是冷静地评估影响范围。通过内部监控系统的初步扫描我们发现受感染的服务器主要集中在开发测试区和部分文件服务器核心生产数据库和交易系统暂时幸免这算是不幸中的万幸。但攻击者已经在内网横向移动必须立刻阻断其传播链条同时为后续的溯源分析保留关键证据。这次事件被我们内部命名为“Solar事件”不仅仅因为病毒的后缀名更因为我们需要像应对一次突如其来的“日食”一样在黑暗降临后系统地、有策略地让一切重见光明。整个应急响应过程就是一场与时间赛跑、与攻击者斗智斗勇的实战。下面我将完整复盘从遏制、分析到根除、恢复的全过程并重点分享我们如何通过流量分析这张“网”捕捉到了攻击者的蛛丝马迹。2. 应急响应第一阶段快速遏制与初步取证应急响应的首要原则是“控制事态减少损失”。在确认安全事件后任何拖延都可能导致灾难性的扩散。2.1 隔离与断网策略我们的第一反应不是去找杀毒软件而是执行网络隔离。对于已确认感染的服务器我们立即通过网络管理设备将其所在VLAN的访问控制列表ACL修改为“只出不进”模式。这意味着受感染主机无法主动连接内网其他机器但其网络流量仍能被我们的监控探针捕获这对于后续的流量分析至关重要。同时我们切断了该区域到互联网的直接出口防止病毒与命令控制C2服务器通信或泄露数据。注意直接物理拔网线或关机是最简单粗暴的方法但会丢失内存中的进程、网络连接等易失性证据不利于溯源。采用网络层隔离如ACL、防火墙策略是更优选择能在阻断攻击的同时保留分析线索。2.2 现场证据固定在隔离的同时取证小组进场。对于Windows服务器我们使用了预先准备好的干净U盘启动的WinPE环境运行一系列脚本工具进行内存转储和磁盘镜像。关键命令包括使用DumpIt或WinPMEM获取完整内存镜像.mem文件。使用FTK Imager或dd命令对系统盘进行只读的磁盘镜像.E01或.raw文件。通过pslist或volatility的命令行版本快速提取运行进程、网络连接和加载模块列表。这些操作都在断网环境下进行确保不会触发病毒的任何后续破坏行为。初步的进程列表显示除了正常的系统进程外存在一个名为svchost_helper.exe的异常进程其路径位于C:\Windows\Temp\下这是一个高危信号。2.3 样本提取与静态分析我们从临时目录和注册表自启动项中提取到了疑似病毒的样本文件。为了避免在分析环境中误执行我们将其上传到多个在线沙箱如VirusTotal、Any.Run、微步云沙箱进行快速扫描和行为分析。报告很快返回确认该样本为“SolarLocker”勒索病毒的新变种其行为特征包括遍历磁盘加密特定后缀的文件如.doc, .xls, .pdf, .sql, .vmx等。在每个被加密的目录下生成README_SOLAR.html勒索信。尝试通过TCP 443端口与多个境外IP通信。利用合法的Windows进程如rundll32.exe,msiexec.exe进行进程注入以规避检测。静态分析还发现样本使用了RSA-2048和AES-256算法组合进行加密这意味着在没有私钥的情况下暴力破解几乎不可能。这坚定了我们不以支付赎金为主要解决路径的决心。3. 应急响应第二阶段深度流量分析与攻击链还原在完成初步遏制和样本分析后我们进入了更关键的阶段通过分析网络流量还原攻击者的入侵路径攻击链找到安全短板。我们部署的全流量威胁检测系统NTA记录了近30天的原始网络数据包PCAP这是我们的“宝藏”。3.1 确定分析时间窗口首先需要确定攻击发生的大致时间。我们结合以下信息进行交叉验证用户最早报告异常的时间点。受感染服务器上文件被修改的时间戳注意时区问题。样本在沙箱中显示的首次活动时间。 最终我们将分析重点锁定在事件发生前48小时至事件发生后2小时这个时间窗口。3.2 使用Wireshark与Zeek进行初级筛选面对海量的PCAP文件直接打开分析是不现实的。我们采用分层筛选策略协议筛选我们首先过滤出与初始感染可能相关的协议如http、dns、smb。很快在HTTP流量中我们发现了一台内部开发机在事件发生前访问了一个伪装成“软件更新日志”的恶意域名update.software-log[.]top下载了一个log_viewer.msi文件。这极有可能是攻击入口。异常连接筛选我们过滤出目标端口为常见远程控制或C2端口的流量如tcp.port 4444、tcp.port 53DNS隧道可能。发现多台受感染主机在加密开始前均向一个IP185.xxx.xxx.xxx的443端口发起了心跳连接每次连接持续约10秒传输数据量很小约2KB这符合C2通信的特征。使用Zeek原Bro日志进行行为分析Zeek生成的连接日志conn.log、HTTP日志http.log和DNS日志dns.log是结构化数据更便于分析。我们编写了简单的Python脚本关联这些日志在http.log中找到log_viewer.msi的下载记录获取源IP受害机和目标主机名。在conn.log中追踪该源IP后续的所有外联连接发现了到185.xxx.xxx.xxx:443的周期性连接。在dns.log中发现该受害机在下载MSI文件前曾大量查询与软件、日志相关的子域名存在域名生成算法DGA试探的嫌疑。3.3 攻击链拼图结合样本分析、日志分析和流量分析我们还原了相对完整的攻击链阶段攻击活动流量/日志证据利用的弱点初始入侵员工点击钓鱼邮件链接或访问被攻陷的第三方网站重定向至恶意域名。HTTP流量访问update.software-log[.]top下载log_viewer.msi。员工安全意识不足Web过滤策略不完善。载荷投递MSI安装包被执行释放勒索病毒本体svchost_helper.exe到临时目录并添加计划任务实现持久化。无直接网络流量但样本静态分析发现持久化代码。终端缺乏应用程序白名单默认允许MSI安装。C2通信病毒成功运行后向C2服务器185.xxx.xxx.xxx:443发送上线心跳并接收加密密钥或指令。周期性、短连接的TLS/SSL流量目标端口443。出站流量缺乏对加密流量的内容检测如SSL解密。横向移动病毒利用窃取到的本地凭据或漏洞如EternalBlue尝试通过SMB协议在内网扫描和传播。大量smb协议流量从感染源发往内网多个IP的445端口。内网未严格划分区域老旧系统未打补丁同一口令在多台服务器使用。数据加密病毒开始遍历网络共享和本地磁盘加密文件并生成勒索信。网络流量骤降因加密消耗CPU但之前会有大量SMB文件访问流量。关键文件未实施最小权限访问控制缺乏文件完整性监控。这张攻击链图清晰地指出了我们防御体系中的多个短板边界检测失效、内网隔离薄弱、终端防护缺失、加密流量盲区。3.4 威胁情报关联我们将捕获的恶意域名update.software-log[.]top和C2 IP185.xxx.xxx.xxx提交给威胁情报平台进行查询。反馈显示该IP在过去一个月内与多个已知的勒索软件即服务RaaS团伙有关联且该域名是新近注册的存在“域名前置”或“快速切换”的特点。这进一步证实这是一起有组织的、可能针对我们行业的攻击。4. 应急响应第三阶段根除、恢复与加固在彻底摸清攻击路径后我们开始执行根除和恢复计划。4.1 彻底根除威胁凭证重置全面重置所有受影响服务器、甚至整个域的管理员密码和本地账户密码因为攻击者可能已窃取凭据。漏洞修补立即为所有内网主机安装涉及横向移动的漏洞补丁如MS17-010并关闭不必要的SMB服务。恶意项目清除根据取证结果编写统一的清理脚本在所有主机上搜索并删除病毒文件、相关的计划任务、服务项和注册表键值。例如使用PsExec工具批量执行命令psexec hostlist.txt -s cmd /c del /f /q C:\Windows\Temp\svchost_helper.exe schtasks /delete /tn \SolarUpdate\ /f主机排查利用EDR终端检测与响应工具或自编脚本对所有在线主机进行扫描检查是否存在相同的IOC入侵指标如文件哈希、进程名、网络连接等确保没有残留。4.2 数据恢复与业务重启由于我们有较为完善的备份策略数据恢复成为可能隔离备份介质首先确认备份服务器本身未被感染并立即将其与生产网络隔离。恢复验证从最近的干净备份感染发生前恢复少量非关键文件验证其完整性和可用性。非常重要的一步是在恢复前对备份数据进行病毒扫描防止备份中已存在病毒。分阶段恢复按照业务优先级分批次恢复服务器。先恢复基础架构如AD、DNS再恢复应用服务器最后恢复数据。每恢复一台都进行严格的安全检查和监控观察异常流量。重建系统对于感染严重、难以彻底清理的系统我们选择了从纯净镜像开始重建只恢复必要的数据和应用配置。这虽然耗时但安全性最高。4.3 安全加固与闭环事件处理完不是终点而是安全加固的起点。我们制定了详细的加固方案网络架构优化重新规划VLAN在开发测试区与核心生产区之间部署更严格的防火墙策略仅允许必要的业务端口通行并启用入侵防御IPS功能。加密流量解密在网络边界部署SSL解密设备对出站和入站的加密流量进行解密和检测消除盲区。终端强化在所有服务器和工作站上推行应用程序白名单禁止在临时目录执行程序。加强邮件网关的过滤能力增加对恶意附件的动态沙箱检测。增强监控与告警基于本次事件的IOC在SIEM安全信息和事件管理系统中创建新的关联规则。例如“同一内网IP在短时间内尝试连接多台主机的445端口”和“进程从C:\Windows\Temp\路径启动并尝试外联”应产生高优先级告警。演练与培训将本次事件整理成案例纳入每年的红蓝对抗演练。同时对全体员工进行新一轮的钓鱼邮件识别和安全意识培训。5. 实战心得与高级流量分析技巧复盘整个“Solar事件”流量分析无疑是贯穿始终、扭转局面的关键。以下是一些在实战中积累的、教科书上不一定写的经验和技巧5.1 流量分析的“望闻问切”望全局观察不要一开始就陷入细节。先用capinfos工具查看PCAP文件的总览包数量、数据量、持续时间、主要协议分布对流量全貌有个概念。突然激增的某种协议流量如SMB、RDP往往是异常点。闻嗅探异常关注“低频”和“高频”事件。一个内网IP突然去解析大量从未见过的域名低频行为或者同一IP在极短时间内产生海量的DNS查询高频行为都可能是恶意软件在寻找C2或进行数据外传。问交互式查询熟练使用Wireshark的显示过滤器和着色规则。例如可以将tcp.flags.syn1 and tcp.flags.ack0仅SYN包标记为红色快速发现端口扫描行为。将http.request.uri contains “.php” and ip.src内网IP标记为黄色监控内网可能的Web攻击。切深度解析对于加密流量TLS/SSL虽然看不到内容但元数据价值巨大。关注TLS握手中的“服务器名称指示”SNI这能暴露访问的域名。JA3/JA3S指纹可以用于识别恶意软件使用的特定SSL/TLS客户端/服务器指纹即使IP和域名变了指纹可能不变。5.2 内存与流量结合分析本次事件中我们从内存转储中提取到了病毒进程尝试连接C2的IP和端口这个信息与流量侧抓到的连接记录完全吻合形成了证据链的闭环。使用Volatility框架的netscan或connscan插件可以在内存中看到已建立或正在尝试的网络连接即使连接在取证时已断开。这比单纯看防火墙日志或Netstat更可靠。5.3 构建内部威胁狩猎线索基于此次事件我们固化了几条用于主动威胁狩猎的流量线索内部主机访问“动态DNS”提供商域名很多恶意软件使用DynDNS、No-IP等服务来隐藏C2。在DNS日志中狩猎对这些服务商域名的查询。ICMP隧道检测检查ICMP流量的大小和频率。正常的ping包很小且规律而用于隧道传输的ICMP包通常载荷大、发送频率高。可以用Wireshark过滤器icmp and frame.len 100进行初步筛选。SMB匿名登录尝试在SMB流量中过滤smb2.session_setup.request且ntlmssp.auth.username “”这可能是攻击者在尝试匿名访问共享。5.4 工具链的自动化整合手动分析单次事件可行但无法应对持续威胁。我们开始将部分流程自动化使用Zeek实时生成日志并接入ELK栈Elasticsearch, Logstash, Kibana进行可视化。在Kibana中制作仪表盘实时展示异常外联、端口扫描、可疑域名解析等。编写Python脚本定期将Zeek的conn.log与威胁情报 feeds如AlienVault OTX、微步在线的API进行比对自动标记与恶意IP/域名通信的内网主机。将Wireshark的过滤和分析过程通过tshark命令行版Wireshark写成脚本实现批量PCAP文件的快速IOC扫描。这次“Solar事件”是一次深刻的教训也是一次宝贵的能力淬炼。它告诉我们没有绝对的安全但扎实的应急响应流程、尤其是基于流量的深度分析能力能让我们在遭受攻击时不再盲目能够快速止血、看清对手、修复短板。安全建设是一个持续的过程而每一次实战复盘都是让防御体系变得更坚固的基石。真正的安全不在于永远不被攻破而在于被攻破后能以多快的速度发现、多深的理解分析、以及多彻底的恢复与提升。