凌晨两点半手机突然响了某客户的生产Java应用CPU飙到90%登录服务器一看进程还在但 war 包目录里干干净净连个可疑文件都没有。当时我就有种预感麻烦大了。这种“查不到文件”的入侵十有八九是内存马而且大概率不是单点问题。后来翻流量日志果然在一个内部后台接口里看到了规律性极强的POST请求请求体是一段看不出含义的加密串会话持续时间异常长WAF规则基本全被绕过去了。顺着线程栈一层层扒下去最终在一个自定义的Filter类里揪出了Godzilla-Suo5组合的内存马。这次实战下来我对“内存马攻防”的很多想法都变了。这篇文章就完整复盘这次检测与防御过程把Godzilla-Suo5MemShell这条攻击链路的原理、流量特征、内存排查方法、落地加固方案全部讲透。不管你是在甲方做蓝队应急还是Java开发运维想给应用加固这篇内容都可以直接当操作手册用。1. 攻防背景为什么内存马能成为当前最头疼的攻击手段1.1 从硬盘Webshell到内存马的演进逻辑过去很多年里攻击者拿下Web应用后最经典的套路就是落一个webshell文件到服务器比如在某个上传目录放一个jsp木马然后用蚁剑、冰蝎这类管理工具连接。这种思路有个致命弱点只要文件落地主机侧的EDR、云锁、安全狗、文件完整性监控全都能盯上查杀规则早晚会匹配到特征管理员扫描目录也能一眼发现问题。内存马绕开的就是这个关键点。它不写文件而是通过漏洞利用链把恶意字节码直接注入到正在运行的Java进程内存里以类的形式寄生在JVM中。由于没有对应文件传统文件扫描基本失效磁盘查杀也发现不了服务器重启前它就一直存在。最要命的是它和正常业务类混在一起纯靠人工看目录根本看不出异常只能从内存侧分析。这个演进本质上就是一个“对抗检测面”的过程攻击者不断把恶意行为往检测盲区里塞而内存恰恰是很多安全产品长期忽视的地方。1.2 Godzilla和Suo5的组合到底解决了什么问题Godzilla哥斯拉是目前活跃度极高的Webshell管理工具支持JSP、ASP.NET、PHP等多种语言。它最突出的特点是流量加密做得比较到位payload经过自定义算法处理请求包和响应包没有明显明文特征传统WAF用正则匹配关键字的方式基本无效。它还有“表面伪装”功能可以把请求体包装成JSON、XML或普通表单格式进一步干扰流量审计。Suo5则是一个HTTP隧道代理工具核心能力是把TCP流量封装进HTTP/HTTPS请求里实现跨防火墙、跨网段的隐蔽通道。它本身不直接生成Webshell但和内存马组合后效果非常炸裂攻击者先通过内存马建立执行通道再用Suo5打开一条稳定的加密隧道把内网流量像普通网页请求一样传输出去。流量侧看到的只是同一个IP不断访问同一个URL频率不高不低很难触发阈值告警。这两个工具组合起来的真实含义是控制通道加密化流量隧道化。内存马解决了“驻留”问题Suo5解决了“通信”问题两两配合让检测难度直接翻倍。注意这类攻击虽然隐蔽但并不是没有痕迹。关键在于不要只盯着文件和明文特征要把检测重心放到进程内存、类加载来源、线程调用栈、流量行为模式上。2. 拆解Godzilla-Suo5内存马的三种形态与攻击链路2.1 最重要的三种注入形态Java内存马的载体是Servlet容器主流形态有三种每一类的注入原理和排查切入点都不一样我在排查时必须先判断属于哪一类否则容易白忙一场。第一种是Servlet型内存马。攻击者通过反射获取当前Web应用的StandardContext再动态往里面addServlet和addMapping注册一个新的Servlet到指定URL路径。这相当于在应用的路由表里“凭空多了一个接口”只要请求命中这个URLServlet里的恶意逻辑就会执行。排查时要重点看容器里是否有不在web.xml或注解扫描范围内的Servlet。第二种是Filter型内存马这是目前实战中最常见的。原理和Servlet类似也是通过反射获取StandardContext但注册的是Filter并且拦截路径设置为/*。因为Filter会先于Servlet处理请求攻击者只要在doFilter方法里加一段判断逻辑——比如检查请求头里是否带着约定好的Key带上就执行命令不带就正常放行——就能在不影响业务的前提下把恶意后门隐藏在所有请求流量中。这也是我这次遇到的类型排查难度比Servlet型高不少因为平时很少有人去核对当前应用注册了几个Filter。第三种是Listener型内存马基于ServletContextListener、ServletRequestListener这类监听器实现。它不主动拦截请求而是等事件触发时执行代码比如每次创建Session时执行一段逻辑。这个形态更隐蔽但触发条件比较苛刻实战中用得相对少。这三种形态背后注入过程基本一致拿到运行中的ApplicationContext或StandardContext通过反射调用addXXX方法完成注册。所以从防御视角看只要堵住“反射调用Context注册接口”这个关键动作整条注入链就会被拦腰斩断。2.2 攻击链路全流程复盘一次完整的Godzilla-Suo5攻击通常走这么几步。第一步利用Web应用的任意漏洞拿到代码执行点常见入口包括反序列化漏洞、表达式注入、JNDI注入、文件上传配合解析漏洞等。第二步把恶意字节码加载进JVM。字节码可能由漏洞利用链直接传入也可能是先落一个很小的Loader文件再动态加载但核心逻辑都在内存里生成类。第三步通过反射获取容器Context把恶意Filter、Servlet或Listener注册进去这一步完成后攻击者已经拥有了一个不依赖文件存在、随进程存活的后门。第四步用Godzilla连接这个后门发送加密指令执行命令、读写文件、加载更多插件。第五步引入Suo5建立隧道把Godzilla的流量代理到更深处形成一条稳定、加密、行为上接近正常访问的通道然后开始横向移动。2.3 攻击落地的关键前置条件不是所有Java应用都能被注入内存马有几个前提条件缺一不可。首先是应用必须运行在Servlet容器里典型的就是Tomcat、Jetty、Undertow、Spring Boot内嵌容器其次是应用必须存在可被利用的代码执行漏洞这是源头再次是应用依赖或容器本身允许被反射访问内部类很多反序列化链之所以好用就是因为可以连续反射调用Context相关方法。实战中还有一个很容易被忽视的条件注入后类能不能被正确加载和ClassLoader体系密切相关。如果漏洞点所在的ClassLoader和容器Context不属于同一个加载域注入就可能失败。这也是为什么很多攻击者会优先找Spring Boot应用——内嵌容器的类加载结构相对简单更容易一次注入成功。3. 从流量侧发现可疑线索不靠解密也能定位3.1 Godzilla流量的协议特征很多人在流量检测时会犯一个错误总想着把Godzilla的加密流量解密出来再判断。这个思路既不现实也没必要。我们应该反过来从加密流量的“外在行为”和“结构特征”去识别。Godzilla客户端发出的POST请求有一个很明显的结构特征请求体通常是一整段经过Base64编码的Payload长度相对稳定并且会携带固定的参数名——默认的pass参数以及一个用于算法密钥的Key参数。虽然工具允许自定义但大多数攻击者不会费劲去改源码所以这些默认参数名本身就是重要信号。另一个被忽视的特征是“单请求单响应”的节奏。正常Web应用里一个页面会并行加载多个资源产生js、css、图片等不同类型的请求而Godzilla连接内存马时几乎不会出现正常的资源请求每一个请求都是在执行一段指令响应内容长度也往往比较均衡格式相对统一。把某个URL的请求序列拉出来看如果清一色全是POST响应长度高度相似且频率稳定那就要高度警惕了。3.2 Suo5隧道的流量形态Suo5这类HTTP隧道有个比较明显的破绽就是连接生命周期长、交互频率具有机器感。正常用户访问一个URL通常是点开页面后长时间不请求或者浏览一段时间然后离开Suo5隧道则像一个持续心跳每隔几秒就会有一个请求而且长时间不间断。我在那次排查中看到某个后台URL每天有上万个请求平均下来每秒0.1到0.2次单次响应时间很稳定这种规律性已经不是人类行为能解释的了。Suo5还会在HTTP头里留下一些特征。例如它常用Connection: Upgrade或者带上自定义的请求头来标识隧道ID部分版本还会使用Transfer-Encoding: chunked。更关键的是Suo5隧道背后的URL往往是一个静态资源路径比如/img/logo.png但产生的流量完全不像静态资源——没有浏览器缓存逻辑、没有条件请求、响应体却是动态生成的内容。抓包看到这种情况基本可以断定有问题。3.3 可落地的流量检测规则与脚本思路基于上面的特征我们可以直接在WAF或流量分析平台上加规则。我整理三组比较实用的检测思路已经在我负责的环境里跑过一阵误报率可控检测维度规则逻辑补充说明参数结构POST请求中同时包含pass与key参数且请求体为连续Base64串注意排查自定义参数名的变种可加入“无意义参数名超长Body”辅助判断请求节奏同一个IP对同一个URL每天请求次数异常多且请求间隔方差极小这里要按不同业务接口建立基线正常访问的方差明显更大响应特征响应体长度集中在某个固定区间Content-Type为application/octet-stream或text/html但无标准页面结构配合来源IP聚合效果更好连接行为单条TCP连接持续时间超过30分钟且期间持续有HTTP请求SSH、WebSocket等正常长连接需先排除如果环境里没有商业WAF可以用Python写一个简单的流量日志分析脚本逻辑很简单按源IP和目标URL聚合计算每分钟请求数、请求体长度均值与标准差、连接持续时间。凡是“高频、低方差、长连接”三个指标同时满足的直接拉进可疑列表。实操心得流量规则的误报率一定要在真实业务流量下反复校准最有效的办法是把正常业务接口的请求节奏先跑一周基线再对比新增流量。我见过太多团队因为误报太多最后把规则关掉反而漏了真攻击。4. 从内存侧排查与取证把藏起来的类“连根拔起”4.1 先用Arthas定位可疑类和调用栈流量侧发现异常后下一步必须快速在内存侧确认。首选工具是Arthas它是阿里开源的Java诊断工具attach到目标进程后可以直接查看类加载情况、反编译字节码、查看调用栈操作效率很高比直接dump堆再慢慢分析要快得多。Arthas上手很简单在服务器上解压后执行java -jar arthas-boot.jar选择目标Java进程即可。进入交互界面后我一般按这个顺序排查第一执行sc -d *Servlet*或sc -d *Filter*看看当前容器里所有Filter和Servlet类的完整信息。正常来说Filter数量应该是有限的而且每一个都能在web.xml、注解或者配置类里找到来源。只要出现一个类名看着可疑、但又说不上来在哪注册的Filter就要高度怀疑了。第二执行jad 类名反编译。反编译结果会直接暴露恶意逻辑比如doFilter里有没有判断特定请求头的代码、有没有调用Runtime.exec或ProcessBuilder。我记得当时反编译出来的Filter里面就有一行从请求头取值的逻辑约定一个自定义头名值匹配后直接执行命令这就是典型的“内存马后门”写法。第三执行thread查看全部线程栈寻找执行命令时留下的痕迹。如果此刻攻击者正在通过Godzilla交互栈里很可能会出现ProcessImpl、Runtime.exec相关调用再结合调用方类名就能把整个攻击链路的类串联起来。4.2 用jmap和堆dump做完整取证Arthas适合快速定位但取证环节必须保留完整的堆内存快照。用jmap -dump:live,formatb,file/tmp/heap.bin pid生成dump文件然后用Eclipse MAT或MemoryAnalyzer打开分析。分析时直接在OQL或者对象列表中搜索关键词包括但不限于Godzilla、Suo5、Filter、Shell、ClassLoader、ProcessBuilder等等。有一点要特别提醒生产环境的堆可能有好几个GBdump过程中对业务有一定影响live参数会触发一次Full GCSTW时间可能比较长。所以操作前一定要评估环境最好在低峰期做或者和业务方确认可接受的影响窗口。另外dump文件生成后建议立刻用gzip压缩再传输几GB的文件压缩后可能只有几百MB传输和分析都快很多。4.3 用一个简单的JDK脚本快速筛查可疑类加载如果不方便装Arthas或者要批量排查多台服务器可以写一个小工具。原理很简单遍历所有ClassLoader找出其中加载的类再和启动时的类集合做差集重点看多出来的自定义类是否在Filter、Servlet、Listener的白名单里。import java.lang.management.ManagementFactory; import java.lang.management.RuntimeMXBean; import java.net.URLClassLoader; import java.util.*; public class UnusualClassScanner { public static void main(String[] args) throws Exception { // 获取所有已加载类遍历类加载器 // 在实际使用中可配合Instrumentation.getAllLoadedClasses()实现 // 这里给出核心过滤逻辑 // 1. 过滤掉JDK、容器自带的类 // 2. 过滤掉业务白名单中的类 // 3. 剩余部分重点检查javax.servlet.Filter、javax.servlet.Servlet // 实现类并打印其ClassLoader来源。 } }当然这段代码只是提供思路实际运行需要通过-javaagent参数或者Attach机制拿到Instrumentation实例然后调用getAllLoadedClasses()枚举所有类的ClassLoader。这个思路也适合改造成Agent形式的实时监控后面防御部分会再展开。常见问题很多人在容器环境里执行jmap或Arthas都会遇到权限不足的报错。注意建议以root或容器内相同UID运行必要时加上--cap-addSYS_PTRACE后重启容器否则attach会被拒绝。5. 防御落地与加固实践从单点查杀到纵深防御5.1 方案一Tomcat Filter注册式防御查杀只是止损要防止再被打进来必须从运行时层面做防御。最轻量、最容易落地的方案是在应用里注册一个优先级最高的全局Filter对所有请求做一次安全校验。这个Filter的核心逻辑有两个部分。一是校验请求体结构如果发现请求同时包含可疑参数且Body为超长Base64或加密串直接拒绝访问二是校验“容器内的类”是否合规——在Filter初始化时扫描当前应用的StandardContext把已注册的Servlet、Filter类名记录下来启动后定时比对凡是新增的类不在白名单里的立即阻断并通过日志告警。// 核心伪代码扫描并阻断新增Filter public void check() { // 获取StandardContext Context ctx getCurrentContext(); // 遍历ctx.getApplicationFilterConfigs() for (FilterConfig cfg : ctx.getApplicationFilterConfigs()) { String className cfg.getFilterClass().getName(); if (!WHITE_LIST.contains(className)) { // 动态触发拦截请求的逻辑 throw new SecurityException(unexpected filter: className); } } }这个方案不依赖第三方组件代码量也不大普通Java开发完全能维护。但它有个天然弱点如果攻击者先于你的Filter注册或者恶意Filter的注册顺序在你的检查之后就可能被绕过。所以它只能算第一层不能作为唯一防线。5.2 方案二Agent机制与RASP深度防御真正高强度对抗下光靠Filter防御不够因为Filter本身就处在容器里和攻击者注入的Filter是“同一层”的博弈。比较靠谱的做法是把防御点下沉到JVM的Agent机制用RASP运行时应用自我保护的方式从底层拦截。Agent的思路是这样的通过premain或attach模式注册一个ClassFileTransformer在类加载时对关键方法做字节码增强。增强的目标一般是两个一是javax.servlet.http.HttpServlet.service()方法另一个是javax.servlet.Filter.doFilter()方法。在这两个方法入口处插入一段检测逻辑判断当前线程调用栈里是否出现了可疑的类加载器或不在白名单里的类。一旦发现栈中出现非预置的可疑类就可以直接抛出异常阻断该请求达到“即使注入成功也无法执行”的效果。public class SecurityTransformer implements ClassFileTransformer { Override public byte[] transform(ClassLoader loader, String className, Class? classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) { if (javax/servlet/http/HttpServlet.equals(className)) { // 使用ASM或ByteBuddy增强service方法 // 注入检测逻辑遍历当前线程栈过滤出类名关键词 // 当栈中出现可疑类时抛异常阻断请求 return enhanceServletMethod(classfileBuffer); } return classfileBuffer; } }业界很多商业RASP用的都是这套思路只不过检测规则和防御策略更完善。对于有研发能力的团队可以基于开源的ByteBuddy和ASM自己实现一个轻量RASP专防内存马性能和效果完全够用。踩坑提醒字节码增强会带来一定的兼容性风险尤其是不同Tomcat版本、不同Spring Boot版本对字节码结构要求不一致。做Agent增强前一定要搭建与生产一致的环境做回归测试避免出现类加载冲突或NoSuchMethodError。5.3 方案三纵深防御运营策略再从运营视角看防内存马不能只靠某一个组件而是整个链路上都要有探针。我落地过一套三层防御体系效果比较理想。第一层做边界流量检测。WAF和NTA设备上跑前面说的那些规则识别Godzilla特征、Suo5隧道行为、异常请求节奏做到攻击发生前或者刚发生时就能看到信号。第二层做主机和进程监控。尤其是在JVM启动后定期采集线程栈和类加载列表可以配置成每分钟采样一次存到日志平台一旦出现新的Filter或Servlet实例就触发告警。这类监控不需要太强关键是持续产生有规律的基线数据能对比。第三层做运行时RASP兜底。真到了请求层面Agent防御负责最后一道关宁可误伤可疑请求也不能让恶意代码执行。同时源头治理也不能漏。攻击链路的起点是漏洞利用建议把反序列化入口、表达式注入点、JNDI相关配置全部梳理一遍移除不必要的高危依赖比如commons-collections的旧版本。减少漏洞入口相当于让攻击者根本拿不到注入内存马的机会。6. 常见问题与排查技巧实录6.1 实战中高频踩坑点内存马排查容易踩的坑我集中列几个给后来人参考。第一个坑是Arthas attach不上目标进程。多数情况是权限问题尤其是K8s容器内运行的非root进程。解决办法有两个要么以root用户执行要么给容器加SYS_PTRACE能力。还有一个容易被忽略的点Arthas会加载到目标进程的ClassLoader里如果目标应用自己有一堆类加载器冲突可能attach后命令执行失败这时候换个低版本Arthas或者改用jstackjmap组合反而更稳。第二个坑是dump大堆导致服务卡死。之前我试过在一个堆大小12G的金融系统上直接jmap dump live结果Full GC持续了差不多30秒直接被业务方投诉。后来学乖了先jmap -histo:live pid看对象统计缩小范围后再决定要不要全量dump而且尽量选业务最低峰期操作。第三个坑是内存马被删除后反复出现。这种情况通常说明漏洞源头还没修复。遇到这种问题不要只盯着删类要先封锁漏洞入口。常见入口包括对外开放的反序列化接口、Shiro反序列化、Spring的SpEL表达式注入、Fastjson相关入口。把入口修了再清内存中的类才算真正处理完。第四个坑是Filter防御和RASP之间的规则冲突。防御Filter会对所有请求做白名单校验如果业务本身有大量动态生成Filter的需求比如某些热加载功能就会产生误杀。解决思路是给防御Filter设置可信扫描路径白名单那些动态注册Filter的代码路径单独标注放行。6.2 一份可以直接照用的排查清单我把整体排查流程整理成清单方便现场应急时按顺序操作不会遗漏关键步骤。步骤操作核心命令或工具提升效率的关键点1确认异常进程top、ps -ef先找到CPU或内存异常的Java进程2抓线程栈jstack pid保留现场后续可关联分析命令执行线程3快速定位类Arthassc -d *Filter*优先排查Filter其次Servlet、Listener4反编译可疑类Arthasjad 类名确认恶意逻辑提取特征用于流量回查5全量内存取证jmap -dump:live,formatb,filexx.hprof低峰期执行压缩后离线分析6分析类与引用Eclipse MAT / OQL搜索关键词确认注入来源ClassLoader7漏洞源头修复排查反序列化、表达式注入、JNDI未修复前清理内存马是无效的8攻击入口防御Filter校验 Agent/RASP阻断注入动作防止二次进入9流量规则优化WAF/NTA更新规则加入本次提取的特征封堵同类攻击10持续监控线程栈、类加载基线采集与历史数据对比识别新型变种这份清单看起来简单但每一条背后都有实战细节。重点是不要跳过第7步我在太多项目里看到团队辛辛苦苦抓到内存马、结果漏洞源不修过几天又被同样方式打进来的情况。网络安全里最怕的就是“治标不治本”。按我的经验内存马防御最忌讳单点思维。现在很多团队只盯着RASP或者只盯着WAF实际对抗中攻击者会不断调整战术流量特征今天传一次就不再用了注入类名也一直在变。真正有效的方案是把我前面讲的流量行为基线、内存类加载监控、运行时Agent防御组合在一起让每个环节都去看自己能看到的部分最后把数据汇总起来分析。这样哪怕单点被绕过其他环节也能立刻补上信号。最后再分享一个小技巧如果应用的容器版本可控可以考虑把容器类加载器和业务类加载器严格分开并给容器相关的Context注册接口加一层启动白名单校验。很多注入型内存马的原理就是靠反射去调Context方法一旦入口被白名单锁死攻击者就算有字节码也注册不进去这类问题直接就从根上解掉了。当然这个方案改动面比较大要结合应用实际情况评估但对核心系统来说投入产出比还是很值得的。