【流量分析】Godzilla分析
一、哥斯拉流量的特点：
1.User-Agent (弱特征)
哥斯拉客户端使用JAVA语言编写，在默认的情况下，如果不修改User-Agent，User-Agent会类似于Java/1.8.0_121（具体什么版本取决于JDK环境版本）。但是哥斯拉支持自定义HTTP头部，这个默认特征是可以很容易去除的。
2.Accept（弱特征）
Accept为text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
3.Cookie (强特征)
哥斯拉的作者应该还没有意识到，在请求包的Cookie中有一个非常致命的特征，最后的分号。
4.请求体特征 (较强特征)
因为无法准确识别加密的请求体，所以只能采用比较宽泛的匹配条件去匹配请求体特征，宽泛的匹配思路其实就是基于区别大部分正常的数据包，加密数据包自身体现的特征。这种宽泛的匹配在一些情况下可能会带来误报，因此有时候难以作为一种非常有效的检测手法。
哥斯拉支持对加密的数据进行base64编码以及原始的加密raw两种形式的通讯数据，对于请求体的检测也要考虑两种情况。
哥斯拉在进行初始化时会产生一个比较大的数据包，后面进行命令执行等操作时产生的base64数据包会比较比较小。在长度上做一个匹配条件在一定程度上也可以降低误报率。
对于原始加密raw请求体，没想到比较好的方法，目前只想到到了匹配较多的不可见字符的思路。
和请求体一样，请求响应体也分两个格式，base64编码的和原始加密raw数据。如果请求体采用base64编码，响应体返回的也是base64编码的数据。在使用base64编码时，响应体会出现一个很明显的固定特征。这个特征是客户端和服务端编写的时候引入的。
从代码可以看到会把一个32位的md5字符串按照一半拆分，分别放在base64编码的数据的前后两部分。整个响应包的结构体征为：md5前十六位+base64+md5后十六位。
5.哥斯拉会相应3次
01 通过Burp抓包可知，第1个请求会发送大量数据，该请求不含有任何Cookie信息，服务器响应报文不含任何数据，但是会设置PHPSESSID，后续请求都会自动带上该Cookie。
02 可以看到，第2个请求中已经自动带上了第1个请求中服务器响应返回的Cookie值，并且第2个请求中只有少量的数据。
第3个请求
第3个请求与第2个请求完全一致。
6.哥斯拉加密的方式
7.哥斯拉会长时间有 Connection: keep-alive
二、题目：hw-典型哥斯拉流量
一开始可以发现：
188一直在向180发送syn包 是188在Ping180，看端口有没有开启，要看180有没有回包 rst ack seq=1 ack=1 win=0 len=0
(ip.src == 192.168.162.180 ) && (ip.proto == 6) 输入筛选条件，红色的是没有开放的；看返回包，返回包协议中携带syn、ack的包是正常通信的。
综上第一题的答案是 80，888，8888
追踪流量查看用户做了什么，很多都是404的，后面上传了shell.jsp后才有一些是200的
···
GET /index.jsp?pwd=admin&cmd=ls HTTP/1.1
Host: 192.168.162.180
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: JSESSIONID=9467B2C71C4B258B7BFB8CCCA6C7C564
Upgrade-Insecure-Requests: 1
HTTP/1.1 200
Server: nginx
Date: Mon, 30 May 2022 14:38:24 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 17
Connection: keep-alive
X-Cache: MISS
<h1>Hello world!
GET /test.jsp?pwd=admin&cmd=ls HTTP/1.1
Host: 192.168.162.180
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: JSESSIONID=9467B2C71C4B258B7BFB8CCCA6C7C564
Upgrade-Insecure-Requests: 1
HTTP/1.1 200
Server: nginx
Date: Mon, 30 May 2022 14:38:31 GMT
Content-Type: text/html;charset=GBK
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Cache: MISS
Content-Encoding: gzip
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>..........</title>
</head>
<body>
<pre>bin
boot
cdrom
dev
etc
flag
home在这里插入代码片
可以看到用户挂马之后看了下根目录下有啥，
确实有个flag
查看的内容都是通过shell.jsp来实现的
01 通过Burp抓包可知，第1个请求会发送大量数据，该请求不含有任何Cookie信息，服务器响应报文不含任何数据，但是会设置PHPSESSID，后续请求都会自动带上该Cookie。
02 可以看到，第2个请求中已经自动带上了第1个请求中服务器响应返回的Cookie值，并且第2个请求中只有少量的数据。cookie还是呆分号的
可以判断为哥斯拉流量。
三、哥斯拉流量的加密方式
from Crypto.Cipher import AES
import binascii
import zlib
# 密钥，与 JSP 代码中的密钥相同
key = b'748007e861908c03'
# 要解密的加密数据（十六进制形式）
encrypted_hex_data = "b5c1fadbb7e28da08572486d8e6933a84c5144463f178b352c5bda71cff4e8ffe919f0f115a528ebfc4a79b03aea0e31cb22d460ada998c7657d4d0f1be71ffa"
def decode(data, key):
cipher = AES.new(key, AES.MODE_ECB)
decrypted_data = cipher.decrypt(data)
return decrypted_data
def ungzip(in_str):
s = zlib.decompress(in_str, 16 + zlib.MAX_WBITS).decode()
print("Decoded and Unzipped:\n", s)
# 将十六进制数据转换为字节序列
encrypted_bytes = bytes.fromhex(encrypted_hex_data)
# 解密数据并解压缩
decrypted_data = decode(encrypted_bytes, key)
ungzip(decrypted_data)
得到结果可得
所谓的加密是一个aes形式的ecb加密外加unzip的形式：
对响应包截取该md5后的前16位以及后16位
对截取后的响应包内容进行 base64解码/raw原始数据形式 + aes解密 + gzip解压缩
1.一定要是http的形式
2.截取的内容一定是分段后的内容也就是数据运输的内容
3.请求包相应包都是如此
4.一定要是原始数据
我们把挂着哥斯拉jsp马的数据全部都读取以下并翻译
cmdLinewhoami
www
cmdLinecat /www/wwwroot/test.com/key
the key is 1****y
cmdLine ifconfig
docker0: flags=4099
ether 02:42:13:c6:39:05 txqueuelen 0 (以太网)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 27 bytes 4460 (4.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163
inet 192.168.162.180 netmask 255.255.255.0 broadcast 192.168.162.255
inet6 fe80::3c58:317b:f1ee:d5fc prefixlen 64 scopeid 0x20
inet6 fe80::8925:adf7:1d2a:2c41 prefixlen 64 scopeid 0x20
ether 00:0c:29:df:95:a8 txqueuelen 1000 (以太网)
RX packets 2360170 bytes 3041706453 (3.0 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 608498 bytes 43248948 (43.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens38: flags=4163
inet 192.168.101.132 netmask 255.255.255.0 broadcast 192.168.101.255
inet6 fe80::68af:1a5:a54c:7366 prefixlen 64 scopeid 0x20
ether 00:0c:29:08:04:93 txqueuelen 1000 (以太网)
RX packets 31049 bytes 2298483 (2.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 749 bytes 65158 (65.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (本地环回)
RX packets 80607 bytes 17837506 (17.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 80607 bytes 17837506 (17.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth038e57f: flags=4163
inet6 fe80::1cf7:44ff:fea5:1deb prefixlen 64 scopeid 0x20
ether 1e:f7:44:a5:1d:eb txqueuelen 0 (以太网)
RX packets 10 bytes 1199 (1.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 172 bytes 27148 (27.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
cmdLinenmap
Cannot run program “nmap”: error=13, 权限不够
cmdLinels /
bin
boot
cdrom
dev
etc
flag
home
lib
lib32
lib64
libx32
lost+found
media
mnt
opt
patch
proc
root
run
sbin
snap
srv
swapfile
sys
tmp
usr
var
www
cat /flag
flag{9236b29d-5488-41e6-a04b-53b0d8276542}
对于http流其实可以一个个查看回头输入http会自动光标定位到刚才的位置
