近日，企业电话管理系统供应商3CX遭到供应链攻击的事情，在安全圈中吵得沸沸扬扬。由其提供的VOIP应用程序3CXDesktopApp，遭到了攻击者的恶意篡改，其中包括了Windows和MacOS两个平台上所使用的客户端程序。

1、MSI_Installer

该恶意样本的外壳是一个带有有效数字签名的msi安装程序。

安装后，整体目录结构如下图所示(%Programs% -> %Programs%/app)，图中黄框圈中的文件为本文重点关注的文件。

2、Mal_3CX_Launcher

在安装完成后，其会通过"%Programs%"下的"3CXDesktopApp.exe"来启动"%Programs%/app"下的"3CXDesktopApp.exe"。

3、Mal_3CX

"%Programs%/app"下的"3CXDesktopApp.exe"同样是一个带有数字签名的程序，但在其导入表中，我们发现其引入了一个没有数字签名和任何版权信息的DLL文件(ffmpeg.dll)。

4、ffmpeg.dll

在"ffmpeg.dll"中其利用"CreateFileW"、"GetFileSize"、"ReadFile"将同级目录(%Programs%/app)下的"d3dcompiler_47.dll"读取到内存中，可以看到"d3dcompiler_47.dll"是一个带有数字签名的文件。

随后其判断指定内存地址是否是以"4D5A"开头，以判断是否成功将"d3dcompiler_47.dll"读取到内存中；再通过循环遍历的方式在内存中搜索加密块的开始标识"FEEDFACE"。

若成功找到标识头，则循环读取硬编码密钥"3jB(2bsG#@c7"到内存中，根据流程可以确定这是一个RC4密钥。

利用刚刚获取到的RC4密钥，对先前通过标识"FEEDFACE"定位到的加密块进行解密，得到一段shellcode。

快速浏览一下shellocde，可以看到和文件操作相关的函数，以及"GetProcAddr"和"LoadLibray"这个获取API的经典组合。且在上图中我们可以看到，在执行shellcode的CALL后还有一个"VirtualProtect"，那么这个shellcode大概率还是一个过程体。

5、samcli.dll

不出所料，在[shellcode+0x65D]的位置找到了一个PE文件头，在shellcode执行结束后，我们也在内存中发现了解密后的DLL文件。

可以看到shellcode最后通过CALL调用了解密后DLL中的导出函数"DllGetClassObject"，并且其将"1200 2400 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 3CXDesktopApp/18.11.1197 Chrome/102.0.5005.167 Electron/19.1.9 Safari/537.36""以参数的形式传入"DllGetClassObject"中。

在DllGetClassObject中其调用了"CreateThread"来创建新的线程，并调用第二个"VirtualProtect"修改区段权限，以便后续执行。

跟进到新创建的线程中，可以看到上文中提及的参数"1200 2400 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 3CXDesktopApp/18.11.1197 Chrome/102.0.5005.167 Electron/19.1.9 Safari/537.36""以命令行参数的形式传给了新线程。

随后，其从同级目录下的"manifest"文件中读取随机值。

此段恶意代码并不会立即执行，而是利用"Sleep"函数进行休眠，若未到达指定时间到则会直接退出。

休眠结束后，其从"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography"下读取"MachineGuid"作为后续和C2服务器通信的标识。

得到ICO文件后，将其读入内存，并寻找标识"$"，这是加密数据的开始位置，找到位置后，调用解密函数对加密数据进行解密。

跟进后可以发现，其通过base64和AES-GCM对加密数据进行解密，解密后得到C2地址。

随后，其会将之前取得"MachineGuid"与"__tutma"进行拼接(__tutma = {MachineGuid})作为标识符，放入与C2服务器通信的请求包中。

由于，攻击者警惕性较高，已将C2服务器下线，无法获取后续的payload，因而本文也就搁笔于此。

由于无法拿到最后的payload，目前还无法确定攻击者的真实意图，但从攻击的整体流程和手法上来看，幕后黑手的身份必定非同凡响！此外，在2023年3月中旬左右，便有少量3CX用户发出了告警，但都被当作了误报进行处理，直到2023年3月29日，此次供应链攻击事件才被正式确认。要知道，3CX在全球190多个国家，拥有超过1200万用户，可见这是一起非常严重的供应链攻击事件，涉及到安全的各个层面。值得我们持续关注和深思。