CS后门源码特征分析

发表于 更新于 分类于 阅读次数：

CS后门源码特征分析

cs?cs go！来看看经典后门的流量分析吧

首先准备好cs在kali中解压后进入cs的文件目录中

1
chmod 777 *  #然后使用chmod命令给所有的文件可读可写可执行权限

然后设置并启动cs

1
./teamserver lhost 密码

之后在物理机上运行cs

登陆账号密码后进入后台

新建一个监听器

生成一个木马文件并选择监听器生成并保存在文件夹中

在物理机中双击运行文件发现物理机成功在后台上线

然后抓取流量包，使用筛选指令：

1
ip.addr==192.168.1.225

在流量包中找到特征码==KZlL==

使用java的==checksum8==算法来计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public class EchoTest {

  public static long checksum8(String text) {

    if (text.length() < 4) {

      return 0L;

    }

    text = text.replace("/", "");

    long sum = 0L;

    for (int x = 0; x < text.length(); x++) {

      sum += text.charAt(x);

    }

 

    return sum % 256L;

  }

 

  public static void main(String[] args) throws Exception {

    System.out.println(checksum8("KZlL"));

  }

}



结果输出为93，说明了这是一个64位的木马

这里再生成一个32位的后门木马

在win7虚拟机中运行木马文件可以看到win7在监听器中上线

在wireshark打开流量检测找到第一个请求头

使用java的==checksum8==算法来计算特征码==Y2Wz==

可以得到结果92而92也正好表示为32位木马文件

创建一个http的规则文件，命名位==cshttp==将规则写入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# suricata规则
# http-beacon-staging，向c2服务器发起get请求，下载大小约210kb的stager，请求地址符合checksum8规则
# 调用lua检查uri是否符合checksum8规则：计算uri的ascii之和并与256做取余计算，余数为92则符合规则
alert http any any -> any any (gid:3333; sid:30001; rev:1; \
    msg:"http-beacon-checksum8-path-parse"; \
    classtype: http-beacon; \
    flow: established, to_server; \
    urilen:4<>6; \
    luajit:checksum8_check.lua; \
)


# checksum8_check.lua
function init (args)
    local needs = {}
    needs["http.uri"] = tostring(true)
    return needs
end

function match(args)
    local uri_raw = tostring(args["http.uri"])
    local uri = string.sub(uri_raw, 2, -1) -- 去除uri中的"/"
    local sum = 0

    for i=1,#uri do
        local x = string.sub(uri,i,i)
        sum = sum + string.byte(x)
    end

    if (sum % 256) == 92 then
        return 1 -- 符合checksum8规则，匹配成功
    else 
        return 0 -- 不符合checksum8规则，匹配失败
    end
end

然后放入suricata的规则文件夹之中运行之后再查看日志

之后再生成一个https型的后门，先创建一个新的监听器

再生成一个可执行的恶意文件

之后在物理机中运行用wirehshark进行流量监测可以发现JA3码具有明显的特征

编写规则文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# https-beacon-ja3指纹，client-hello
alert tls any any -> any any (gid:6666; sid:30005; rev:1; \
    msg:"https-beacon-ja3-hash"; \
    classtype: https-beacon; \
    ja3.hash; pcre:"/652358a663590cfc624787f06b82d9ae|4d93395b1c1b9ad28122fb4d09f28c5e|72a589da586844d7f0818ce684948eea|a0e9f5d64349fb13191bc781f81f42e1/"; \
)


# https-beacon-ja3s指纹，server-hello
alert tls any any -> any any (gid:6666; sid:30006; rev:1; \
    msg:"https-beacon-ja3s-hash"; \
    classtype: https-beacon; \
    ja3s.hash; pcre:"/fd4bc6cea4877646ccd62f0792ec0b62|15af977ce25de452b96affa2addb1036|b742b407517bac9536a77a7b0fee28e9/"; \
)

查看日志

加壳免杀处理流量分析

因为是在无安全软件的干扰下进行的我们直接用一个最简单的upx壳来当作免杀处理

加壳之后先运行64位的后门软件,然后运行抓包，再将心跳包后缀改为vir文件解密

看上去upx壳并不能对最后解析的结果产生作用

再运行32位的http后门，将生成的心跳包用工具解密

可以看到同样也将心跳包的内容解密出来了

由此可见一些简单的加壳对心跳包的解读是没有影响的