供应链污染，还是……？对Office助手Addin的进一步分析

ANY.LNK

自https://bbs.kafan.cn/thread-2293204-1-1.html和https://bbs.kafan.cn/thread-2293121-1-1.html后，对该系列样本的关注点大部分都集中到了后续的AiPPT payload上，认为这是https://ti.qianxin.com/blog/arti ... ly-chain-attack-cn/所述的供应链攻击投毒的延续
但在对已提供的样本的分析表明，其内可能还包含其他的未在先前报告中说明的隐情

4个位于\Users\<UserName>\AppData\Roaming\OfficeAddinZhix目录下的DLL为Office加载项，具有有效的Beijing Yundong Zhixiao Network Technology Co. , Ltd.签名，分别适配微软Office和WPS Office的32位和64位版本。







四个DLL共享高度同源的代码，其中适配微软Office的DLL功能更多，体积更大，连接的域名和网络活动更多。（多出来的网络连接部分与诱导付费购买Office有关，话说这家厂商是微软授权的Office经销商吗？还是取得了使用微软商标的授权？）









后续分析主要围绕四个DLL共享的代码部分展开，也是其核心可疑（恶意？）逻辑所在处

以NativeWPSAddin64.dll为例，每个DLL有6个导出函数，其中5个为标准的供regsvr32使用的函数（COM组件相关），可能标识了这些DLL的安装方式和来源
在通过regsvr32.exe注册时，DLL会检查环境（此函数稍后会重点分析），向远程服务器报送一份数据，并将自身的配置写入Office的加载项注册表



剩下的那个函数是StartInstall，在奇安信的报告中提到过同名称的类似导出函数，在DLL被rundll32.exe调用时使用


函数sub_180005da0（此处被我命名为了OpenAddinAndRun）又为整个DLL中的关键逻辑，被StartInstall和sub_18001e1b0（WPS Office进程内的StartInstall逻辑）

此函数会首先查询自身注册表，给usenum（使用数？）上加一，随后初始化一大块结构





依据标志位分别执行不同的操作。如果标志位置零，表明历程不在rundll32.exe上下文执行，仅执行信息搜集；如果被rundll32.exe加载执行StartInstall函数，则创建一个新线程用于后续的安装动作。



搜集信息检查环境，其中搜集的信息包括：

用户名和所有网络适配器信息：



获取到的信息会处理后存储到注册表user2中



设备GUID（唯一标识符相关）



获取到的信息存储到注册表user4中



可能的更新渠道相关信息



检查是否在Wow进程中执行



检查是否在虚拟机中运行



获取操作系统版本



检查办公应用PowerPoint当前版本，时间，安装配置



当前进程名称



OfficeAid任务项，版本，PowerPoint加载项模块加载行为，以及NET Framework版本（考虑到这四个DLL本身是C++类语言编写，以及后续的payload是NET应用程序“AiPPT”，这可能是在为后续下载安装铺路？）



检查国产安装软件包括360，金山，腾讯



自身CLSID {2B92539D-351A-44C2-858A-BF50963536A8}



安装相关逻辑：（sub_180006340，RunInstall）



清理旧文件：




（同上）检查运行环境


设置openaddin注册表，构造POST请求发给hxxp://zhushou.officeaid02[.]com/api/v3/open，获取JSON格式的配置，解析内容，包括type以及id等（完整链接由域名和API地址拼接而成，下同）





操作类型1：睡眠等待后下载注册DLL：（这部分看起来像是自我更新一类的？）









操作类型2：DLL卸载：




操作类型3：睡眠，而后向临时目录下载写入文件，最后调用ShellExecuteExW执行







操作类型4：另一种配置的睡眠Shell执行：



操作类型5：下载DLL，并调用rundll32.exe执行StartInstall函数，额外向/api/v3/addinlog报送日志









在开始安装时和操作完成时都会向hxxp://zhushou.officeaid02[.]com/api/v3/report报告


此外，在未找到具体使用位置的函数中，还发现了对竞品插件（iSilde）管理员权限等的检测代码







综上所述，介于这些DLL将自己加载进超出其Office COM加载项所定义的进程范围（而且rundll32.exe几乎只负责（推广）安装），检测虚拟机、杀毒软件以及竞品软件，云控下发配置调整可能的多种静默安装等行为，我认为此些DLL已经超出了合理运作限度，再加上其使用HTTP明文传输搜集到的信息，下载远程程序并执行，增加了其被中间人攻击的风险。在此以中等置信度认为其与灰色产业相关，并可能受到了黑产的影响。

---

后记：

虽然大致流程已经明晰，但尚有一些问题未得到解答。
其一为StartInstall函数的参数问题，在操作类型5的分析中，其调用的命令行如下：

1. rundll32.exe "%s",StartInstall %s 2 "%s" ""

复制代码

其中第一个%s是GetModuleFileNameA从自身句柄（全局变量继承自DllMain）获取的文件名称，即DLL自身（或至少与之同名）；第二个%s是Temp目录下的\OfficeAid.Installer.dll，第三个%s继承自函数参数1的0x21偏移量。
而DLL本身的StartInstall只有3个参数，arg1 arg2未直接找到代码引用（冗长的汇编代码让AI看了之后都开始胡言乱语）

arg3经过处理后传给LoadLibraryW，同为arg3相关的参数也一并作为参数2传递给了GetProcAddress得到的StartInstall函数中，该函数的参数3是个找不到赋值的全局变量（可能是未知字符串）



（不过似乎这些并不影响安装历程的进行）
（如果删掉第二个%s的同时第一个%s换成新的DLL就好了=/，这样就能和奇安信的报告或GetProcAddress得到的调用方式一致了）

目前运行测试可以跑到环境检查后的网络连接发包报送信息，但没有触发进一步的下载行为或其他外联





后续的AiPPT为.NET应用程序，自解压包解压缩到临时目录，AiPPTSilentInstaller将文件从payload目录复制到指定目录，目录内文件经过混淆，其中AiPPTAddin.Installer.exe解混淆后功能为注册COM加载项，其余暂时未分析。