Tomcat内存马有：Filter型，Servlet型，Listener型
Spring内存马有：Controller型，Interceptor型
Java Agent内存马：这种方式不仅限于Tomcat或Spring
直接能想到的办法是利用Java Agent遍历所有JVM中的class，判断是否是内存马
例如使用阿里的arthas分析，根据继承实现类黑名单，注解包名类名等黑名单来做
例如LandGrey师傅的copagent项目，根据黑名单和风险注解作为依据，
或者使用c0ny1师傅的java-memshell-scanner项目，从Tomcat API角度删除
首先是类名可能是恶意的，或者包名和项目名不符，可以一眼看出
其次优先级肯定是第一位的，这由内存马的特性决定，所以应该重点关注第一个Filter
观察ClassLoader是否是不正常的，以及是否存在对应的Class文件
有一种思路是在destroy方法中加入再注册内存马的代码，但并不是所有删除方式都会触发destroy方法
所以另外的思路是跑一个不死线程，循环检测该内存马是否存在，以及注册的功能
内存马持久化这个问题必须要往本地写文件，可以利用addShutDownHook方法在JVM退出时写文件
一般来说思路是写入依赖Jar中，例如catalina.jar中
4ra1n师傅提到的修改Tomcat的Lib也是一种手段，在默认开启的WsFilter中的doFilter方法中修改代码
@Filter标签还有什么办法（★★★）使用ServletContainerInitializer用于在容器启动阶段注册三大组件，取代web.xml配置。其中onStartup方法会在Tomcat中间件重启加载当前webapp会优先执行这个方法。通过改方法，我们可以注册一个webshell的filter
网上师傅提到用sa-jdi.jar工具来做，这是一个JVM性能检测工具，可以dump出JVM中可能有问题的Class文件，尤其重点关注HttpServletr.service方法，这是Agent内存马常用的手段
一般Agent内存马会调用Java Agent提供的redefineClass方法加入内存马
如果想检测，拿到的字节码并不是修改过的字节码，而是原始字节码，因此无法判断某个类是否合法
准确描述：无法获取到被redefineClass修改后的字节码，只能获取到被retransformClass修改后的字节码
根据JavaEE规范，最先想到的点应该是javax/servlet/http/HttpServlet#service
其次是位于Filter链头部的org/apache/catalina/core/ApplicationFilterChain#doFilter
针对特殊框架可以做特殊处理，例如针对Spring的org/springframework/web/servlet/DispatcherServlet#doService
还有4ra1n师傅提出关于Tomcat自带Filter的修改：org/apache/tomcat/websocket/server/WsFilter#doFilter
这个比较简单，用Agent把查到的类对应的方法改成原始的字节码即可
获取原始字节码也不难，从本地或标准库中查找，然后利用Javassist修改
核心是找到类似Tomcat和Spring中的Context对象，然后尝试从其中获取request和response对象以实现内存马的功能。
可以从常见的类名入手：Requst、ServletRequest、RequstGroup、RequestInfo、RequestGroupInfo等等
可以参考c0ny1师傅的java-object-searcher项目，半自动搜索request对象
参考c0ny1师傅的文章，由于Spring Cloud Gateway并不基于Tomcat而是基于Netty框架，需要构造一个handler用作内存马。另外的思路是构造上层的内存马，也就是基于Spring的内存马，向RequestMappingHandlerMapping中注入新的映射。具体代码使用到了Sping的一些工具类，在SPEL中反射调用了defineClass以达到执行代码的效果