antsword

每个请求体都存在以@ini_set("display_errors","0");@set_time_limit(0)开头

并且响应体的返回结果是base64编码发混淆字符，格式为：随机数 base64结果 随机数

菜刀

  • payload在请求体中，采用url编码+base64编码，payload部分是明文传输。

  • payload中有eval或assert、base64_decode这样的字符。

  • payload中有默认固定的&z0=QGluaV9zZXQ…这样base64加密的攻击载荷，参数z0对应$_POST[z0]接收到的数据，且固定为QGluaV9zZXQ开头。进行base64解码后可看到代码：@ini_set(“display_errors”,”0”);@set_time_limit(0);@set_magic_quotes_runtime(0);这段意思是首先关闭报错和magic_quotes，接下来去获取主机的信息。

    上面的完整内容是QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtpZihQSFBfVkVSU0lPTjwnNS4zLjAnKXtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO307ZWNobygiWEBZIik7J

冰蝎

2.0

先aes加密(cbc模式)然后base64编码

动态密钥生成

内置了十几个User-Agent头，每次请求时会随机选择其中的一个

3.0

AES加密 + base64编码

取消了动态密钥生成。在webshell里预留了密钥

默认的密钥是默认密码(rebeyond)的MD5的前16位

也就是md5(‘rebeyond’)[0:16]=e45e329feb5d925b)

内置了十几个User-Agent头，每次请求时会随机选择其中的一个

连接jsp的webshell的请求数据包中的content-type字段常见为application/octet-stream。

4.0

Accept字段（弱特征），通常是Accept: application/json, text/javascript, /; q=0.01 意思是浏览器可接受任何文件，但最倾向application/json 和 text/javascript

Content-Type字段（弱特征），通常是Content-type: Application/x-www-form-urlencoded

与冰蝎的前述版本相似，进行请求时内置了十几个User-Agent头，每次请求时会随机选择其中的一个。

连接的端口有一定的特征，冰蝎与webshell建立连接的同时，java也与目的主机建立tcp连接，每次连接使用本地端口在49700左右(就是比较大的端口)，每连接一次，每建立一次新的连接，端口就依次增加。

使用长连接，避免了频繁的握手造成的资源开销。默认情况下，请求头和响应头里会带有 Connection：Keep-Alive

有固定的请求头和响应头(弱特征。是因为使用了默认的密钥情况下才有固定的头。如果更改了不使用默认密钥就没有了)，请求字节头：dFAXQV1LORcHRQtLRlwMAhwFTAg/M ，响应字节头：TxcWR1NNExZAD0ZaAWMIPAZjH1BFBFtHThcJSlUXWEd

默认密钥:e45e329feb5d925b

哥斯拉

Cookie中有一个非常关键的特征，最后会有个分号

响应体的数据有一定特征，哥斯拉会把一个32位的md5字符串按照一半拆分，分别放在base64编码的数据的前后两部分。整个响应包的结构体征为：md5前十六位+base64+md5后十六位。

User-Agent字段（弱特征），如果采用默认的情况，会暴露使用的jdk信息。不过哥斯拉支持自定义HTTP头部，这个默认特征是可以很容易去除的。

Accept字段（弱特征），默认是Accept:text/html, image/gif, image/jpeg, *; q=.2, /; q=.2。同上，这个也可修改，只能作为辅助检测的特征。

Accept（弱特征）: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8

payload特征：
jsp会出现xc,pass字符和Java反射（ClassLoader，getClass().getClassLoader()），base64加解码等特征
php，asp则为普通的一句话木马

小发现:

(不是绝对的,也可能是nginx反向代理导致的)

如果请求头里的HOST头位于比较后的位置。那么要么是冰蝎。要么是哥斯拉。

因为一般的host头都位于前面的位置

如：

1
2
3
4
5
6
GET /hackable/uploads/shell.php?pass=852 HTTP/1.1
Content-type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)
Host: 192.168.66.136
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

区分哥斯拉和冰蝎子的：

请求体

哥斯拉的一般是这两种

1
2
3
4
5
6
pass=AWEzAAN%2FWFI3XHNGaGBQWDEHPwY4fSQAM2AIDw%3D%3D（base64编码）
或者
​
:•T[6•
L9e•[aqP•)[T\••O9t
这种乱码的

冰蝎的虽然也是乱码。但是请求的参数好歹还是都是英文字符和数字

1
F1w4ahdSJGUxG3t11sfr6qxbThq9VnL7i6K1/NzHsb0s9eQIfj2qDW/r5OeNJjI0U/BrUp2pHtrtCkdiUeJVIKFzCMSfe8yhEddJFJideje6Eb0dtrHHd9YYaZcxqQL2FFusmCXFICrCh3MsG+BYZHKbNVkWJrsTiu/1VBPV9CBkJzPBO4aH98EBFycyQbpGCHjAPaZmbaIIVWenbm642/xYr85uQ5/K74vlQ9wR5iGLZvyH8WZOF0YpqhxjkApKeShoSGX/C87NiqMTVAB+DcFNf4HaitS1o7Q6kXnUET00L5irn+WdNis2mvNEzr+DGay6LSKKD9kDl6iTKD/1aiXfk5EgH4PfR0/aXCEKTsFW29So6wbhR6u4H3/

补充：CS 远控码的特征

1
2
3
4
5
6
7
端口： 默认 50050 
HTTPS 证书：默认证书中，别名、所有者等信息全是 CobalStrike 
UA：默认 CS HTTP 流量的 UA 是 MSIE 
Beacon： CS 上线时会先投递一个小 stage ，然后去 beacon server 下载 stage，通过访问默
认的 uri 获取 cs 的 shellcode，从而识别到 cs beacon stagin 的特征。
心跳包特征 a) 间隔一定时间，均有通信，且流级上的上下行数据长度固定；
数据特征a) 在请求的返回包中，通信数据均隐藏在jqeury*.js中。

是否为误判的判断处理:

判断冰蝎（Cobalt Strike）或哥斯拉（Godzilla）告警是否为误报的具体步骤

个人理解:补充:

只需要判断到底是不是webshell木马的流量就行,如果存在明显的弱特征符合并且正常的请求头里一定不可能存在这种形式的弱特征那么基本就不是误报,如果攻击者对这方面做得很好,判断不出来就需要分析前后的包然后查看响应内容拿密钥解密什么的看看关键词什么的是否为恶意(可能存在那种刚好的正常的业务也存在相同参数的情况,所以需要尝试用key看看能不能解密响应之类的,或者看看正常的这块业务的代码是否存在这个参数去判断是否为误报),或者查看前后是否存在短时间高频率且异常路径的请求包和响应之类的

判断是否为误报时，

第一步:应检查是否存在典型的 Webshell 请求特征，而不是一开始就追踪执行行为。

比如哥斯拉的cookie是多了个分号

哥斯拉的UA头里存在jdk版本

更多的弱特征看上文

这种正常的请求里决不可能存在的如果出现那么就是webshell流量,没有误判

不管payload里面写了什么还是测试的语句了,至少没有问题不是误报.确定为webshell流量

所有的正常的请求头一般host请求头都是放在第二个位置,

但是webshell的流量的请求头host都是放在比较后面的在请求包里

HOST请求头在UA之后之类的

可以直接通过第一步判断是最好的,但是如果不行就去通过第二步尝试判断:

第二步:

高隐蔽哥斯拉流量
  • 现象：攻击者删除分号，UA伪装为Chrome，但请求体含pass=xxx。
  • 判定：
    • 解密pass参数，发现Runtime.exec("curl http://恶意IP")，确认攻击。
    • 可能存在那种刚好的正常的业务也存在相同参数的情况,所以需要尝试用key看看能不能解密响应之类的
    • 或者看看正常的这块业务的代码是否存在这个参数去判断是否为误报

第三步:

时间与频率：攻击流量通常高频、短时触发。

查看url路径是否存在关联

  • 若告警URL为业务无关路径（如/upload/xxx.jsp），风险较高；
  • 若为正常业务接口（如/api/login），需结合参数进一步判断。

1. 提取告警流量特征

  • 请求/响应头检查：
    • User-Agent：冰蝎默认UA可能为Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36，哥斯拉可能为空或自定义UA。
    • Cookie：哥斯拉Cookie中通常包含;分隔的Base64字段（如rememberMe=xxx; PHPSESSID=xxx），冰蝎可能使用固定Cookie名（如SessionID）。
  • URL路径：
    • 冰蝎默认路径如/submit.php、/gate.php；哥斯拉可能使用/admin/login.php等伪装路径。

2. 分析请求体与响应体

  • 参数特征：
    • 哥斯拉：参数名可能为pass、data，值为Base64+AES加密数据；冰蝎常用cmd、id等参数，加密数据长度固定。
    • 检查是否存在长Base64字符串或无意义二进制数据。
  • 响应特征：
    • 哥斯拉：返回内容可能含pageContext、ClassLoader等Java反射关键词；
    • 冰蝎：返回数据可能为加密后的二进制格式（如Beacon心跳包）。

3. 解密验证（关键步骤）

  • 哥斯拉：
    1. 提取请求中的pass参数值（密钥），尝试用AES解密Base64数据。
    2. 若解密后含Runtime.getRuntime().exec()或文件操作命令（如whoami），则为真实攻击。
  • 冰蝎：
    1. 检查流量是否使用SSL，提取JA3指纹（冰蝎默认JA3指纹可匹配）。
    2. 若为HTTP，尝试解密数据（默认密钥为Tk5UU1NM），查看是否含Beacon配置信息。

4. 上下文关联分析

  • 时间与频率：
    • 攻击流量通常集中在短时间内高频触发（如1分钟内多次POST请求）。
  • 业务场景：
    • 若告警URL为业务无关路径（如/upload/xxx.jsp），风险较高；
    • 若为正常业务接口（如/api/login），需结合参数进一步判断。

5. 日志与行为溯源

  • 服务器日志：
    • 检查对应IP的访问记录，确认是否在告警时间点有异常文件创建（如webshell.jsp）。
  • 文件监控：
    • 若上传路径存在可疑文件（如.jsp、.php），结合文件哈希与威胁情报匹配。

6. 误报可能性排查

  • 加密业务流量：
    • 部分业务系统使用AES加密传输数据（如医疗、金融），需与开发确认是否合法。
  • 扫描器干扰：
    • 安全扫描器（如AWVS、Nessus）可能触发类似特征，需对比扫描任务时间线。

总结判断流程图

1
2
3
4
5
告警触发 → 提取特征（UA/URL/参数） → 匹配已知工具特征  
   ↓                            ↓  
是 → 解密验证恶意指令 → 确认攻击  
   ↓                            ↓  
否 → 检查业务合理性 → 关联日志/文件 → 判定误报

示例误报场景

  • 哥斯拉误报：某系统使用Base64加密传输业务数据，但无pass参数或反射关键字。
  • 冰蝎误报：内部工具使用固定Cookie名SessionID，但未加密且无Beacon行为。

通过以上步骤，可系统化区分真实攻击与误报，提升告警分析效率。