0x00 前言
如果说，作为“软件供应链攻击”的典型案例，XCodeGhost事件虽然影响面较大，但其本质上毕竟只是作为软件推广的小后门而存在，攻击性并不显著。本文将分析的XShellGhost后门案例则是继XCodeGhost之后下一个 “供应链安全”的经典案例，并且相较之下其攻击特征尤其突出，技术水准也直线上升，是真正令人细思极恐的高级幽灵。
0x01 事件背景
2017年7月，著名安全公司卡巴斯基通过在合作伙伴的网络环境中分析可疑的DNS请求发现了NetSarang（XShell所属公司）生产和分发的软件最新版本已被秘密修改，用于包含可以让攻击者远程激活的加密载荷。之后卡巴斯基通知厂商与其发布了联合安全声明，并以“Shadowpad”来命名此类软件后门（国内安全厂商则习惯将其命名XShellGhost）。
2017年8月，联合声明被更新，声称发现了在香港利用该软件后门的案例。
此外，卡巴斯基在他们的对外报告中提及因为攻击者非常小心地隐藏自己所以很难定性谁是幕后黑手，只是此事件相关的某些技术曾被应用于另一种已知的恶意软件如PlugX和Winnti。
0x02 样本分析
本事件受影响的产品包括主版本号为5的Xmanager、XShell、XFtp和Xlpd，被感染的恶意模块是这些产品共同使用的一个基础网络通讯库“nssock2.dll”。
（一）、后门位置
以XShell 5.0.1322版本为例，后门代码位于安装目录下的“nssock2.dll” 模块，包含NetSarang公司的合法签名（当前为被吊销状态）。
该模块在软件启动后会自动被加载运行，植入的后门并不影响其原本的正常功能。恶意代码如下所示，可以看到从全局数据区解密一段shellcode代码运行。
该段恶意代码执行在本模块初始化CRT（C运行时库）期间，由函数“_CRT_INIT”进行调用。
“_CRT_INIT”运行在DllMain主函数之前，即恶意代码在此模块正常工作前就已经执行完毕。
（二）、植入机制
（三）、shellcode1（Loader模块）分析
接着分配一块包含可执行属性的内存用于解密下一阶段的shellcode（下文简称shellcode2），解密前先按照一种特殊的自定义算法初始化其内存数值。
shellcode2的解密算法如下。
准备完毕调用一个寄存器call进入shellcode2代码。
（四）、shellcode2（后门上线模块）分析
本阶段shellcode的主要任务是信息采集，用于筛选目标用户进而决定是否执行下一阶段的shellcode（下文简称shellcode3），首先创建一个单独的线程来进行接下来的任务。
判断是否执行shellcode3是根据该后门存储在用户系统注册表中的感染标志来决定的，注册表的路径根据用户的硬盘序列号异或“0xD592FC92”生成，感染标志的数据则在该路径（HKLM\SOFTWARE\%d或HKCU\SOFTWARE\%d）“Data”字段存储，此字段存储的数据不仅包含感染标志信息，还包含shellcode3的2个解密key等相关信息。
事实上，shellcode3的解密算法和“nssock2.dll”解密第一阶段shellcode的算法是相同的，并且解密key（“0xC9BED351”和“-0x57A25E37”即0xA85DA1C9）也一致，只不过在第一次感染（感染标志不为1）时这2个解密key（“data.key1”和“data.key2”）是通过云端下发更新到“Data”字段。
第一次感染时，会判断当前时间与上次感染时间（“last_run_time”）的时间差，若满足一定的时间间隔则发送dns来请求云端数据，进而决定是否可以执行shellcode3。
具体的“DGA”算法生成域名的过程如下，可以看出是通过把当前系统时间值按照特定的算法转换成了特定字符串来充当域名的前缀主域部分。
发送的数据按照特定格式进行组织后再加密和编码转换成上线域名的子域字符串部分，如下是数据的加密算法，加密前的数据前部有个“DOOR”的标志字符串（小端存储，猜测此处表征后门之意），紧接着还包含了被攻击系统的主机名和用户名等信息可供控制端进行筛选。
编码子域字符串部分的算法如下，每个字节将被简单编码成对应的2个字符，所以根据该算法也比较容易从一些DNS查询记录中恢复出受害用户的相关信息。
同时，由于此数据编码后的子域长度较大，其实反而容易显得可疑而暴露自身，根据卡巴斯基报告中关于“在调查期间发现了可疑的DNS请求”的描述可能指代的就是这里。若是没有此缺陷，XShellGhost后门可能存活的时间还会更长一些，并且经此一役，各大安全厂商也开始加强对此类“DNS隧道攻击”的监控。
若能成功接收到攻击方从远端下发的执行命令，就可以从中获得下一阶段shellcode3的解密key，进而完成下面的控制过程。
（五）、shellcode3（Loader模块）分析
通过上一节的分析，虽然此时已无法获得攻击者下发的控制数据，但基于对解密shellcode3的算法/密钥与解密第一阶段shellcode相一致的猜测，最终可以解出shellcode3的代码。同时，由于shellcode3的功能代码是复用了第一阶段shellcode那个加载器，只是要加载运行的下一阶段代码不同而已，所以本节也不再赘述直接进入下一节shellcode4的分析。
（六）、shellcode4（远控模块）分析
本阶段shellcode就是XShellGhost最核心的远控模块，此模块最大的特点就是采用插件式（“Plugin”）管理，整套远控程序由一个母体插件（“Root”）管理多个子功能插件的方式来运行。
每个插件的入口和DllMain有点类似，均通过fdwReason来定义具体要执行的操作。通用的操作码如1表示插件初始化，102表示获取插件的编号id，103表示获取插件的名称，104表示获取插件提供的API功能列表。如下即母体插件“Root”的入口函数，插件id为100。
通过上述操作码可获得本模块共计6个插件的编号和名称，具体说明如下。
“Root”母体插件在初始化阶段会加载其他5个子插件并调用“Install”插件来进行安装操作。
加载插件的过程其实还是复用上述shellcode1的“Loader”代码，可见此后门是基于此方式来实现模块化调用。
另外所有插件模块中还存在一个通用的字符串解密函数，专门用于在需要使用字符串的时候进行临时解密，通过此方式来隐藏自身的静态特征以阻碍安全人员分析和躲避安全软件的查杀。
当然，通过此解密算法我们也很容易就可以写出辅助脚本可以方便的解出插件中包含的加密字符串用于分析，如下是一个IDA Python的示例解密脚本仅供参考。
（七）、子功能插件分析
本节简单按照插件编号的顺序分别介绍一下5个子插件的功能。
“Plugins”插件
本插件除了向其他插件提供注册表查询、写入和删除的操作接口之外，最重要的功能就是实现了一种拓展外部插件的机制。具体是监控注册表“HKLM\SOFTWARE\Microsoft\%rand%”（或HKCU路径下）的变化，若捕捉到变化就去加载存储在该路径下的插件数据。
捕捉到变化后循环枚举该路径下各项的数据，检查该数据是否为有效插件并调用“Root”插件提供的相关接口加载。
“Config”插件
这些运行配置在每次后门运行时都会被加载并重新加密写入路径为“%ALLUSERSPROFILE%\%rand%\%rand%\%rand%\%rand%”的文件中存储，此路径根据用户的硬盘信息生成，每台机器看上去随机但对用户来说是相对固定的。
“Install”插件
本插件主要就是进行后门的安装，将母体插件“Root”注入到上述“Config”插件指定的进程“svchost.exe”中运行。注入过程先尝试以“Winlogon.exe”的系统进程权限来创建傀儡进程“svchost.exe”，若失败再以普通权限创建。
傀儡进程创建（挂起状态）成功后调用“Root”插件提供的一个API接口来完成注入操作。具体是先注入通用的“Loader”加载器代码，然后注入“Root”母体插件的数据，最后通过劫持傀儡进程入口点或创建远程线程的方式来执行“Loader”代码加载运行“Root”母体后门。
注入后成功加载“Root”插件后门：
除了安装后门的功能外，本插件还会检查运行环境是否正在被调试或被监控，调试检测主要是调用“IsDebuggerPresent”判断或遍历活动窗口判断是否包含“WinDbgFrameClass”等调试工具的窗口类。
监控检测主要检测2款著名的工具，一款是系统资源监控工具“ProcMon”，判断方式是每隔1秒尝试打开如下几个诸如“\\.\ProcmonDebugLogger”的全局对象，若存在则立即退出进程。
另外一款则是网络流量监控工具“Wireshark”，判断方式是每隔5秒尝试检查 “Wireshark-is-running-{9CA78EEA-EA4D-4490-9240-FC01FCEF464B}”互斥体对象是否存在，若存在则立即退出进程。
“Online”插件
最终调用对应通讯模块来发送上线请求，若成功接收到响应则执行相应的指令，比如收集目标用户的系统运行信息。
“DNS”插件
本插件核心的功能就是提供网络通讯的接口来收发C&C指令，因为是基于DNS协议所以“Online”插件会调用本插件接口来建立专用的DNS隧道进行通信，选用的DNS服务器即网关默认DNS和“Config”插件指定的4个“8.8.8.8”等公用IP。
发送的数据就类似上述shellcode2阶段被编码成DNS查询的全域名（FQDN）的子域部分，最终控制端靠解析此部分编码来接收传输数据。不过这里使用的主域部分不再是使用“DGA”生成的域名，而是“Config”插件指定的C2域名“www.notped.com”，发送时构造类型为“TXT”的DNS查询数据包依次发送给公共DNS服务器IP列表来完成数据传输。
发送完DNS查询数据后正常可以马上接收到响应包，但是需要检查其中是否包含正确的“TXT”回复包，后门需要据此获得控制端设置的控制指令。
只有当响应的“TXT” 回复包满足特定的编码格式才能解析出指令数据成功进行控制操作，而这通常需要控制者对其C&C域名设置自定义的NS解析服务器，才能方便的接收来自公共DNS的查询数据包实时返回自定义控制数据包。
当前由于C&C域名早已失效，所以直接返回了服务端失败的标志，无法进入指令解析的流程。
0x03 溯源分析
本节仅简要整理并罗列出一些网上公开的报告信息。首先看一下当时与该后门直接相关的一些C&C域名：
0x04 DNS隧道防御检测
本节仅简单介绍一下防御检测恶意利用DNS隧道的思路。
针对这些可疑的特征进行归纳，首先可以把主机名（子域部分）超过52个字符的DNS查询请求作为识别DNS隧道的特征，因为正常的域名满足“Zipf”定律，而走DNS隧道的域名遵循的是随机分布。然后可以进行流量层面的监测，如单位时间内DNS报文的速率，或者连续多个TXT类型的DNS报文等都可以作为识别特征进行监控。最后就是结合发送DNS报文的进程名或进程链进行参照分析，提高甄别筛选的效率。
0x05 总结
XShellGhost事件是一起针对IT基础设施平台（软件）的经典供应链攻击案例，其本质是攻击者在入侵知名公司NetSarang后污染其软件产品源代码植入后门，并利用该产品分发传播来实施定向攻击。随着该事件的发生和披露，预示着此类攻击事件将在未来频繁演绎，所有的单位或个人都可能成为被渗透和攻击的对象，防不胜防。关于软件供应链安全的话题和研究，也将激起未来安全形势新的变化和浪潮。
0x06 参考链接
1.ShadowPad in corporate networks，https://securelist.com/shadowpad-in-corporate-networks/81432/
2.ShadowPad: popular server management software hit in supply chain attack，https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2017/08/07172148/ShadowPad_technical_description_PDF.pdf
3.Xshell高级后门完整分析报告，https://security.tencent.com/index.php/blog/msg/120
4.Xshell被植入后门代码事件分析报告，https://www.anquanke.com/post/id/86655
5.Xshellghost技术分析——入侵感染供应链软件的大规模定向攻击，https://www.anquanke.com/post/id/86657
6.XShellGhost事件技术回顾报告，https://cert.360.cn/static/files/XShellGhost事件技术回顾报告.pdf
7.C/C Runtime Library Code Tampering in Supply Chain，https://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html
8.调试实战——dll加载失败之全局变量初始化篇，https://www.shangmayuan.com/a/b15e4d7d24f9466584cd3f89.html
9.XshellGhost再现？使用DNS隧道传输的PlugX远控变种分析，https://bbs.zkaq.cn/t/1073.html
10.rdp连接_揭开谍中谍的好戏，关键词：HW、RDP漏扫、红蓝对抗，https://blog.csdn.net/weixin_36443823/article/details/112720716
11.DNS报文格式，https://www.cnblogs.com/qrxqrx/articles/8034781.html
12.微步通告: XShell官方软件被植入后门溯源分析，https://m.threatbook.cn/detail/67
13.Xshell后门事件中用到的DNS Tunneling技术分析，https://slab.qq.com/news/tech/1638.html
14.XShell后门DNS Tunnel编码分析，https://www.anquanke.com/post/id/86630
15.Xshell dns tunnel攻击，https://www.cnblogs.com/bonelee/p/7850493.html
16.隧道技术之DNS和ICMP与其检测防御，https://www.lper.cn/post/sui-dao-ji-zhu-zhi-dns-he-icmp-yu-qi-jian-ce-fang-yu/#xshellghost
17.一次误报引发的DNS检测方案的思考：DNS隧道检测平民解决方案，https://www.163.com/dy/article/D09THVKG05119F6V.html
