1. 项目概述一次典型的内部网络安全事件那天下午监控平台的告警突然亮起不是那种常规的扫描告警而是一条关于某个内部业务系统存在可疑POST请求的日志。系统本身部署在内网不直接对外暴露也就是我们常说的“不出网”环境。这种环境下的安全事件往往更棘手因为攻击链可能更隐蔽危害也可能更大。作为安全团队的成员我第一时间被拉进了应急响应小组。初步排查目标系统是一个基于Java开发的Web服务大量使用了Fastjson进行数据序列化与反序列化。结合告警的上下文和近期漏洞情报一个词立刻浮现在脑海Fastjson反序列化漏洞。接下来的几个小时就是一场与时间赛跑的“破案”过程核心线索不是系统日志而是网络流量。这篇文章我就来复盘一下如何在没有直接外联证据不出网的情况下通过深度分析流量特征一步步锁定并证实了这次Fastjson漏洞攻击希望能给面临类似场景的同行一些参考。2. 应急响应的核心思路与前期研判面对一个不出网环境的安全告警常规的“看外联IP、查外发流量”思路行不通。我们的战场被限定在了内部网络。但这并不意味着无计可施恰恰相反内网流量往往保留了更原始、更完整的攻击痕迹因为攻击者通常认为这里“更安全”会放松警惕。我的核心思路很明确将攻击行为视为一个“黑盒”输入而我们的应用和网络就是“传感器”通过分析这个“黑盒”输入在“传感器”上引发的异常波动来反推攻击的本质。2.1 环境隔离与初步信息收集接到告警后第一步不是直奔服务器而是建立信息隔离区。我立即联系了系统负责人和网络团队做了三件事流量镜像在核心交换机上对目标服务器的业务网卡入口流量进行全量镜像保存到独立的分析平台。这是后续所有分析的基石必须保证流量的完整性和原始性。系统快照在确保业务可接受的前提下当时是非高峰时段对服务器的内存、关键进程列表、网络连接状态进行了快照保存。对于Java应用特别关注了jstack线程栈和jmap -histo对象直方图的输出。日志拉取收集了应用日志如Log4j2、中间件日志Tomcat access/error log、系统日志/var/log/messages以及任何现有的安全设备如WAF、IDS的告警日志。注意在应急初期切忌直接登录服务器进行“大刀阔斧”的查杀或重启。这可能会破坏现场证据如内存马、进程信息让攻击溯源变得困难。我们的原则是“先取证后处置”。2.2 基于告警的假设驱动分析告警信息显示可疑请求的URL路径是一个正常的业务API接口但Payload部分异常。这立刻指向了两种可能1. 业务逻辑漏洞如越权、注入2. 通用组件漏洞如反序列化。结合该系统大量使用Fastjson处理JSON请求的背景以及近期Fastjson 1.2.80及以下版本反序列化漏洞CVE-2022-25845等的威胁情报我初步将调查重心放在了Fastjson漏洞上。这个假设成为了后续分析的“导航仪”。我需要从海量的流量数据中寻找能验证或推翻这个假设的证据。不出网环境下的攻击攻击者目标通常是植入内存马、窃取内网敏感数据、作为横向移动的跳板。因此流量特征会围绕“漏洞利用”、“后门通信”、“内网探测”这几个阶段展开。3. 关键流量特征解析与攻击链还原有了镜像流量我使用Wireshark和Zeek原名Bro结合自研脚本进行深度分析。不出网流量的分析关键在于识别“异常”而非“恶意”。因为所有流量源IP都是内网地址传统IP信誉库失效。以下是我锁定的几个关键特征及其分析过程。3.1 Fastjson漏洞利用流量的“指纹”Fastjson反序列化漏洞的利用其流量特征在HTTP层有比较明显的印记。我在筛选出的可疑时间段的HTTP请求中发现了以下共性type属性指向非常规类这是Fastjson反序列化的核心特征。攻击者通过type指定一个目标类Fastjson会尝试实例化并调用其setter或getter方法。在攻击流量中我看到了诸如com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl、org.apache.tomcat.dbcp.dbcp2.BasicDataSource这类明显不属于业务逻辑的类名。这些是公开漏洞利用PoC中常用的类用于构造利用链。{ type: com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl, _bytecodes: [yv66vgAAADQA...base64编码的恶意字节码], _name: a.b, _tfactory: {}, _outputProperties: {} }为什么这是关键证据正常的业务JSON数据type如果使用指向的应该是业务DTOData Transfer Object类如com.xxx.service.dto.UserDTO。出现Java标准库或第三方库中的特定类且包含_bytecodes等敏感字段基本可以断定是攻击行为。POST数据体结构异常正常的业务JSON结构相对规整字段名有业务含义。而攻击Payload为了满足反序列化链的调用条件结构往往嵌套复杂会出现大量空对象{}、空数组[]以及像_outputProperties、_name这类具有特定含义的属性名。通过编写简单的脚本统计JSON的嵌套深度和特定关键词出现频率可以快速筛选出异常请求。Content-Type与数据体不匹配的“伪装”部分攻击流量试图伪装。虽然POST请求的Content-Type标头是application/json但数据体开头却可能包含无关字符或尝试进行编码混淆。不过在本次事件中攻击流量相对“原始”没有做深度混淆。3.2 漏洞利用成功后的“后门”流量特征如果Fastjson漏洞利用成功攻击者下一步通常是在内存中植入Webshell内存马或执行系统命令。由于不出网命令执行结果或Webshell的通信都会在内部网络产生流量。我发现了紧随漏洞利用请求之后的一些异常会话“冰蝎”型Webshell通信特征这是内网渗透中最常见的工具之一。其流量特征较为明显静态路径动态参数存在对某一个特定URL路径如/upload、/static/xx.jsp的频繁POST请求每次请求的URL完全相同但参数如pass、c的值是加密且变化的。这与正常用户访问或API调用模式不符。固定的HTTP头部“冰蝎”3.0以后版本虽然加密能力增强但其请求头中的Accept、Accept-Language、Accept-Encoding等字段的值长度固定且每次请求几乎一模一样。正常浏览器的这些头部会因请求内容稍有差异。通过Zeek脚本提取同一源IP的请求头进行对比很容易发现这种“机器式”的规律性。Content-Type: application/octet-stream这是“冰蝎”上传文件或执行特定操作时的一个特征。正常的Web应用很少使用这个Content-Type来传输业务数据。“哥斯拉”型Webshell通信特征另一个常用工具其特征点有所不同Cookie尾部异常分号在部分版本中哥斯拉Webshell连接的请求Cookie字段最后一个键值对后面会多一个分号如Cookie: key1value1; key2value2;。而标准HTTP和浏览器实现最后一个键值对后不应有分号。这是一个非常细微但有效的特征。长连接保持为了维持Shell会话哥斯拉会设置Connection: keep-alive并保持较长时间的TCP连接与同一内网IP进行多次高频、短间隔的请求-响应交互模拟“心跳”或持续操作。命令执行回显的流量模式攻击者可能不植入Webshell而是直接通过漏洞执行系统命令如whoami、ipconfig /all、net user。其流量特征表现为请求与响应的不对称性一个简短的POST请求携带了编码后的命令却收到了一个较长的HTTP响应体。这个响应体内容通常是命令执行结果的输出经过Base64或URL编码。响应内容包含系统信息通过解码响应内容发现了Windows系统命令行输出的典型格式如C:\Users\提示符、中文乱码等直接证实了系统命令已被执行。实操心得在分析这些后门流量时不要只盯着单个数据包。要建立“会话”Conversation视角在Wireshark中跟踪完整的TCP流Follow TCP Stream。这样你能看到一次交互的完整明文或加密前的原始数据对于识别加密Webshell的固定头部、尾部特征非常有帮助。例如冰蝎的流量在TCP流视图下往往能看到请求体中存在固定的“魔术字节”或结构。3.3 横向移动与内网探测的痕迹攻击者进入一台内网机器后绝不会满足于此。我通过分析该服务器作为客户端向外发起的连接发现了横向移动的迹象对内网端口的扫描从受害服务器上发现了向大量内网IP的445SMB、3389RDP、22SSH、6379Redis等端口的SYN连接尝试。这些连接很多是“半开连接”SYN_SENT说明目标端口未开放。这种由内网一台服务器发起的、针对其他内网服务的端口扫描行为是典型的横向移动前期侦查。异常协议连接尝试发现了向其他服务器1433MSSQL、3306MySQL端口的连接并伴随有类似SQL语句的TCP载荷。这可能是攻击者在尝试数据库弱口令爆破或利用数据库漏洞。SMB、RDP协议通信发现了与个别内网主机成功的445端口通信流量中携带了NTLM认证相关数据。这极有可能是攻击者在尝试传递哈希Pass-the-Hash或利用永恒之蓝EternalBlue类漏洞进行横向扩散。如何关联这里的关键时间线。端口扫描和异常连接请求都发生在首次Fastjson攻击流量之后几分钟内。这就构成了一个完整的攻击链闭环外部攻击者通过某种方式可能是鱼叉邮件、水坑攻击导致的内网用户中招再由该主机作为跳板向内网目标服务器发送Fastjson恶意Payload → 利用成功在服务器上执行命令或植入Webshell → 通过该Webshell作为据点发起对内网其他主机的扫描和攻击尝试。4. 深度流量取证与攻击者画像勾勒仅仅知道被攻击了还不够应急响应的目标是“抑制、根除、恢复、总结”。通过深度流量分析我们可以勾勒出攻击者的行为画像为根除隐患提供精准方向。4.1 攻击载荷Payload解码与工具识别我将捕获到的Fastjson攻击Payload中的_bytecodes字段Base64编码提取出来进行解码。解码后得到的是一个Java类文件的字节码。通过使用javap -c反汇编或者直接使用一些在线Java字节码分析工具可以大致看出这个类的功能。在我分析的案例中该字节码是一个简单的类其静态代码块static{}中包含了一段通过Runtime.getRuntime().exec()执行系统命令的代码命令是下载一个远程脚本并执行。进一步我分析了该下载命令指向的内网地址另一个已被攻陷的肉鸡并从其流量中发现了与公开的“哥斯拉”管理端通信的特征。由此可以推断攻击者使用的可能是公开的Fastjson漏洞利用工具如JNDI注入攻击工具配合哥斯拉进行后续控制。工具链的相对固定也说明攻击者可能并非高级APT组织而是利用现成工具的常规黑产或脚本小子。4.2 攻击路径与入口点推测这是不出网应急中最难也是最重要的一环。服务器本身不对外攻击流量从何而来我通过以下步骤进行推测溯源攻击源IP所有攻击流量的源IP都是一个内网地址假设为10.1.2.100。这显然不是最终攻击者而是一个“跳板机”。分析跳板机立刻协调网络团队获取10.1.2.100主机的信息。发现这是一台运维人员的办公电脑。检查该电脑在攻击时间前后的网络连接和进程历史通过EDR终端记录发现其浏览器曾访问过一个被标记为“钓鱼”的外部网址随后该主机上出现了异常的Java进程网络活动。还原攻击路径综合所有信息最可能的攻击路径是运维人员办公电脑10.1.2.100访问钓鱼网站 → 网站利用浏览器漏洞或诱导下载在其电脑上植入了一个木马或劫持了浏览器 → 该木马以办公电脑为跳板对内网服务器目标发起了Fastjson漏洞攻击。攻击者利用了内部人员的主机作为“桥头堡”绕过了网络边界防护。4.3 影响范围评估通过分析受害服务器已沦陷向外发起的扫描流量我整理出了一份“潜在感染清单”直接扫描目标列出了所有被扫描的IP和端口。成功建立连接的主机特别是那些有SMB、RDP等成功会话的主机需要立即进行隔离和检查。内部敏感系统扫描列表中包含了数据库服务器、版本控制服务器Git、文件共享服务器等。这些系统一旦被攻破后果严重。这份清单成为了后续“抑制”阶段的关键输入安全团队据此迅速开展了内网隔离和排查工作。5. 应急处置措施与长效加固建议基于流量分析得出的结论我们迅速采取了行动。5.1 立即处置抑制与根除隔离网络立即在防火墙上切断了受害服务器10.1.2.200和跳板机10.1.2.100与内网的所有非必要通信只保留管理通道。清除后门对受害服务器由于发现了内存马特征我们选择了最彻底的方式备份业务数据后直接下线该实例。在隔离环境中对磁盘镜像进行取证分析确认Webshell文件位置和攻击者创建的后门账户然后使用干净的镜像重新部署应用。严禁直接重启在确认内存马存在的情况下重启会导致内存马消失但磁盘上的后门文件可能被设置为持久化如写入计划任务、服务重启后会被重新加载。必须先清理文件层面的后门。排查跳板机对运维人员的电脑进行全盘杀毒、恶意进程清理并重置了密码。检查了浏览历史、下载记录和启动项。扫描潜在目标根据“潜在感染清单”对其他被扫描的主机进行漏洞扫描和日志审查确认是否已被渗透。5.2 漏洞修复与配置加固升级与修复将业务系统使用的Fastjson组件紧急升级到最新安全版本当时是1.2.83或更高并确保开启了SafeMode或使用了官方推荐的安全配置如指定反序列化白名单。// 使用SafeMode是最根本的解决方案 ParserConfig.getGlobalInstance().setSafeMode(true);网络层面细化网络分区强化VLAN和防火墙策略遵循最小权限原则。即使在内网Web服务器也不应能直接访问数据库服务器的管理端口、运维区的SSH端口等。部署内部IDS/IPS在核心交换节点部署网络入侵检测/防御系统配置规则检测Fastjson攻击特征、冰蝎/哥斯拉流量特征、横向移动扫描行为等。出站流量管控虽然是不出网服务器但仍需严格限制其主动向外发起的连接仅允许访问必要的更新源或依赖服务。主机与应用层面强化EDR部署确保所有服务器和终端安装有效的终端检测与响应系统能够检测异常进程、网络连接和文件操作。日志集中与审计将所有服务器、中间件、数据库的日志集中收集到SIEM安全信息与事件管理平台。针对Fastjson可以监控日志中是否出现type属性为非法类的告警。WAF规则更新在内部的WAF或应用网关设备上更新规则集添加对已知Fastjson漏洞攻击Payload的检测和拦截。5.3 监控与预警优化本次事件暴露了原有监控的不足。我们后续优化了异常流量建模基于此次攻击的流量特征建立了内部异常流量基线模型。例如监控同一内网IP对特定服务端口如445的扫描行为监控HTTP请求中Content-Type: application/octet-stream但URL并非文件上传接口的情况。威胁情报集成订阅了Fastjson等相关组件的漏洞情报feed一旦有新的漏洞或PoC公开能第一时间在流量和日志层面添加检测规则。演练常态化定期组织内部红蓝对抗演练模拟不出网环境的渗透攻击检验安全监测和应急响应流程的有效性。6. 总结与反思不出网应急的“道”与“术”这次应急响应让我深刻体会到对于不出网环境流量分析是“眼睛”而正确的安全架构和运维习惯是“免疫系统”。“术”的层面要熟练掌握各类攻击工具的流量特征。这需要持续学习建立自己的知识库。例如不仅要记得“冰蝎的Accept头长度固定”还要理解为什么它要这么做为了绕过基于流量行为异常的检测。分析时要结合多种特征进行综合判断避免单一特征误报。“道”的层面必须坚持几条铁律假设 breach假设已被攻破不要幻想内网是绝对安全的。零信任架构的理念至关重要任何访问请求都必须经过验证和授权。纵深防御在网络、主机、应用、数据各个层面都部署防护和检测措施。即使攻击者突破了一层下一层也能提供缓冲和告警。最小权限无论是服务器间的访问还是人员的账号权限都必须遵循最小化原则。本次事件中如果运维电脑没有直接访问生产服务器的权限攻击链就可能中断。持续监控与响应安全运营SecOps不是一次性的项目而是持续的过程。需要建立7x24小时的监控和响应能力对告警进行闭环处理。最后我想说一次成功的应急响应技术分析只占一半另一半是高效的团队协作、清晰的沟通和规范的流程。从网络团队提供流量镜像到系统团队配合下线机器再到业务团队理解风险接受短暂的业务中断每一个环节都不可或缺。把这次复盘写下来既是对自己工作的总结也希望能成为一个可供参考的案例。安全之路道阻且长唯有多看、多练、多思考才能在与攻击者的对抗中多一分胜算。