事件背景

某重要活动结束前一天，安全的矛与盾星球内部交流群里有位蓝队兄弟扔出来三个公鸡队样本让群里还在的师傅帮忙分析一下，由此便展开了下面的分析经过。

分析经过

首先拿到样本之后，用file命令做简单识别，file能识别的文件格式还是很多的。但这三个样本不巧，被公鸡队做了手脚，已经混淆了文件头。

用010Editor打开文件，简单查看了下，发现文件当中存在明文字符串，整体来说此时样本比较奇怪。

这时候坤佬（@wonderkun）在群里来了句，看出来文件混淆的方式了，用0xEE异或即可得到混淆前的原文件。具体原理坤佬解释这是统计学：不知道异或的密钥是几个字节，所以要统计单字节，双字节和四字节。由于pe文件中出现最多的是 0x00 ，所以按照单字节统计，出现次数最多的就密钥，双字节，四字节以此类推。

看一下此时文件的头部的分布，的确0xEE出现次数最多，坤佬太强了，学到了。

按照坤佬的统计，并且结合文件后半部分存在明文，可得知只是头部数据被0xEE异或混淆，大概在010Editor中查看数据后，发现前0x400字节存在问题，所以只需要对前0x400字节做0xEE异或即可。

去除头部的混淆之后，1文件为EXE（console）程序，2文件为DLL，3文件依然是未知格式。

并且1.exe为微软签名的程序，结合2文件为DLL，3文件未知，以及常见的恶意软件loader加载方式，这里猜测2.dll为恶意DLL程序，通过运行1.exe实现白加黑DLL劫持，再加载运行3样本中实际的后门指令。又通过进一步分析，1.exe为MpRunCmd.exe，2.dll应该为mpclient.dll。

所以这里的mpclient.dll应该就是恶意软件的loader所在模块。IDA中直接载入，分析后发现，所有导出函数都会调用loader的加载函数，这样做可以保证loader一定会被执行。

接着对loader函数进行分析。首先是调用ShowWindow隐藏MpCmdRun.exe进程的窗口。

然后是获取程序的文件名，不过这个Filename始终没有被用到，猜测应该是之前从一些功能函数里copy的代码，没有删除不必要的函数调用。

最后是loader的主要函数，以字符串"kuailele"为解密key解密文件当中的后门指令，并加载。

跟进函数sub_180001870，首先是对明文字符串进行加密、解密，最后还是明文字符串，这里搞不懂作者想干啥。

此时得到的v2依然为宽字符串"C:\ProgramData\TU.IO"。接下来调用sub_180001710并传入v2，经过调试分析，作者自实现了GetProcAddress函数，采用计算字符串Hash并比较的方式，规避调用系统GetProcAddress，以及隐藏导入表函数的敏感特征。函数sub_180001710的实际作用是读取传入文件名也就是C:\ProgramData\TU.IO到Func程序全局变量当中。

‍

接下来调用sub_180001680函数对读取的文件内容进行解码。

跟进函数sub_180001680，发现函数第一个参数是需要解码的buffer，第二个参数为buffer的长度，第三个参数也就是a1（这里是"kuailele"）为key，第四个参数为key的长度，并且以key的长度-1为循环长度，对buffer的数据进行异或解码。这里存在一个问题，key的最后一个字节没有被用到，猜测可能是作者编写程序循环长度判断有些问题，这里正常应该以key的全部长度为循环异或解码。

接下来动态获取函数VirtualProtect并调用，修改Func指向地址的内存属性为64，也就是PAGE_EXECUTE_READWRITE。

‍

最后通过EnumObjects回调执行Func指向内存的指令。

为了验证分析的结果是否正确，这里笔者用星球专版CS IceRiver生成一个64位的beacon.bin文件，并以"kuailele"为key通过循环异或对beacon.bin进行编码，将编码后的文件复制到"C:\ProgramData\TU.IO"文件当中，然后双击执行1.exe，观察IceRiver是否收到beacon权限。

可以看到成功接收到了beacon权限，且所在进程为1.exe，这说明分析是正确的。

并不简单

上面分析的是白加黑loader的处理过程，奇怪的问题是即使对样本3文件进行循环异或编码，获取到的文件依然是未知格式，并且在010Editor当中也看不到任何明文数据，这说明样本3应该还有其他混淆的存在。群里那位蓝队的师傅说，这三个文件是通过钓鱼木马反向溯源到的远程文件，也就是说很可能在钓鱼木马当中存在对样本3的解码过程。

首先按照群里师傅提供的信息，这三个样本是在http://112.74.109.76:5559/下载到的。

确定是回连到CobaltStrike监听器。且回连地址为https://service-baw5g4iz-1309608249.bj.apigw.tencentcs.com，攻击者通过图标伪装的方式，诱导目标用户点击诱饵.exe上线。

由于已经确定是CobaltStrike C2，所以这里先决定对teamserver进行反制，利用CVE-2021-36798尝试DOS teamserver（可能没有什么效果，但总要尝试一下，尽人事听天命）。

接下来对钓鱼木马.exe进行分析。IDA载入，发现在入口函数的第一个调用的函数，被做了手脚，突兀的出现一条直接跳转到text段起始地址的指令。

并随着对text开始的指令进行分析，“诡异”也越来越多。

通过观察，发现text段开始的指令，应该就是添加了垃圾指令的shellcode，这时候为了避免IDA自动识别对分析的干扰，将text段开始所在的指令通过010Editor复制到shellcode.bin文件当中，这里长度笔者设置为到PE文件入口点start处。文件起始偏移为0x400，长度为0xc7150。

IDA中载入保存的shellcode.bin文件，以64 bit code反编译，在shellcode首地址创建函数，之后借助IDA F5大法反编译代码。

虽然作者在生成shellcode时采用填充了垃圾指令，但由于是jmp直接跳转的方式，在IDA中反编译过程当中，直接被优化掉了，这样也起不到干扰分析人员的作用了。

首先是函数sub_37DD，作用是动态获取一些函数的地址，并将函数地址存放到函数地址数组中，将该函数命名为init_functions，参数为function_tables。

跟进继续分析，经过动态调试分析发现，sub_3FC9函数为获取内存加载的模块基址，sub_4609函数为在模块内部搜索对应的函数。

对上层调用函数进行注释。接着作者自己实现了strlen函数，然后对字符串最后一个字节置0，这里没有什么实质的作用，这里GetCommandLineA相当于获取了当前程序的路径。

然后读取当前程序的文件内容到内存当中。

接着从偏移0x145C0C处，前0x400字节使用0xEE异或解码，最后复制MZ头到头部前2字节。这里操作为解码保存在当前程序当中的PE文件。

函数sub_1339经过调试，其作用为保存解码后的PE文件到文件当中，并执行该EXE文件。

接下来需要对解码出来的EXE文件进行分析，首先提取从偏移0x145C0C到文件末尾的所有数据，并对数据的前0x400个字节进行0xEE异或解码，然后复制MZ头到文件头部，得到一个新的EXE文件，称之为stage.exe。

将stage.exe载入到IDA当中，反编译main函数，IDA提示 function size too large。这里需要修改IDA安装所在目录下的cfg\hexrays.cfg文件，将MAX_FUNCSIZE从64修改到10240，再次反编译即可。

首先调用函数ShowWindow隐藏当前程序窗口，再解码编码后的实际地址，传入到作者自己实现的http_download函数当中，获取远程的文件，最后以"POLICE"字符串为解码key，循环异或解码样本3的数据，并将解码后的数据保存到C:\ProgramData\TU.IO文件当中，将样本1保存到C:\ProgramData\WhitLog文件中，样本2保存到C:\ProgramData\BlacLog文件中。

由此知道了样本3的上一层编码方法，对下载到本地的样本3进行两次解码，两次解码key分别为"POLICE"和"kuailele"，得到一个beacon.bin文件，该文件即公鸡队生成的stageless shellcode文件。

紧接着还要执行一段shellcode，首先作者通过单字节赋值的方式生成大长度的函数体，以此干扰分析人员和达到shellcode静态免杀的效果。

之后调用sub_140001110函数执行shellcode，这里执行shellcode的方式为通过SetPropA和PostMessageA实现，对于通过该回调函数执行shellcode的方式见到的并不是很多。

下面展开对函数sub_140001110的分析。首先获取粘贴板窗口进程ID。

函数sub_140001070的作用是判断目标进程是否为32位程序。

如果是32位程序，将会结束目标程序，什么也不干，并返回0。

否则将会在目标进程通过WriteProcessMemory写入shellcode的数据，并通过SetPropA函数设置回调函数地址为shellcode的地址，并通过PostMessageA函数触发shellcode执行。

通过动态调试，将内存当中的shellcode dump到文件shellcode_inject.bin文件当中，IDA中载入，以64 bit mode分析。

可以发现，与shellcode.bin的结构很相似，分析步骤相同，这里主要关注所做的动作。首先是从文件c:\programdata\WhitLog和c:\programdata\BlacLog中读取前面stage.exe下载保存的样本1、样本2的数据，再解码头部前0x400字节数据，再重新写入数据到文件当中。

然后注册表添加自启动，重命名白加黑文件，确保在执行白文件后能执行loader所在DLL。

最后是调用函数CreateProcessA执行C:\ProgramData\MpCmdRun.exe加载恶意DLL执行stageless beacon shellcode上线CS。

至此，钓鱼木马的所有流程已全部分析完成。

木马IOC

远程HTTP文件服务器：http://112.74.109.76:5559/
C2 腾讯云API地址：https://service-baw5g4iz-1309608249.bj.apigw.tencentcs.com
sha256：
1：abf4a58e2410c9f2ff44b46d6b0fd4c0ef1c87cd2f92b54110b48c6bac58bdd7
2：4b911039f73805932ee8b71e0995e7abd67fb19032a04a25f4bb40f83cbc44a8
3：40df318615a24046c0a20e96b728db4dfc000b126e8cf2f186fcf61cadd5dcf0
钓鱼木马.exe: 4de7883c5527dab617a70af7d76bc34d1f73ebfe50bf29c40f883ec8db3f2b32

我们的知识星球"安全的矛与盾"是一个既讲攻击也讲防御、开放的、前沿的安全技术分享社区。在这里你不仅可以学习到最新的攻击方法与逃避检测的技术，也可以学到最全面的安全防御体系，了解入侵检测、攻击防护系统的原理与实践。站在攻与防不同的视角看问题，提高自己对安全的理解和深度，做到: 知攻、知守、知进退；有矛、有盾、有安全。

更多的干货内容，更深入的技术交流，尽在知识星球“安全的矛与盾”，欢迎大家扫码加入！有问题请咨询微信 Manliness_man