1. 项目概述：从应急响应到内存马查杀的实战闭环

在蓝队日常的应急响应工作中，最让人头疼的莫过于那些“看不见、摸不着”的威胁。传统的文件型Webshell，好歹还有个落地文件可以溯源、删除。但内存马不同，它像幽灵一样驻留在JVM的运行时内存中，不落盘、不写文件，仅凭常规的文件扫描和日志审计，你很可能一无所获。我经历过多次护网和实战应急，发现攻击者越来越倾向于使用这种“无文件”攻击手段，尤其是在攻防演练后期，防守方清理了所有Webshell文件后，攻击者通过内存马依然能维持权限，实现“起死回生”。这个项目标题“蓝队技能-应急响应篇&Web内存马查杀&JVM分析&Class提取&诊断反编译&日志定性”，精准地勾勒出了一条从应急响应告警开始，到最终定位、分析、清除内存马并完成事件定性的完整技术链路。它不是单一工具的罗列，而是一套结合了JVM底层原理、字节码分析与实战经验的组合拳。对于每一位需要守护Web应用安全的蓝队成员、安全运维乃至研发人员来说，掌握这套技能，意味着你能在最棘手的无文件攻击场景下，依然拥有清晰的排查思路和有效的处置手段。

2. 内存马的本质与JVM运行时分析基础

2.1 内存马为何难以察觉：从类加载机制说起

要理解内存马，必须先理解JVM的类加载机制。我们都知道，一个Java类从.java源文件到被JVM执行，需要经过编译（成.class字节码文件）和加载两个阶段。传统Webshell依赖的是文件系统中的.class或.jsp文件。而内存马的“无文件”特性，其核心在于绕过了“从文件系统加载”这一步。

JVM提供了ClassLoader.defineClass()方法，这个方法的神奇之处在于，它可以直接接收一个字节数组（即.class文件的二进制内容），并在内存中将其定义为一个可用的Class对象。攻击者正是利用这一点，通过Web应用已有的漏洞（如反序列化、表达式注入、文件上传+代码执行等），将恶意类的字节码直接送入JVM内存并加载，从而完成“无文件”植入。

一个关键认知误区：很多人认为内存马完全无痕。实际上，它的“无痕”仅针对文件系统。在JVM的运行时内存中，这个恶意类被加载后，与正常业务类并无二致，都会存在于Metaspace（或JDK8之前的PermGen）中，被对应的ClassLoader管理，并可能在堆中创建实例。因此，排查的战场从磁盘文件转移到了JVM运行时内存。

2.2 内存马的常见“藏身之处”与攻击路径

根据其“寄生”和“篡改”的方式，内存马主要分为三大类，理解这些类别是有效排查的前提：

第一类：动态注册型内存马这是最常见的一类。攻击者利用Web容器（如Tomcat、Spring）允许动态添加组件的特性，在运行时向容器注册新的Servlet、Filter或Listener。

• Filter型内存马：最为流行。因为Filter可以拦截所有请求，攻击者注册一个路径匹配/*的恶意Filter，就能接管所有流量。
• Servlet型内存马：注册一个特定路径的Servlet，作为后门入口。
• Listener型内存马：通过监听特定事件（如ServletRequestListener）来执行恶意代码。
• Spring Controller型内存马：在Spring MVC框架中，动态向RequestMappingHandlerMapping注册新的控制器（Controller）。

排查关键点：这类内存马会新增组件。因此，排查思路是获取当前容器内所有已注册的组件列表，与已知的正常基线进行对比，找出“多出来”的那个。

第二类：字节码篡改型内存马这类内存马更为隐蔽，它不新增组件，而是直接修改JVM中已加载的、用于处理请求的关键类的字节码。例如，攻击者利用Java Agent技术，附着（Attach）到目标JVM进程，修改javax.servlet.http.HttpServlet.service()方法的实现，在其中插入恶意逻辑。

• 常见篡改目标：ApplicationFilterChain.internalDoFilter(),HttpServlet.service(), Spring的DispatcherServlet.doDispatch()等请求处理链上的关键方法。
• 工具：常借助javassist或ASM等字节码操作库实现动态修改。

排查关键点：这类内存马修改了现有类。因此，排查思路是检查关键类的字节码是否与预期的原始版本一致，或者通过监控类字节码的变更来发现异常。

第三类：利用框架特性注入型内存马某些框架提供了动态添加路由或处理器的能力。例如，在基于Netty的Web框架中，攻击者可能动态添加一个ChannelHandler；在某些RPC框架中，动态注册一个服务。这类内存马高度依赖于具体中间件和框架的API。

排查关键点：需要熟悉对应框架的运行时模型和API，检查其核心路由表或处理器注册表。

3. 实战查杀：基于JVM诊断工具的动态分析

当接到应急响应通知，怀疑存在内存马时，我们首要的目标是“看见”它。直接重启服务固然能清除内存马，但会丢失所有运行时状态和攻击证据，并非上策。我们应该优先使用JVM诊断工具进行在线分析。

3.1 利器首选：Arthas的实战应用

Arthas是阿里开源的Java诊断工具，它通过Agent机制动态注入目标JVM，提供了丰富的命令行诊断功能，是排查内存马的首选工具。

第一步：快速附着与基础信息收集假设目标应用进程ID为12345。

# 启动Arthas并附着到目标进程 java -jar arthas-boot.jar 12345

附着成功后，我们先进行一轮快速扫描，寻找可疑迹象：

# 1. 查看所有已加载的类中，是否包含常见恶意关键词（如shell, memshell, eval, inject, agent等） sc *shell* sc *memshell* sc *eval* sc *inject* sc *agent* # 2. 特别关注匿名内部类（类名中包含$），攻击者为了省事，常使用匿名类实现恶意逻辑 sc *\$* # 3. 列出所有ClassLoader，观察是否有异常的或自定义的ClassLoader classloader -l

我的实操心得：单纯搜索关键词命中率不高，因为攻击者会混淆类名。但“搜索$”这招在Tomcat环境下尤其好用，因为通过JSP注入的内存马，其生成的类往往是org.apache.jsp.*_jsp$1这种形式。如果发现非JSP目录下的匿名内部类，需要高度警惕。

第二步：深度排查Web容器组件对于动态注册型内存马，我们需要直接检查容器的核心注册表。

针对Tomcat Filter内存马：Filter是内存马的重灾区。我们可以通过Arthas执行OGNL表达式，直接获取Tomcat的StandardContext，进而查看其filterMaps和filterDefs。

# 获取当前Web应用的StandardContext (需要知道context path，默认为ROOT) ognl '#c=@org.springframework.web.context.support.WebApplicationContextUtils@getWebApplicationContext(@javax.servlet.ServletContext@class.getDeclaredMethod(“getServletContext”).invoke(null)).getServletContext(), #c.getAttribute(“org.apache.catalina.core.ApplicationContextFacade”).getContext()' # 更通用的方法：通过线程堆栈找到ApplicationFilterChain实例，再回溯Context (以下为示例思路，实际命令需调整) thread -b # 找出阻塞的请求处理线程，查看其堆栈 # 从堆栈中找到ApplicationFilterChain的引用，通过OGNL表达式导航到StandardContext

由于直接操作OGNL较为复杂，在实际应急中，我通常更依赖一个经过验证的JSP扫描脚本（如c0ny1师傅的java-memshell-scanner），或使用下面更直接的方法。

通过Arthas查看所有Filter实现类：

# 查找所有实现了javax.servlet.Filter接口的类 sc -d * --interfaces javax.servlet.Filter

这条命令会列出所有Filter类。你需要结合业务知识进行判断：哪些是框架自带的（如CharacterEncodingFilter），哪些是业务定义的，哪些是来源不明、名称奇怪的。

第三步：反编译与代码审计当发现可疑类后，使用Arthas的jad命令直接反编译，查看其字节码逻辑。

# 1. 查看类的详细信息，包括ClassLoader sc -d com.example.SuspiciousFilter # 2. 反编译类，查看源码（假设类加载器hash为 18b4aac2） jad -c 18b4aac2 com.example.SuspiciousFilter

在反编译出的代码中，你需要重点关注：

1. doFilter方法中是否有读取请求参数（如cmd,password）的逻辑。
2. 是否有动态解码、反射调用等敏感操作。
3. 是否包含常见的Webshell特征字符串（如Runtime.getRuntime().exec()）。

第四步：针对字节码篡改型内存马的排查如果你怀疑是冰蝎Agent马等篡改型内存马，需要直接检查关键类的字节码。

# 反编译关键类，查看其方法实现是否被植入额外逻辑 jad javax.servlet.http.HttpServlet # 或者更精准地查看方法代码 jad javax.servlet.http.HttpServlet service

仔细阅读反编译出的service方法，寻找是否有额外的if判断，检查请求路径是否匹配某个特殊字符串（如冰蝎默认的/agentmemshell），以及是否有调用某个解密类进行解码执行的逻辑。

重要注意事项：使用Arthas等工具在线排查时，务必在测试环境或得到授权后进行操作。某些诊断命令（如频繁调用jad）可能会对高负载的生产环境产生性能影响。此外，攻击者可能部署了反检测手段，阻止Agent注入（如冰蝎的“禁止Attach”功能），此时Arthas将无法连接。

3.2 脚本化自动化扫描：JSP扫描器原理与使用

对于Tomcat环境，一个非常高效的方法是直接使用现成的JSP扫描脚本。其原理是：在Tomcat中，JSP本身就是一个特殊的Servlet，它运行在应用上下文中，可以访问到ServletContext，进而通过反射获取到StandardContext对象。这个对象包含了整个Web应用的所有组件注册信息。

典型工具：tomcat-memshell-scanner.jsp

1. 将扫描脚本上传到Web服务器的可访问目录（前提是存在文件上传点或已知漏洞）。
2. 通过浏览器或curl访问该JSP页面。
3. 脚本会自动执行，并输出当前应用中所有的Servlet、Filter、Listener列表，并高亮显示可疑项（如匿名内部类、非业务路径的Filter）。

脚本核心逻辑拆解：

// 伪代码展示核心思路 ServletContext servletContext = request.getServletContext(); Field contextField = servletContext.getClass().getDeclaredField(“context”); contextField.setAccessible(true); // 一路通过反射获取到StandardContext StandardContext standardContext = ...; // 获取Filter映射 FilterDef[] filterDefs = standardContext.findFilterDefs(); FilterMap[] filterMaps = standardContext.findFilterMaps(); // 遍历并打印，对比基线

优势与局限：

• 优势：直观、快速，能直接看到组件与URL模式的映射关系。
• 局限：仅适用于Tomcat且能上传/访问JSP的场景。对于Spring Boot嵌入式容器或其它Web服务器，此方法可能失效。同时，它无法检测字节码篡改型内存马。

4. 终极取证：内存Dump与离线深度分析

当动态分析受阻（如Agent无法注入），或者我们需要进行司法取证、保留完整证据链时，内存转储（Heap Dump）分析是最终手段。其核心思想是：将JVM某一时刻的整个堆内存（包含所有对象、类定义）保存到文件，然后使用专业工具进行离线、细致的分析。

4.1 获取Heap Dump文件

# 使用jmap工具（JDK自带） jps -l # 找到目标Java进程的PID jmap -dump:live,format=b,file=heapdump.hprof <pid> # 使用Arthas（如果还能连接） heapdump /tmp/heapdump.hprof

生成的文件（如heapdump.hprof）通常较大，可能有数GB。

4.2 使用MAT/Eclipse Memory Analyzer进行初步分析

MAT是一款强大的Heap Dump分析工具。虽然它不是为内存马排查量身定做，但可以通过一些技巧发现蛛丝马迹。

关键搜索技巧：

1. 搜索类名：在OQL（Object Query Language）控制台中，执行查询：

   SELECT * FROM java.lang.Class WHERE toString() LIKE “%shell%” SELECT * FROM java.lang.Class WHERE toString() LIKE “%filter%” AND toString() NOT LIKE “%org.apache%” AND toString() NOT LIKE “%org.springframework%”

   通过排除已知的框架和容器类，缩小可疑范围。

2. 搜索字节码特征：内存马的本质是.class字节码。一个.class文件的标准魔数是0xCAFEBABE。在MAT中，我们可以尝试搜索包含此字节序列的byte[]对象。在OQL中搜索byte[]内容比较困难，但可以留意大尺寸的byte[]对象。

3. 分析HTTP请求参数：内存马在执行时，往往会从HttpServletRequest中获取参数。在Heap Dump中，可以查找包含常见后门参数名（如cmd,password,code）的字符串对象。

   SELECT * FROM java.lang.String s WHERE s.toString() LIKE “%cmd%”

4.3 使用专业工具进行深度字节码挖掘

对于内存马分析，更专业的方法是使用能够解析Java运行时内存结构的工具，直接提取和重建.class文件。

工具推荐：jhat(已过时) 或VisualVM+OQL，以及更底层的gdb/WinDbg+JDK调试符号。但对于大多数安全工程师，以下方法更实用：

方法：字符串搜索与手动提取由于恶意类的字节码在内存中是以byte[]形式存在的，并且攻击者在传输时通常会用Base64编码。因此，在Heap Dump的二进制文件中搜索Base64编码的字节码头yv66vgAA（即CAFEBABE的Base64编码），是一个极其有效的技巧。

操作步骤：

1. 使用strings命令或hexedit等二进制编辑器打开heapdump.hprof文件。
2. 搜索字符串yv66vgAA。你会很可能发现多处匹配，这些很可能就是攻击过程中在内存中残留的恶意类字节码的Base64形式。
3. 将找到的Base64字符串复制出来，使用Python或在线工具进行解码，保存为.class文件。

   import base64 import sys b64_string = “yv66vgAAADQ...（很长一串）” # 你找到的字符串 class_bytes = base64.b64decode(b64_string) with open(‘ExtractedMalicious.class’, ‘wb’) as f: f.write(class_bytes) print(“Class file saved.”)

4. 使用反编译工具（如JD-GUI、CFR、FernFlower）打开这个.class文件，你就能看到攻击者注入的完整恶意代码逻辑，包括解密函数、命令执行方式、回连路径等关键信息。

我的实战记录：在一次应急中，我们通过搜索yv66vgAA，在Heap Dump中发现了数十处匹配。经过筛选和还原，成功提取出了三个不同的内存马类：一个是Filter马，一个是基于Spring的Controller马，还有一个是用于解码的辅助类。这些还原的类文件成为了事件定性报告的关键证据。

5. 日志分析与攻击链定性

内存马的植入不是凭空发生的，它必然有一个初始的漏洞利用入口。因此，结合Web日志、中间件日志进行攻击链回溯，是应急响应不可或缺的一环。

5.1 关键日志源与排查点

1. Web访问日志(如Tomcat的localhost_access_log.*.txt, Nginx的access.log)：

   • 搜索异常路径：查找访问那些不存在的、奇怪的或带有常见漏洞利用特征路径的请求（如/xxx.jsp,/weblogic,/actuator/env,/upload等）。
   • 关注特殊参数：搜索包含class,byte,base64,eval,runtime,processBuilder等关键词的请求参数。
   • 关联时间点：将发现内存马的时间点向前推（如半小时到几小时），重点审查该时间段的日志，寻找可疑的、成功的攻击请求（HTTP状态码200或302）。

2. 应用错误日志(如Tomcat的catalina.out, Spring Boot的application.log)：

   • 查找异常堆栈：攻击者在利用漏洞时，可能因为参数错误、兼容性问题等触发异常。这些异常堆栈会直接指向被利用的漏洞类和方法，是定位入口点的最直接证据。
   • 关注ClassLoader相关错误：如ClassNotFoundException,NoClassDefFoundError，可能和攻击者尝试加载恶意类有关。

3. 系统日志(/var/log/auth.log,secure等)：检查在Web攻击时间点前后，是否有异常的用户登录、特权命令执行记录，判断攻击者是否已进行横向移动或权限提升。

5.2 攻击链定性实战流程

假设我们通过内存分析，确认了一个路径为/evilfilter的Filter内存马。

1. 回溯：在Web访问日志中，搜索所有包含/evilfilter的请求，找到最早的一条访问记录，记录其时间T1和源IPIP_A。
2. 定位入口：在T1之前（例如前5分钟），从IP_A发起的请求中，寻找那些看起来像是漏洞利用的请求。例如：
   • 带有超长、乱码参数的POST请求。
   • 访问已知漏洞的API端点（如Spring Cloud Function SPEL注入、Log4j2 JNDI lookup等）。
   • 上传文件的请求（可能上传了用于注入内存马的JSP小马）。
3. 验证关联：检查在疑似漏洞利用请求之后，到T1之间，是否有来自IP_A的其他试探性请求（如访问/evilfilter?cmd=whoami）。这能形成完整的攻击链：漏洞利用 -> 植入内存马 -> 使用内存马。
4. 输出报告：将内存Dump中还原的恶意类代码、日志中提取的攻击请求、时间线、源IP等信息整合，形成完整的应急响应报告。报告应清晰说明：攻击入口、利用漏洞、植入的后门类型、后门功能、影响范围以及已采取的处置措施（如清除内存马、修复漏洞）。

6. 常见问题排查与实战避坑指南

在实际应急中，你会遇到各种意想不到的情况。下面是我总结的一些典型问题及解决思路。

6.1 工具使用类问题

问题1：Arthas无法附着到目标JVM进程，提示“Unable to open socket file”或连接超时。

• 可能原因1：权限不足。确保以与应用相同的用户（如tomcat,www-data）运行Arthas。
• 可能原因2：目标JVM启动了Attach机制限制。检查JVM启动参数是否包含-XX:+DisableAttachMechanism（极少见）。
• 可能原因3（最可能）：内存马的反检测功能。冰蝎等工具注入的内存马会尝试清除/tmp/.java_pid<pid>等Attach机制使用的文件，阻止新的Agent注入。
• 解决方案：
  • 首先尝试使用jstack <pid>或jcmd <pid> Thread.print等原生JDK工具，如果这些也失败，则很可能是反检测在起作用。
  • 此时，内存Dump是唯一的选择。立即使用jmap或gcore（Linux）生成Heap Dump。
  • 如果条件允许，可以尝试在业务低峰期，短暂重启单个服务实例（在集群环境下），然后立即进行动态分析。但此方法会丢失现场。

问题2：使用JSP扫描脚本时，返回500错误或空白页。

• 可能原因1：脚本兼容性问题。不同Tomcat版本内部API可能有差异。尝试使用针对特定Tomcat版本修改过的脚本。
• 可能原因2：JSP执行被禁用。检查应用或容器配置。
• 可能原因3：脚本本身被WAF或安全软件拦截。
• 解决方案：将扫描脚本的核心Java代码，改写为一个简单的Java Agent，通过-javaagent参数在启动时加载，或者通过Attach机制注入。这比依赖JSP环境更可靠。

6.2 分析与判断类问题

问题3：在Arthas中看到大量匿名内部类（$），如何快速判断哪些是恶意的？

• 排查步骤：
  1. 看类加载器：sc -d 类名查看其ClassLoader。如果是org.apache.jasper.servlet.JasperLoader加载的，且类路径在/ROOT/org/apache/jsp/下，这通常是正常的JSP编译产物。
  2. 看类名上下文：恶意匿名类的外部类名（$前面的部分）往往很奇怪，或者是一个你完全不认识的类。而JSP生成的匿名类，其外部类名就是JSP文件本身。
  3. 反编译验证：对最可疑的几个类直接使用jad反编译，查看其代码逻辑。

问题4：Heap Dump文件太大（几十GB），无法下载或分析工具打不开。

• 解决方案：
  1. 在服务器上预处理：使用strings heapdump.hprof | grep -a “yv66vgAA” > strings.txt，先在服务器上提取出所有可能的Base64串，下载较小的strings.txt文件进行分析。
  2. 使用MAT的索引功能：MAT在首次打开Dump文件时会创建索引，这个过程可能很慢，但一旦完成，后续查询会很快。确保分析机器有足够的内存（至少比Dump文件大50%）。
  3. 分区域分析：如果只需要分析特定类的实例，可以在生成Dump时使用更精确的OQL或考虑使用jhat（虽老旧，但处理大文件有时更稳定）。

问题5：还原出的.class文件无法反编译，提示“invalid constant pool index”。

• 可能原因：从内存中提取的字节数组可能不完整，或者包含了非.class数据的部分（如相邻的其他对象数据）。
• 解决方案：
  1. 尝试用010 Editor或WinHex等二进制编辑器打开提取的.class文件，检查文件头是否是CA FE BA BE。
  2. 如果头正确但内部损坏，可以尝试使用javap -c -p < classfile来查看字节码指令，虽然可读性差，但能看出大概逻辑。
  3. 回到Heap Dump，尝试找到包含这个byte[]的父对象（如某个ClassLoader或某个类的静态字段），看看是否有更完整的上下文信息。

6.3 处置与加固建议

清除内存马：

• 对于动态注册型：如果使用Arthas或扫描脚本发现了具体的内存马实例，并且该工具提供了kill或unregister功能，可以尝试在线清除。但务必谨慎，在线操作可能引发线程同步问题。更稳妥的做法是记录下内存马的详细信息（类名、URL路径），然后重启应用。
• 对于字节码篡改型：在线修复几乎不可能。必须重启应用以恢复原始的类字节码。

根本性加固：

1. 升级与补丁：第一时间修复导致内存马植入的漏洞（如Fastjson、Shiro、Log4j2等）。
2. 限制动态类加载：在JVM安全策略或应用启动参数中，限制自定义ClassLoader或禁止某些包下的类定义（如java.lang.ProcessBuilder）。可以使用Java Security Manager或-XX:+DisableAttachMechanism（谨慎使用，会影响调试）。
3. 部署RASP：运行时应用自我保护程序能监控关键API调用（如ClassLoader.defineClass,ProcessBuilder.start()），在内存马行为发生时进行拦截和告警。
4. 加强监控：对生产环境JVM进程的Agent注入行为、异常类加载行为进行监控和告警。

最后，我想分享一个深刻的体会：内存马查杀不仅是技术活，更是体力活和细心活。它要求我们不仅懂Java Web开发、JVM原理，还要有在海量日志和内存数据中寻找蛛丝马迹的耐心。建立自己的一套排查清单（Checklist）和工具集至关重要。每次应急后，记得复盘，把攻击者新的绕过手法和你的排查技巧都沉淀下来。这个领域没有一劳永逸的银弹，唯有持续学习、实践和总结，才能在与攻击者的对抗中占据主动。