哥斯拉JSP Webshell样本分析：静态特征、动态行为与检测思路

1. 从标题说起：这个项目到底在折腾什么

“哥斯拉jsp马分析”这个标题，第一次看到的人大概率会愣一下。哥斯拉不是电影里那只大怪兽吗？jsp我知道，Java Server Pages，做网站的老技术了。马又是什么？如果你在安全圈或者运维圈待过，应该能反应过来，这里的“马”指的是webshell，也就是一种放在服务器上的网页后门脚本。而“哥斯拉”是这类工具里比较有名的一个，它生成的webshell流量特征比较隐蔽，功能也强，常被用来做远程管理。所以这个标题翻译成人话就是：对哥斯拉工具生成的JSP类型webshell进行样本分析、流量特征提取和检测思路梳理。

我之所以想写这个主题，是因为最近帮朋友看一个服务器告警，发现里面就躺着一个哥斯拉的JSP马。当时第一眼扫过去，文件内容看起来像正常的业务代码，混淆做得挺细。后来花了不少时间才把它彻底捋清楚。这个过程里踩的坑、总结的方法，我觉得值得整理出来。这篇文章适合谁看？如果你是安全运维、应急响应人员，或者对webshell检测感兴趣的开发者，那下面的内容应该能帮你省下不少翻文档和试错的时间。如果你只是刚入门的安全小白，也没关系，我会尽量用生活化的类比把原理讲明白，保证你能跟上节奏。

需要提前说明的是，本文所有分析都基于公开的样本特征和常见的检测思路，不涉及任何具体工具的获取或使用指导。我的目标只有一个：让你在遇到类似样本时，知道从哪下手、看什么、怎么判断。

2. 哥斯拉JSP马的核心机制拆解

2.1 为什么JSP马在Java环境里这么常见

要理解哥斯拉的JSP马，得先明白JSP在Java Web应用里的位置。JSP本质上是一个被服务器编译成Servlet的模板文件，用户访问它的时候，服务器会执行里面的Java代码，然后把结果返回给浏览器。这个特性决定了JSP文件天生就有执行代码的能力。攻击者只要能把一个JSP文件写到服务器上，就能通过访问这个文件来执行任意Java代码。

你可以把JSP文件想象成一把放在公司前台的万能钥匙。正常情况下，前台只放访客登记表，但有人偷偷把一把能开所有门的钥匙藏在了登记表下面。只要他走到前台，拿起钥匙，就能进任何房间。哥斯拉的JSP马就是这把钥匙，而且它还会伪装成登记表的样子，让你一眼看不出来。

相比PHP或ASP的webshell，JSP马在Java环境里更隐蔽，因为Java的类加载机制和反射能力给了它更多操作空间。哥斯拉正是利用了这些特性，把恶意逻辑拆散、加密、动态加载，让静态文件扫描很难直接命中。

2.2 哥斯拉JSP马的加载流程与关键环节

一个典型的哥斯拉JSP马，从被访问到执行命令，大致会经历这么几个阶段。第一阶段是入口解密。你直接打开文件看到的往往是一堆乱码或者看似正常的Base64字符串，真正的核心代码被加密藏在里面。当请求带着特定参数过来时，入口代码会先解密出一段Java类字节码。第二阶段是动态加载。解密出来的字节码通过自定义的类加载器加载到JVM里，这时候真正的恶意逻辑才开始运行。第三阶段是命令执行与回显。加载后的类会解析请求里的参数，执行对应的操作，比如执行系统命令、读写文件、连接数据库，然后把结果加密后返回给客户端。

这个流程里最关键的环节是动态加载。因为恶意代码不是以明文形式存在于文件里的，静态扫描工具如果只做字符串匹配，很容易漏掉。我实测过几个样本，用普通的文本搜索找“Runtime.exec”或者“ProcessBuilder”这类关键词，结果一个都没搜到，原因就在这里。

2.3 流量层面的伪装逻辑

哥斯拉在流量层面也做了不少文章。它的请求和响应都经过加密，而且加密后的数据看起来像随机的二进制或者Base64字符串，没有明显的特征头。更麻烦的是，它会把加密数据放在Cookie、请求体或者自定义Header里，具体位置可以通过配置调整。这就导致基于固定特征的流量检测规则很容易失效。

我个人的理解是，哥斯拉的设计思路就是“尽量不留下静态特征”。文件内容加密、类名随机、参数名可配置、流量加密，这一套组合拳下来，传统的基于特征库的检测手段确实会吃力。但这不代表它无懈可击，后面我会讲怎么从行为层面去抓它。

3. 样本静态分析：从文件本身找突破口

3.1 文件结构与混淆手法识别

拿到一个疑似哥斯拉的JSP文件，第一步肯定是看文件内容。但别指望一眼就能看出问题，因为它的混淆做得比较细。我一般会先看几个地方。第一是文件开头的Page指令，正常的JSP文件通常会有<%@ page language="java" ... %>这样的声明，哥斯拉的样本往往也会保留，用来伪装成正常页面。第二是看有没有大段的Base64字符串或者十六进制字符串，这些很可能是加密后的载荷。第三是看有没有自定义的类加载逻辑，比如继承ClassLoader的匿名内部类，或者调用defineClass方法。

这里有个小技巧：你可以把文件里的长字符串提取出来，尝试用Base64解码。如果解码出来是一堆乱码，那可能是加密过的；如果解码出来是Java字节码的魔数CAFEBABE开头，那基本可以确定是动态加载的载荷。我遇到过几个样本，Base64解码后直接就是class文件的字节码，连解密都省了，这种属于配置比较粗糙的。

3.2 关键函数与类名追踪

哥斯拉的JSP马虽然混淆了内容，但有些东西不太好完全隐藏。比如它最终要执行命令，就绕不开java.lang.Runtime或者java.lang.ProcessBuilder。虽然这些类名可能被拆分成字符串拼接，或者通过反射调用，但在字节码层面还是会留下痕迹。我的做法是，先把文件里所有字符串常量提取出来，然后找那些看起来像类名或方法名的片段。比如看到“java.lang.Runtime”被拆成“java.lan”+“g.Runti”+“me”，这种拼接方式本身就值得警惕。

另外，哥斯拉的样本里经常会出现一些特定的类名，比如以“Godzilla”开头或者包含“gsl”字样的类。虽然这些名字可以改，但很多公开样本里还是保留了默认命名。如果你在文件里看到类似GodzillaClassLoader或者gsl.payload这样的字符串，那基本就可以确认了。

3.3 静态分析工具的选择与使用要点

做静态分析，工具顺手很重要。我常用的组合是：文本编辑器加十六进制查看器，再加一个Java反编译工具。文本编辑器用来快速浏览文件结构和字符串，十六进制查看器用来看那些不可打印字符和加密数据的分布，反编译工具用来把提取出来的class字节码还原成Java代码。

这里有个坑要注意：不要直接用反编译工具去反编译整个JSP文件，因为JSP文件本身不是标准的class文件，反编译工具会报错。正确的做法是先把JSP文件里的加密载荷提取出来，解密或解码成class字节码，然后再用反编译工具打开。我一开始不知道这个，直接把JSP文件拖进反编译工具，结果什么都看不到，白白浪费了半小时。

还有一个经验是，静态分析的时候要养成记录的习惯。把可疑的字符串、类名、方法调用都记下来，后面做动态分析或者写检测规则的时候会用得上。我一般会用一个简单的表格来整理，列包括：文件路径、可疑字符串、出现位置、推测用途。这样后面复盘的时候一目了然。

4. 动态行为分析：让马自己跑起来

4.1 搭建安全的分析环境

动态分析的意思就是让这个JSP马在受控环境里运行起来，观察它的行为。这一步风险比较高，所以环境隔离必须做好。我的做法是：用一台独立的虚拟机，不连生产网络，只保留一个内部网络用来和我的分析机通信。虚拟机上装一个干净的Tomcat或者Jetty，把JSP文件放进去，然后启动服务。

这里要特别注意：千万不要在你自己日常工作的机器或者连了公司内网的机器上跑未知样本。我见过有人图省事，直接在本地开发环境里打开样本，结果样本反过来扫描内网，差点出事。安全第一，隔离环境是底线。

4.2 请求构造与响应观察

环境搭好之后，下一步就是构造请求去触发马的功能。哥斯拉的客户端和服务器端有一套约定的通信协议，包括参数名、加密方式、命令格式等。如果你没有客户端，也可以手动构造请求，但需要先搞清楚它的参数规则。我的做法是先用静态分析找到入口代码里读取参数的部分，看看它期望的参数名是什么，然后尝试发送简单的命令，比如whoami或者id，观察响应。

响应数据通常是加密的，你需要用对应的解密逻辑去还原。如果静态分析已经找到了加密算法和密钥，那就可以写个小脚本来解密。如果没找到，也可以观察响应的长度和格式，对比不同命令的响应差异，间接判断命令是否执行成功。

4.3 行为监控与日志记录

在样本运行期间，我会同时开启几个监控手段。第一是JVM层面的监控，用jstack或者jcmd定期抓取线程堆栈，看看有没有异常的类加载或者命令执行线程。第二是系统层面的监控，用auditd或者简单的ps轮询，看看有没有新的进程被创建。第三是网络层面的监控，用tcpdump抓包，看看有没有外连行为。

这些监控数据后面会很有用。比如你发现样本执行命令时会创建一个/bin/sh进程，那就可以在检测规则里加上对ProcessBuilder.start的监控。再比如你发现它每隔一段时间就向某个外部地址发送心跳包，那就可以从网络流量层面去封堵。

5. 检测思路与排查技巧实录

5.1 静态检测规则的编写要点

基于前面的分析，可以总结出一些静态检测规则。但要注意，哥斯拉的样本变种很多，不能只靠一条规则打天下。我一般会从几个维度去写规则。第一是文件层面的异常，比如JSP文件里出现了defineClass调用，或者出现了自定义的ClassLoader。第二是字符串层面的异常，比如出现了拼接的类名、加密的载荷特征。第三是结构层面的异常，比如一个JSP文件里包含了大量的Base64字符串，而且这些字符串的长度都是4的倍数。

这里要提醒一点：静态规则容易误报。比如有些正常的框架也会用自定义类加载器，有些业务代码也会用Base64编码。所以规则写完之后一定要在正常样本上跑一遍，看看误报率能不能接受。我个人的经验是，宁可漏报也不要高误报，因为高误报会让运维人员对告警麻木，反而更危险。

5.2 动态检测与行为埋点

动态检测的核心是监控敏感操作。在Java环境里，最直接的敏感操作就是命令执行和文件操作。你可以通过Java Agent技术，在Runtime.exec、ProcessBuilder.start、FileOutputStream等关键方法上埋点，记录调用栈和参数。这样即使样本加密了流量、混淆了代码，只要它最终调用了这些方法，就会被抓到。

我试过用Java Agent做一个简单的监控，效果还不错。样本执行whoami的时候，Agent直接打印出了调用栈，里面清清楚楚地显示了从JSP入口到命令执行的完整路径。这个路径后来成了我写检测规则的重要依据。

5.3 常见问题速查表

在实际排查中，我整理了一些常见问题和对应的处理思路，放在下面这个表格里，方便你快速查阅。

5.4 独家避坑经验分享

说几个我踩过的坑。第一个坑是过度依赖静态特征。有一次我看到一个样本，里面没有任何明显的敏感字符串，就以为它是安全的。后来动态跑起来才发现，它把恶意逻辑藏在了JSP编译后的class文件里，而不是JSP源文件里。所以静态分析一定要结合动态验证，不能只看表面。

第二个坑是忽略了JSP编译缓存。Tomcat会把JSP文件编译成class文件放在work目录下，如果你只检查了webapps目录下的JSP文件，可能会漏掉work目录下的编译产物。我后来养成了习惯，排查的时候两个目录都看。

第三个坑是流量解密时搞错了密钥。哥斯拉的密钥是可以配置的，不同样本用的密钥可能不一样。我一开始拿一个样本的密钥去解另一个样本的流量，解出来全是乱码，还以为是加密算法变了。后来才发现是密钥不匹配。所以做流量分析的时候，一定要先确认密钥来源。

6. 从检测到防御：把经验变成能力

分析样本的最终目的不是为了炫技，而是为了防御。基于上面的分析，我总结了几条在实际工作中比较有用的防御措施。第一是收紧文件上传权限，禁止Web目录执行脚本。很多JSP马能进来，就是因为上传功能没有做好校验，让攻击者把JSP文件传到了可访问的目录。第二是定期检查Web目录和编译缓存目录，发现可疑文件及时清理。第三是部署行为监控，对命令执行、文件写入等敏感操作做实时告警。

另外，我觉得很重要的一点是建立自己的样本库和特征库。每次分析完一个样本，就把它的特征提取出来，加到自己的检测规则里。时间长了，你会发现很多变种其实都有共同的祖先，抓住这些共同点，检测效率会高很多。

我个人在实际操作中的体会是，webshell分析这件事，工具和技术只是一部分，更重要的是耐心和细心。很多线索就藏在那些不起眼的细节里，比如一个多余的换行、一个不常见的编码方式、一个时间戳的异常。你多看一眼，可能就能发现关键证据。最后再分享一个小技巧：如果你不确定一个文件是不是webshell，可以把它放到一个隔离环境里，用最简单的请求去访问它，然后观察服务器的响应时间和资源占用。正常的JSP页面响应时间通常很稳定，而webshell因为要做解密和动态加载，响应时间往往会有波动。这个技巧虽然不能作为唯一依据，但可以作为辅助判断的手段。