RealWorld|针对某特殊群体的供应链打击2
1. 细节分析
1.1 样本捕获
今天我在值班，组内的同事发给我一个GitHub项目链接，他们怀疑这个项目可能涉及钓鱼。项目的地址是：
https://github.com/TonyNPham/GodzillaPlugin-Suo5-MemProxy。
1.2 jar包分析
先把jar文件下载下来看看。使用反编译工具 jadx 查看 jar 包内容。
简单看了一下，这个jar包被 ALLATORI 混淆了。按照我们之前的经验，被 ALLATORI 混淆的一般都有问题。
这个jar包使用的ALLATORI不是收费版，混淆的没有那么严重，可以根据jar包中的代码反编译。下边是这个jar包使用的ALLATORI解密方法。
使用这个方法解密字符串：m;Q{m+L8R+J。
解密结果是：Suo5Servlet。说明我们的解密方法没有问题。
这个项目是用 swing 写的图形化界面，在 initView 的时候加了点东西，先判断了一下操作系统是不是 win，然后再判断是32 位还是 64 位。
详细的逻辑在 suo5Version 方法里面，代码差不多是下面这个样子。
我们可以看到通过SHowIcon获取到一个文件，再使用decodeGzipHex解压文件，使用get读取解压后的文件。
get方法里是熟悉的defineClass，通过这个我们可以确定，这个插件肯定要干坏事。
尝试了很多反编译工具，反编译的内容都都有一些问题。索性，我们查看了这些代码的smali代码。
查看showIcon的smali代码。
发现 showIcon 调用了一个变量。在代码里查看这个变量。
发现一处代码读取文件，将文件流赋予了this.i。这里被读取的内容混淆了，我们解密一下。
内容解密出来是。
那这里就很清晰了，就是读取jar包中的icon.png
这个jar包一共2.3MB，这个icon.png就占了1.7MB，肯定有问题。
查看initView的反编译代码，发现suo5Version有调用一些参数的逻辑。
重新阅读代码，在Suo5MemProxy中发现了类似的定义。
这里直接说结论，上面 initView 的时候，this.j和 this.d 分别是 dll 加载器（区分 32bit 和 64bit），通过计算 icon 的偏移，会生成一个 class 文件，通过 class 文件会在缓存目录下会生成microsoft10192开头.cache结尾的文件，这个东西是一个通过 jni加载dll的文件。
1.3 Class文件分析
我们先使用代码里的方法解出来class文件。class文件内容如下：
在类中定义了两个native方法 分别是enqueue和openProcess。经常用内存马的朋友应该会感觉熟悉，因为这里就是rebeyond提出的一种java内存加载shellcode的方法。
这里继续使用decodeHex解开字符串的内容，再将解开的内容写在缓存目录下，文件以microsoft10192开头.cache结尾。
在windows系统，这个文件在C:\Users\用户名\AppData\Local\Temp目录下。
1.4 DLL分析
使用file查看文件，这个文件是一个DLL文件。
把这个文件放入Ghidra分析。查看自定义的native方法。
这段代码与rebeyond提出的方法基本一致。
如果对这部分技术好奇，可以阅读Java内存攻击技术漫谈。
这里可以看到DLL中的native方法需要有一段shellcode传入，我们继续分析。
1.5 Shellcode分析
重新阅读一下suo5Version的代码。
可以看到传入了两个值，这两个值对应的不同系统。
● this.j = new int[]{38218, 128, 35621}; （64bit）
● this.d = new int[]{41346, 64, 341490};（32bit）
而 this.g和 this.b是（64bit 和 32bit 的 shellcode），偏移量：
● this.g = new int[]{536484, 16, 10354};
● this.b = new int[]{424526, 8, 14325};
使用shellcode的偏移读取icon.png文件，得到了一个shellcode文件。
使用hexdump、file查看这个文件。file返回这个是一个data。hexdump看不出来什么规律。
尝试使用capstone读取这段文件，反编译。
可以看到指令非常复杂，应该是做了逻辑混淆。
在shellcode运行以后，对系统行为进行监控。可以看到从java进程拉起来一个tcp请求，这个请求向45.76.176.189:443发送数据。
继续对45.76.176.189:443进行分析。可以看到45.76.176.189存在一个自签名的模仿微软live.com的域名，并且这个签名的启用时间就是8月10日。
查找类似签名方法的证书，发现了59.110.233.102和137.175.17.89这两个ip。
2. 总结
针对某特殊群体的供应链攻击一直以来都是热门，攻击者屡试不爽，受害者痛不欲生。我们应当谨慎，确保我们使用的软件和服务都来源于可信任的供应商，并定期进行安全审查。随着技术的发展，攻击者的手段也日益狡猾和高级，他们不再满足于简单的钓鱼攻击或恶意软件，而是转向了更复杂、难以检测的供应链攻击。
2.1 样本行为流程示意图
2.2 IOC
类型
信息
ip
45.76.176.189
ip
59.110.233.102
ip
137.175.17.89
md5
aa1b539a40e58bed3ec1342a45381610
md5
fc0669c42c96fb9008faab07d5b8c4f3
md5
70fc8b8321399a6e7e1b4b0ef015f735
md5
23c5eb0941829d2355b36d4b1bbe65ca
md5
017c4de9c2b641f51e9d988d9d9f7808
md5
a7e2b965712d389f89b16559dd91e08b
md5
6f5b480750e8b72a0b24995a82ecc475
4ff9bad8643d6ff
md5
c7252e0c3bb649072d668ecd39dacf70
cert.sha1
3ba4472305265d3c7e55f69026577149cf5652d2
cert.sha1
ea9c6d2e4590b8d4bbbbe6c0325a42b30e0045fd
cert.sha1
ca8a1998bb406ee9d13d8e7ed62dcf33334edf84
===
===
3.参考信息
https://paper.seebug.org/1853/
=================================
