FIN7 APT组织有趣的另类样本

样本

分析

第一部分载荷

由于只狩猎到了第一部分的载荷以及后续模块,故该样本的初始投递触发尚不清楚.

该模块下文简称”Load1”,该Load1模块为PowerShell的执行脚本.

该Load1首先定义了变量body用于存放加密的后续脚本模块.

随后调用GetTempFileName随机生成的文件名称,并拼接.ps1的后缀成为完整的文件名.(这句代码后续并没有什么作用,推测是做测试时留下的.)

调用FromBase64String将body中的编码字符进行解密.

解码结果看是乱码.后续可能还有其它操作.

接着通过DeflateStream对象将之前解码的数据进行解压缩,解压的缓冲区大小为59538并且该命令将不会返回任何内容.

将解压后的数据,使用GetString转换成为文本类型(可以看出是一个PowerShell的脚本),并调用IEX进行执行.

第二部分载荷

第二部分的载荷有着大量的混淆.

我们都知道PowerShell在怎么混淆最终都要变成能够执行的命令,也是是说解混淆的关键就在于如何在执行恶意功能前将解混淆的脚本Dump出来.

首先大致看一下混淆逻辑,通过Set-StrictMode, 将脚本设置为强制执行表达式、脚本和脚本块中的编码规则.

随后执行AaPr函数

调用zedEnb函数

调用innM函数

调用PMds函数

调用LoqvPF函数,Param是对输入的参数的数据类型进行绑定, 一旦脚本缺少参数，或者输入的参数类型不正确，就提醒用户.

该函数内部实际上就是将传入的字符进行重新拼接排序,也就是通过多个函数进行混淆.这个混淆思路与以往的还是有所不同的,通过大量函数进行混淆使得整个脚本充斥着大量的变量和函数.

随后输出了字符串9Sv7i82j+

其它的函数都是类似的混淆规则只是位置不同,将PMDS函数执行完成后,返回了如下字符串.

中间多次混淆规则类似,因为篇幅限制就不贴图了,执行完成上述后,Cbnli变量中就是解混淆后的数据.

解混淆的数据如下,可以看出是被Base64编码的数据.

接着通过FromBase64String进行解码.

接着获得DeflateStream对象,用于解压缩和第一阶段的脚本一样.

可以看到dLWDg函数内部是申请缓冲区.

VHAvub函数和第一阶段的脚本一样,通过调用DeflateStream对象将被Base64解码后的数据进行解压缩.

最后调用Dpsi.

Dpsi中还有混淆代码,这里我提取删减了一些,其实是个Load.

首先看下Allocate,这里一看就是动态获得VirtualAlloc

Call_method内部

首先获取System对象,通过System对象的GetType方法获得Microsoft.Win32.UnsafeNativeMethods对象.

通过Microsoft.Win32.UnsafeNativeMethods对象的GetMethod方法,动态获得GetProcAddress和GetModuleHandle的API地址.

通过GetModuleHandle获得传入字符串kernel32.dll的句柄,随后通过GetProcAddress获得VirtualAlloc的函数对象并返回.

接着通过Alloc_conf方法将获得的委托类型.

最后通过GetDelegateForFunctionPointer方法将非托管函数指针转换为委托.( VirtualAlloc)

调用VirtualAlloc申请内存地址.

获取CreateThread的委托对象.

调用CreateThread,创建线程执行解密的数据.

获取WaitForSingleObject的委托对象.

调用WaitForSingleObject,等待线程返回.

第三部分载荷

被解码的数据是一个x64位的DLL,该DLL导出了Reflective

Loader方法和DLLMain方法.

DLLMain方法里,核心功能主要是和C2服务器通讯,得到返回数据后,创建线程执行.

首先收集用户信息和网卡信息

连接C2服务器195.123.227.40,发送窃取的用户信息并接收服务器发送的数据.

通过CreateThread创建线程,执行远程下载的数据.

ReflectiveLoader方法是反射加载DLL.

总结

该组织在Powershell脚本方面,还是有一些建树的,第二阶段脚本的混淆方式与以往有很大的不同,主要通过函数拼接字符串进行混淆,该方式目前在VT上是100%免杀,第一阶段的脚本被上传后依旧只有7家杀软能够查杀,另外该样本也使用了多层套娃的模式,看来未来的脚本免杀路线应该会以无文件+套娃+混淆+多类型混合(脚本,可执行文件等)的形式出现.