内存马在Java安全领域一直是绕不开的话题而Spring框架下的Interceptor拦截器内存马算是其中很隐蔽的一种形态。它不写文件、不动Filter、甚至不碰Servlet容器而是把逻辑挂在Spring MVC处理请求的拦截器链上。这篇文章我会从Spring MVC的请求处理链路说起拆解动态注册Interceptor的核心机制再用一次授权测试里的排查经历讲清楚检测思路最后给出一份相对完整的自查清单。内容适合正在研究Java安全的应用安全同学也适合想深入了解Spring内部机制的后端开发者。先说清楚一个前提所有涉及动态注入的验证我都只在授权测试环境里做过没有经过授权的系统碰都不要碰。安全研究的价值在于提前发现风险、帮助防守而不是绕过规则。1. 为什么Interceptor能成为内存马的载体请求在Spring MVC里的必经之路1.1 Filter、Servlet和Interceptor三者的位置差异很多人一聊到Java内存马第一反应是Filter。因为Tomcat的容器层Filter链足够底层一旦注入成功几乎对所有请求生效。但Filter的注册位置在Servlet容器和Spring容器是两层。而Interceptor挂在Spring MVC内部离业务代码更近修改它不需要惊动容器只需要在Spring上下文里“动手脚”。一个典型请求在Spring Boot应用中的流转大概是这样的请求先到达Servlet容器经过一堆Filter如Spring Security的过滤器链。进入DispatcherServlet这是Spring MVC的前端控制器。DispatcherServlet通过HandlerMapping找到处理请求的Handler也就是Controller方法。在真正执行Controller方法之前Spring会依次调用HandlerInterceptor的preHandle方法。Controller方法执行完后再调用postHandle和afterCompletion。也就是说只要HandlerMapping里的Interceptor列表里有东西每个匹配的请求在执行前都会先撞上它。这个位置天然适合做“检查和改写”也正因如此如果被塞进恶意逻辑它就能对请求和响应做不少事情。1.2 与Filter型内存马相比Interceptor型隐蔽在哪Filter型内存马需要拿到容器上下文或Servlet上下文而Spring Boot应用里最常见的场景是“已经获得了Spring上下文内的代码执行能力”。这种情况下往HandlerMapping里添加一个自定义HandlerInterceptor要比往Tomcat里塞一个Filter更“顺手”因为SpringApplicationContext本身就是攻击者已经掌握的对象池。另外常规的Webshell扫描工具会把磁盘文件、字节码特征作为重点Interceptor内存马没有独立文件它只是运行期一个对象。你翻web目录、翻上传目录、翻日志都不一定有线索。业务代码里大量自定义拦截器也很常见比如登录校验、权限校验、日志记录所以想在运行期发现一个“多出来的”拦截器光靠眼睛看是看不出来的。这里有一个容易忽略的细节Spring Boot在自动配置阶段会创建RequestMappingHandlerMapping这个Bean它处理绝大多数Controller请求。而AbstractHandlerMapping基类里有一个adaptedInterceptors字段类型是ListObject。这个字段就是所有已适配拦截器的容器。所谓动态注册Interceptor内存马本质上就是往这个List里追加一个对象。理解了这个位置后面检测和加固的方向也就清晰了。2. 动态注册Interceptor的底层逻辑与关键前提2.1 拦截器在Spring容器里到底存在哪里AbstractHandlerMapping这个抽象类是所有HandlerMapping的父类。它内部维护了一个adaptedInterceptors列表在初始化时通过initInterceptors()方法把配置好的拦截器加进去。如果你在WebMvcConfigurer.addInterceptors里注册过自定义拦截器这些拦截器最终也会落到这个列表里。正常情况下这个列表里的元素只有两种来源实现了HandlerInterceptor接口的普通对象。MappedInterceptor包装对象它内部持有HandlerInterceptor和路径匹配规则。关键点在于adaptedInterceptors是实例字段不是常量也不是不可变集合。只要代码能拿到RequestMappingHandlerMapping这个类的实例就可以通过反射把自定义对象追加到该List里。追加之后Spring处理请求时遍历拦截器链自然就会调用到新加的这个拦截器。打个比方拦截器列表就像一个派件仓库里的“快递员花名册”正常情况是公司行政添加的。如果你的系统被入侵攻击者能拿到仓库钥匙往花名册里加一个“特殊快递员”那么后续每一批派件都会先经过他。2.2 运行时拿到HandlerMapping实例的几条路径在已经获得代码执行能力的前提下拿到RequestMappingHandlerMapping实例并不是难事。最常见的方式包括从ApplicationContext中按类型获取BeanapplicationContext.getBean(RequestMappingHandlerMapping.class)。通过Autowired注入当然动态注入场景下没法用注解一般用前一种。如果存在多个HandlerMapping比如BeanNameUrlHandlerMapping需要自己判断当前请求实际走的是哪一个。这个“取Bean”的动作本身很普通业务代码里到处都在用。所以防守方不能只防这个动作而要从更底层去防“未经允许的自定义类被加载并注册”。顺带提一下Spring版本差异。Spring 5.3之后默认的路径匹配策略引入了PathPatternParserMappedInterceptor里保存的不再是简单的AntPathMatcher字符串规则而是PathPattern。反射往adaptedInterceptors里追加对象时如果追加的是普通HandlerInterceptor它会被当作全局拦截器处理作用范围是所有请求这比自定义路径规则的MappedInterceptor影响范围更大。2.3 动态注册能成功的前提条件与边界需要把话说清楚动态注册Interceptor这件事本身不是漏洞而是Spring对外扩展点的一部分。不是所有系统都能随随便便成功至少需要满足三个条件攻击者已经有代码执行能力比如通过反序列化、SQL注入写文件配合、表达式注入等拿到任意代码执行。当前请求线程能访问到Spring容器也就是能拿到ApplicationContext。JVM没有限制反射调用的敏感访问比如JDK 17强模块系统下对java.base模块的反射限制会更严格但对Spring自己的类影响有限。所以本质上内存马是“二次利用”的产物。它不是独立的攻击入口而是攻击者拿到一次执行机会之后为了保持控制权、逃避检测而做的持久化操作。反过来说防御方如果把精力全部放在“清内存马”上而没堵住最开始的代码执行漏洞那清理完很快又会被写入新的。3. 一次授权测试里的“排查链路”从异常日志到藏在链尾的拦截器3.1 现场现象与初步判断某一次授权测试的收尾阶段我们在一套Spring Boot应用里发现一个很有意思的现象一个正常业务接口返回正常但响应里多了一个自定义响应头并且访问一个根本不存在的URL时也会返回200状态码响应体还是空。正常情况下不存在的URL应该由Spring MVC抛出404。直接返回200说明有东西在Controller还没执行时就把请求短路了。这个行为与HandlerInterceptor.preHandle返回false的表现一致——请求被拦截不再继续执行后续链路。初步判断有两个可能一是系统里本来就配置了某个全局拦截器做了“吞请求”逻辑二是存在额外的拦截器注入。为了区分这两种可能我们需要直接去看adaptedInterceptors里到底有哪些对象。3.2 用堆转储和JVM诊断命令定位异常对象排查的时候不能只凭日志猜最直接的方法是看运行期对象。我们当时的做法是先通过JDK自带的堆转储工具导出一份堆快照。再用内存分析工具打开快照搜索AbstractHandlerMapping的子类实例。找到RequestMappingHandlerMapping实例后展开它的adaptedInterceptors字段查看列表长度和每个元素的类名。正常应用里拦截器数量一般是几个到十几个类名大多来自项目包名或Spring框架包名。当时列表里出现了一个类名非常“干净”的拦截器包名路径很短看起来不像普通业务类。这里给个自查时可以直接用的思路用反射把当前所有HandlerMapping里的拦截器列出来ListHandlerMapping mappings applicationContext.getBeansOfType(HandlerMapping.class) .values() .stream().toList(); for (HandlerMapping mapping : mappings) { try { Field field AbstractHandlerMapping.class.getDeclaredField(adaptedInterceptors); field.setAccessible(true); List? interceptors (List?) field.get(mapping); System.out.println(Mapping类: mapping.getClass().getName()); for (Object interceptor : interceptors) { System.out.println( 拦截器: interceptor.getClass().getName() 加载器: interceptor.getClass().getClassLoader()); } } catch (Exception e) { // 反射访问在新版本JDK下可能需要额外处理 } }这个代码本身没有任何攻击性它的作用是让你的应用自己“照镜子”。运行时如果发现列表里出现了不属于你的类加载器的拦截器就需要马上警惕。3.3 找到挂载点后的验证方式与结论定位到可疑拦截器后我们先用Class.getProtectionDomain().getCodeSource()看了它的类加载来源发现没有一个对应的代码源说明它的类是动态生成的。再结合响应头特征基本确认这就是一个动态注册的Interceptor内存马。随后我们把应用重启再访问同样的URL异常响应头消失。这也印证了“内存马不落盘、重启即失效”的特点。但要注意如果攻击者同时有外部的持久化通道比如计划任务、自启动脚本重启后内存马会再次被注入所以排查不能止步于“重启一下”。这次排查给我最大的感受是动态注册Interceptor的迷惑性并不在于技术多高级而在于它藏在一堆正常拦截器中间如果不主动查看运行期对象列表几乎不会有感知。4. 从检测角度拆解如何训练眼睛识别异常Interceptor4.1 基于对象快照的基线比对对于生产环境我建议在每次发版后第一时间用脚本记录当前应用里的拦截器基线包括拦截器数量、类名、ClassLoader、代码来源。把这些信息存成一份快照文件之后定期巡检时做对比。一张简单的对比表可以帮助判断维度正常特征可疑特征类名项目包名规范业务含义明确包名短、无业务含义或包含Base64解码痕迹类加载器应用系统加载器或框架加载器自定义ClassLoader或距离默认加载器很远代码来源有明确的jar包路径或classes目录为null或指向临时目录实例数量稳定每次启动一致与部署记录不一致启动后动态增加接口行为与配置代码逻辑对应出现未配置的处理逻辑或响应头/响应体异常这个表不是金标准但能帮你快速过滤掉绝大多数正常情况。如果一条记录对应了多个可疑特征那就要深入看。4.2 从请求行为特征找线索不是所有环境都允许你jmap、jstack。在这种场景下行为侧的异常特征可以作为辅助判断。举几个实际出现过的信号访问一个不存在的URL状态码是200而不是404。请求完成后响应头里多出了莫名其妙的字段。某些请求的响应耗时突然出现固定延迟像是被额外处理逻辑拖住。请求参数里的特殊值会触发不同响应比如传了某个约定好的参数后返回内容明显改变。正常过滤器、拦截器原本打印的日志顺序发生变化或者出现了重复输出。这些信号单独看都不足以定论但如果同时出现多个就该去检查拦截器列表了。拦截器内存马本来就会改变请求的处理时机所以从“请求行为变异”反向追踪是很有效的分析思路。4.3 借助Java Agent做运行期扫描对于有条件的环境可以挂一个自定义Java Agent在类加载和对象实例化阶段做钩子。这不是普通业务能轻易做的事但确实有团队会针对Spring MVC的AbstractHandlerMapping做专门的防护。简单说思路Agent在premain阶段用ClassFileTransformer或者Instrumentation API去监听org.springframework.web.servlet.handler.AbstractHandlerMapping类。当有代码调用addInterceptor或反射修改adaptedInterceptors时记录调用栈并判断调用来源是否在白名单内。一旦发现非白名单类在操作拦截器列表直接抛出异常或记录告警。这种机制比较重更适合有专门安全团队的公司。对于大多数项目定期快照比对已经能覆盖绝大多数风险。5. 防御与自查清单把Interceptor内存马当作扩展点风险来治理5.1 注册面收口别让WebMvcConfigurer成为攻击者的跳板业务系统里如果有自定义的WebMvcConfigurer比如统一登录拦截、接口鉴权拦截一定要保持精简。不要在拦截器里写危险逻辑也不要暴露一个能从HTTP入口触达任意Spring Bean的方法。比如某个接口接收一个类名然后用反射去调用该类的方法这种设计一旦存在等于是把Spring容器整个交了出去。如果条件允许可以自己封装一个WebMvcConfigurer重写addInterceptors方法限制只能添加预先定义好的拦截器白名单Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor); registry.addInterceptor(auditInterceptor); // 不允许其他外部类再调用registry.addInterceptor }但说实话这套防御只能挡住“配置阶段”的注入。攻击者如果在运行期直接反射改adaptedInterceptors字段这个重写是拦不住的。所以它只是防御体系里的一层不是全部。5.2 运行期守护定期校验已注册拦截器的Class来源我给团队的例行检查脚本里会做下面几件事启动时自动生成一个拦截器指纹文件包含所有Interceptor类名和代码来源哈希。每天凌晨通过JMX或一个受保护的管理接口重新读取当前拦截器列表与指纹文件比对。比对结果写入独立日志如果发现新增、删除或类名变更立即触发告警。具体到实现就是把之前那一段反射读取adaptedInterceptors的方法包成一个定时任务。管理接口本身要严格限制IP、鉴权和调用频率防止被攻击者利用来探测当前状态。这里要特别注意如果应用本身存在RCE漏洞攻击者同样可以伪造这个名单。所以运行期守护更多是“发现”作用不能完全依赖它。5.3 从源头防RCE比清内存马更重要这句话我每次都会强调内存马只是“症状”不是“病根”。一个攻击者能把Interceptor塞进你的内存说明他已经在你系统里执行过代码了。清掉一个拦截器如果漏洞还在他换个姿势又能进来。所以防御的重心应该落在依赖库漏洞扫描尤其是反序列化链涉及的高危组件。对外接口严格做参数校验防止表达式注入、模板注入。上线前的Web应用渗透测试覆盖越权、任意文件读写、命令注入等场景。最小权限原则应用运行账号不要给到宿主机的高危权限。这些工作看起来和“内存马”离得很远但实际上它们是决定你能不能睡好觉的关键。5.4 把异常迹象纳入监控告警体系拦截器列表变化只是众多攻击迹象中的一种建议把下面几个指标都接进监控体系Spring上下文里自定义Bean数量的变化。HandlerMapping中Interceptor列表长度和对象哈希。非业务代码主动调用反射的次数和调用栈。动态生成Class的数量。不需要每个都做成实时拦截可以先做基础数据采集。这些指标单独看都正常但组合起来能提供很强的关联分析能力。比如某个时间段反射调用突增、动态类生成突增、随后拦截器列表变化那基本可以判定有一个完整的注入过程发生了。写在最后的经验拦截器内存马真正让人头疼的地方其实不是技术有多高深而是它和正常业务代码完全共用Spring MVC的同一套扩展机制。你很难用一个简单的特征去一刀切误判率太高。我自己的习惯是把Spring的adaptedInterceptors当成“敏感资产”来管理启动时记录指纹上线后定期看差异。哪怕没有任何异常每个月花两分钟查一次成本很低却能避免很多被动局面。另外一个容易被忽略的点是排查这类问题不要只盯应用本身。如果攻击者已经能在宿主机上为所欲为他完全有可能直接读写正在运行的JVM进程。安全对抗是体系化的内存马只是其中一个很小的战场。希望这篇文章能把动态注册Interceptor的原理和检测思路讲透也希望大家在真实环境里遇到类似现象时知道该从哪里下手。 
长河君 · 2026/10/24 0:30:54 · 阅读 1.2k Spring MVC拦截器内存马：动态注册原理与检测防御实战
内存马在Java安全领域一直是绕不开的话题而Spring框架下的Interceptor拦截器内存马算是其中很隐蔽的一种形态。它不写文件、不动Filter、甚至不碰Servlet容器而是把逻辑挂在Spring MVC处理请求的拦截器链上。这篇文章我会从Spring MVC的请求处理链路说起拆解动态注册Interceptor的核心机制再用一次授权测试里的排查经历讲清楚检测思路最后给出一份相对完整的自查清单。内容适合正在研究Java安全的应用安全同学也适合想深入了解Spring内部机制的后端开发者。先说清楚一个前提所有涉及动态注入的验证我都只在授权测试环境里做过没有经过授权的系统碰都不要碰。安全研究的价值在于提前发现风险、帮助防守而不是绕过规则。1. 为什么Interceptor能成为内存马的载体请求在Spring MVC里的必经之路1.1 Filter、Servlet和Interceptor三者的位置差异很多人一聊到Java内存马第一反应是Filter。因为Tomcat的容器层Filter链足够底层一旦注入成功几乎对所有请求生效。但Filter的注册位置在Servlet容器和Spring容器是两层。而Interceptor挂在Spring MVC内部离业务代码更近修改它不需要惊动容器只需要在Spring上下文里“动手脚”。一个典型请求在Spring Boot应用中的流转大概是这样的请求先到达Servlet容器经过一堆Filter如Spring Security的过滤器链。进入DispatcherServlet这是Spring MVC的前端控制器。DispatcherServlet通过HandlerMapping找到处理请求的Handler也就是Controller方法。在真正执行Controller方法之前Spring会依次调用HandlerInterceptor的preHandle方法。Controller方法执行完后再调用postHandle和afterCompletion。也就是说只要HandlerMapping里的Interceptor列表里有东西每个匹配的请求在执行前都会先撞上它。这个位置天然适合做“检查和改写”也正因如此如果被塞进恶意逻辑它就能对请求和响应做不少事情。1.2 与Filter型内存马相比Interceptor型隐蔽在哪Filter型内存马需要拿到容器上下文或Servlet上下文而Spring Boot应用里最常见的场景是“已经获得了Spring上下文内的代码执行能力”。这种情况下往HandlerMapping里添加一个自定义HandlerInterceptor要比往Tomcat里塞一个Filter更“顺手”因为SpringApplicationContext本身就是攻击者已经掌握的对象池。另外常规的Webshell扫描工具会把磁盘文件、字节码特征作为重点Interceptor内存马没有独立文件它只是运行期一个对象。你翻web目录、翻上传目录、翻日志都不一定有线索。业务代码里大量自定义拦截器也很常见比如登录校验、权限校验、日志记录所以想在运行期发现一个“多出来的”拦截器光靠眼睛看是看不出来的。这里有一个容易忽略的细节Spring Boot在自动配置阶段会创建RequestMappingHandlerMapping这个Bean它处理绝大多数Controller请求。而AbstractHandlerMapping基类里有一个adaptedInterceptors字段类型是ListObject。这个字段就是所有已适配拦截器的容器。所谓动态注册Interceptor内存马本质上就是往这个List里追加一个对象。理解了这个位置后面检测和加固的方向也就清晰了。2. 动态注册Interceptor的底层逻辑与关键前提2.1 拦截器在Spring容器里到底存在哪里AbstractHandlerMapping这个抽象类是所有HandlerMapping的父类。它内部维护了一个adaptedInterceptors列表在初始化时通过initInterceptors()方法把配置好的拦截器加进去。如果你在WebMvcConfigurer.addInterceptors里注册过自定义拦截器这些拦截器最终也会落到这个列表里。正常情况下这个列表里的元素只有两种来源实现了HandlerInterceptor接口的普通对象。MappedInterceptor包装对象它内部持有HandlerInterceptor和路径匹配规则。关键点在于adaptedInterceptors是实例字段不是常量也不是不可变集合。只要代码能拿到RequestMappingHandlerMapping这个类的实例就可以通过反射把自定义对象追加到该List里。追加之后Spring处理请求时遍历拦截器链自然就会调用到新加的这个拦截器。打个比方拦截器列表就像一个派件仓库里的“快递员花名册”正常情况是公司行政添加的。如果你的系统被入侵攻击者能拿到仓库钥匙往花名册里加一个“特殊快递员”那么后续每一批派件都会先经过他。2.2 运行时拿到HandlerMapping实例的几条路径在已经获得代码执行能力的前提下拿到RequestMappingHandlerMapping实例并不是难事。最常见的方式包括从ApplicationContext中按类型获取BeanapplicationContext.getBean(RequestMappingHandlerMapping.class)。通过Autowired注入当然动态注入场景下没法用注解一般用前一种。如果存在多个HandlerMapping比如BeanNameUrlHandlerMapping需要自己判断当前请求实际走的是哪一个。这个“取Bean”的动作本身很普通业务代码里到处都在用。所以防守方不能只防这个动作而要从更底层去防“未经允许的自定义类被加载并注册”。顺带提一下Spring版本差异。Spring 5.3之后默认的路径匹配策略引入了PathPatternParserMappedInterceptor里保存的不再是简单的AntPathMatcher字符串规则而是PathPattern。反射往adaptedInterceptors里追加对象时如果追加的是普通HandlerInterceptor它会被当作全局拦截器处理作用范围是所有请求这比自定义路径规则的MappedInterceptor影响范围更大。2.3 动态注册能成功的前提条件与边界需要把话说清楚动态注册Interceptor这件事本身不是漏洞而是Spring对外扩展点的一部分。不是所有系统都能随随便便成功至少需要满足三个条件攻击者已经有代码执行能力比如通过反序列化、SQL注入写文件配合、表达式注入等拿到任意代码执行。当前请求线程能访问到Spring容器也就是能拿到ApplicationContext。JVM没有限制反射调用的敏感访问比如JDK 17强模块系统下对java.base模块的反射限制会更严格但对Spring自己的类影响有限。所以本质上内存马是“二次利用”的产物。它不是独立的攻击入口而是攻击者拿到一次执行机会之后为了保持控制权、逃避检测而做的持久化操作。反过来说防御方如果把精力全部放在“清内存马”上而没堵住最开始的代码执行漏洞那清理完很快又会被写入新的。3. 一次授权测试里的“排查链路”从异常日志到藏在链尾的拦截器3.1 现场现象与初步判断某一次授权测试的收尾阶段我们在一套Spring Boot应用里发现一个很有意思的现象一个正常业务接口返回正常但响应里多了一个自定义响应头并且访问一个根本不存在的URL时也会返回200状态码响应体还是空。正常情况下不存在的URL应该由Spring MVC抛出404。直接返回200说明有东西在Controller还没执行时就把请求短路了。这个行为与HandlerInterceptor.preHandle返回false的表现一致——请求被拦截不再继续执行后续链路。初步判断有两个可能一是系统里本来就配置了某个全局拦截器做了“吞请求”逻辑二是存在额外的拦截器注入。为了区分这两种可能我们需要直接去看adaptedInterceptors里到底有哪些对象。3.2 用堆转储和JVM诊断命令定位异常对象排查的时候不能只凭日志猜最直接的方法是看运行期对象。我们当时的做法是先通过JDK自带的堆转储工具导出一份堆快照。再用内存分析工具打开快照搜索AbstractHandlerMapping的子类实例。找到RequestMappingHandlerMapping实例后展开它的adaptedInterceptors字段查看列表长度和每个元素的类名。正常应用里拦截器数量一般是几个到十几个类名大多来自项目包名或Spring框架包名。当时列表里出现了一个类名非常“干净”的拦截器包名路径很短看起来不像普通业务类。这里给个自查时可以直接用的思路用反射把当前所有HandlerMapping里的拦截器列出来ListHandlerMapping mappings applicationContext.getBeansOfType(HandlerMapping.class) .values() .stream().toList(); for (HandlerMapping mapping : mappings) { try { Field field AbstractHandlerMapping.class.getDeclaredField(adaptedInterceptors); field.setAccessible(true); List? interceptors (List?) field.get(mapping); System.out.println(Mapping类: mapping.getClass().getName()); for (Object interceptor : interceptors) { System.out.println( 拦截器: interceptor.getClass().getName() 加载器: interceptor.getClass().getClassLoader()); } } catch (Exception e) { // 反射访问在新版本JDK下可能需要额外处理 } }这个代码本身没有任何攻击性它的作用是让你的应用自己“照镜子”。运行时如果发现列表里出现了不属于你的类加载器的拦截器就需要马上警惕。3.3 找到挂载点后的验证方式与结论定位到可疑拦截器后我们先用Class.getProtectionDomain().getCodeSource()看了它的类加载来源发现没有一个对应的代码源说明它的类是动态生成的。再结合响应头特征基本确认这就是一个动态注册的Interceptor内存马。随后我们把应用重启再访问同样的URL异常响应头消失。这也印证了“内存马不落盘、重启即失效”的特点。但要注意如果攻击者同时有外部的持久化通道比如计划任务、自启动脚本重启后内存马会再次被注入所以排查不能止步于“重启一下”。这次排查给我最大的感受是动态注册Interceptor的迷惑性并不在于技术多高级而在于它藏在一堆正常拦截器中间如果不主动查看运行期对象列表几乎不会有感知。4. 从检测角度拆解如何训练眼睛识别异常Interceptor4.1 基于对象快照的基线比对对于生产环境我建议在每次发版后第一时间用脚本记录当前应用里的拦截器基线包括拦截器数量、类名、ClassLoader、代码来源。把这些信息存成一份快照文件之后定期巡检时做对比。一张简单的对比表可以帮助判断维度正常特征可疑特征类名项目包名规范业务含义明确包名短、无业务含义或包含Base64解码痕迹类加载器应用系统加载器或框架加载器自定义ClassLoader或距离默认加载器很远代码来源有明确的jar包路径或classes目录为null或指向临时目录实例数量稳定每次启动一致与部署记录不一致启动后动态增加接口行为与配置代码逻辑对应出现未配置的处理逻辑或响应头/响应体异常这个表不是金标准但能帮你快速过滤掉绝大多数正常情况。如果一条记录对应了多个可疑特征那就要深入看。4.2 从请求行为特征找线索不是所有环境都允许你jmap、jstack。在这种场景下行为侧的异常特征可以作为辅助判断。举几个实际出现过的信号访问一个不存在的URL状态码是200而不是404。请求完成后响应头里多出了莫名其妙的字段。某些请求的响应耗时突然出现固定延迟像是被额外处理逻辑拖住。请求参数里的特殊值会触发不同响应比如传了某个约定好的参数后返回内容明显改变。正常过滤器、拦截器原本打印的日志顺序发生变化或者出现了重复输出。这些信号单独看都不足以定论但如果同时出现多个就该去检查拦截器列表了。拦截器内存马本来就会改变请求的处理时机所以从“请求行为变异”反向追踪是很有效的分析思路。4.3 借助Java Agent做运行期扫描对于有条件的环境可以挂一个自定义Java Agent在类加载和对象实例化阶段做钩子。这不是普通业务能轻易做的事但确实有团队会针对Spring MVC的AbstractHandlerMapping做专门的防护。简单说思路Agent在premain阶段用ClassFileTransformer或者Instrumentation API去监听org.springframework.web.servlet.handler.AbstractHandlerMapping类。当有代码调用addInterceptor或反射修改adaptedInterceptors时记录调用栈并判断调用来源是否在白名单内。一旦发现非白名单类在操作拦截器列表直接抛出异常或记录告警。这种机制比较重更适合有专门安全团队的公司。对于大多数项目定期快照比对已经能覆盖绝大多数风险。5. 防御与自查清单把Interceptor内存马当作扩展点风险来治理5.1 注册面收口别让WebMvcConfigurer成为攻击者的跳板业务系统里如果有自定义的WebMvcConfigurer比如统一登录拦截、接口鉴权拦截一定要保持精简。不要在拦截器里写危险逻辑也不要暴露一个能从HTTP入口触达任意Spring Bean的方法。比如某个接口接收一个类名然后用反射去调用该类的方法这种设计一旦存在等于是把Spring容器整个交了出去。如果条件允许可以自己封装一个WebMvcConfigurer重写addInterceptors方法限制只能添加预先定义好的拦截器白名单Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor); registry.addInterceptor(auditInterceptor); // 不允许其他外部类再调用registry.addInterceptor }但说实话这套防御只能挡住“配置阶段”的注入。攻击者如果在运行期直接反射改adaptedInterceptors字段这个重写是拦不住的。所以它只是防御体系里的一层不是全部。5.2 运行期守护定期校验已注册拦截器的Class来源我给团队的例行检查脚本里会做下面几件事启动时自动生成一个拦截器指纹文件包含所有Interceptor类名和代码来源哈希。每天凌晨通过JMX或一个受保护的管理接口重新读取当前拦截器列表与指纹文件比对。比对结果写入独立日志如果发现新增、删除或类名变更立即触发告警。具体到实现就是把之前那一段反射读取adaptedInterceptors的方法包成一个定时任务。管理接口本身要严格限制IP、鉴权和调用频率防止被攻击者利用来探测当前状态。这里要特别注意如果应用本身存在RCE漏洞攻击者同样可以伪造这个名单。所以运行期守护更多是“发现”作用不能完全依赖它。5.3 从源头防RCE比清内存马更重要这句话我每次都会强调内存马只是“症状”不是“病根”。一个攻击者能把Interceptor塞进你的内存说明他已经在你系统里执行过代码了。清掉一个拦截器如果漏洞还在他换个姿势又能进来。所以防御的重心应该落在依赖库漏洞扫描尤其是反序列化链涉及的高危组件。对外接口严格做参数校验防止表达式注入、模板注入。上线前的Web应用渗透测试覆盖越权、任意文件读写、命令注入等场景。最小权限原则应用运行账号不要给到宿主机的高危权限。这些工作看起来和“内存马”离得很远但实际上它们是决定你能不能睡好觉的关键。5.4 把异常迹象纳入监控告警体系拦截器列表变化只是众多攻击迹象中的一种建议把下面几个指标都接进监控体系Spring上下文里自定义Bean数量的变化。HandlerMapping中Interceptor列表长度和对象哈希。非业务代码主动调用反射的次数和调用栈。动态生成Class的数量。不需要每个都做成实时拦截可以先做基础数据采集。这些指标单独看都正常但组合起来能提供很强的关联分析能力。比如某个时间段反射调用突增、动态类生成突增、随后拦截器列表变化那基本可以判定有一个完整的注入过程发生了。写在最后的经验拦截器内存马真正让人头疼的地方其实不是技术有多高深而是它和正常业务代码完全共用Spring MVC的同一套扩展机制。你很难用一个简单的特征去一刀切误判率太高。我自己的习惯是把Spring的adaptedInterceptors当成“敏感资产”来管理启动时记录指纹上线后定期看差异。哪怕没有任何异常每个月花两分钟查一次成本很低却能避免很多被动局面。另外一个容易被忽略的点是排查这类问题不要只盯应用本身。如果攻击者已经能在宿主机上为所欲为他完全有可能直接读写正在运行的JVM进程。安全对抗是体系化的内存马只是其中一个很小的战场。希望这篇文章能把动态注册Interceptor的原理和检测思路讲透也希望大家在真实环境里遇到类似现象时知道该从哪里下手。