恶意ELF二进制文件相似度比较及可视化 – 作者:FreeAChao-安全小百科

二进制文件相似度比较是检测恶意软件的重要途径，利用待检测软件与系统中已收集的恶意软件的相似度大小，来判定其是否为恶意软件。本文介绍两种可视化的方式，分别来说明恶意ELF文件的相似度关系。

一、引言

此前笔者曾发表两篇关于蜜罐的文章，在文章中提到蜜罐每天都会收到恶意样本，例如《Cowrie蜜罐的Docker部署过程及Elasticsearch+Kibana可视化》文章中部署的系统，通过其日志可以看到相应下载或上传恶意样本的过程。

图1. SSH蜜罐cowrie收到的恶意样本

在收到大量的样本之后，需要进行分析来识别样本的具体工作流程，但在数量少的情况下，还能利用IDA pro来进行手动分析，但是数量多了之后，就希望能够将分析的过程自动化。每天都有大量的恶意软件出现，而恶意软件编写者会倾向于复用之前的代码，例如经典的僵尸网络代码mirai、bashlite等，通过修改cnc地址，或者增加一些最新的漏洞利用代码，但整体上恶意代码的执行流程是大致相同的。

在恶意软件例如病毒、木马、蠕虫等检测过程中，大致分为两种方式：基于指纹的检测方式和基于行为的检测方式[1]。基于指纹的方式，是将某个恶意软件与已有的指纹库进行对比，如果有符合特征的，则认定该软件为恶意软件；这种方式倾向于识别已经在指纹库中已经存在的恶意软件。这种方式就是利用相似度的方式，来比较新的样本与已有样本。如果相似度高，则判定为恶意样本。本文就来探索利用相似度来分析恶意样本的研究过程。

为了能够利用更多的样本来查看查看整体的相似度结果（数量越多，出现具有相似度的样本对越多），笔者开发了一个自动化爬取恶意样本并展示相似度的Web应用，同时在从符号表的角度介绍细粒度的恶意软件相似度。自动化抓取恶意软件的应用代码已上传至github，有兴趣的读者可以按照文章的第四小节在自己的机器上部署。

本文的内容如下：

通过ssdeep来分析恶意软件相似度，并利用echarts进行可视化
利用neo4j来分析细粒度的恶意软件相似度
介绍文中使用的恶意软件自动化获取系统

本文大部分是结论性的内容，介绍笔者在初步展开二进制相似度研究中的实践与总结，阐述在研究过程中使用的思路。在研究过程中，笔者对Linux下的样本更感兴趣，所以本次主要分析ELF二进制文件，在恶意样本下载过程中，会直接过滤掉一些非ELF的文件。

二、ssdeep分析相似度

2.1 ELF样本展示

本文中所关注的样本，大多数为僵尸网络样本，而且塔门普遍会生成多种系统架构的样本，以便适用于不同架构的设备，图2中展示了一个名为yakuza的样本。

图2. yakazu样本

随机取一个文件的sha256在virustotal进行分析，可以看到其在多个引擎中被标记为gafgyt的变种，又名bashlite[5]，在github上可以找到相应的源码。

图3. 某yakuza样本的分析结果

本文的研究就是基于这些恶意样本展开。

2.2 ssdeep的力导向图关系表示

传统的方法主要使用md5，sha256等方式来计算指纹，这种指纹对数据修改较为敏感，即使修改了文件的一个字节，也会引起整个指纹的大面积变化。在文章ModSecurity技巧：使用ssdeep检测Webshell[2]中，采用的ssdeep的数值来进行比较，这种方法对文件局部的修改不敏感，利用分段hash来计算文件的指纹；文章Threat Attribution using ssdeep[3]中以修改C源代码为例，说明了ssdeep进行二进制相似度比较的过程。按照这个思路，本文同样利用ssdeep来说明恶意软件相似度比较的过程。ssdeep的比较过程很简单，编程过程中只需要安装ssdeep即可，本文使用python语言进行编程。

使用过程中，ssdeep在对比两个恶意软件的相似度时，会生成一个相似度数值；为了更直观的感受相似度的关系，采用echarts的力导向图来绘制关系。初步研究阶段，只要两个恶意软件的相似度不为0，便在两者之间进行连线。

图4. 相似关系力导向图

在捕获一定数量的恶意ELF之后，对其进行两两ssdeep的计算，将其中按相似度大小排序前200个关系进行展示，如图4所示。图4的具体含义是，每个点代表一个ELF文件，不同颜色代表不同的架构，在图上方标注着相应的颜色关系。图中显示291个样本，并非仅仅下载了291个样本，而是显示了相似度大小排序后前200个的关系对，其中包含了291个独立样本。

在图4中，除了红色圆圈标记的地方，大部分的相似关系都发生在同颜色的恶意软件中；但红色圆圈中的ELF，从颜色中可以看出分别是PowerPC和Motorola m68k，实际上这两款架构也是非常相似的。所以，从图中可以得出结论：ssdeep对于相同架构ELF是能够检测出相似度的；但前文中也说到，很多恶意ELF文件编写者会同时编译多种架构的文件，但即使是同样的代码，不同架构的ELF是没有相似度可言的。

图5. 工作任务列表

在经过一下午的持续工作，捕获样本更多。

图6. 下载多个文件后的关系情况

从图6中可以看出没有连线的点越来越少了，而且此时图片中的相似关系更为复杂（例如红色方框圈出的部分）。在悬停鼠标在节点上之后，可以看到此时有很多同名的ELF被连接在一起。这并非是说两者是同一个文件，因为在自动化下载软件过程中，是按照ELF文件的sha256作为文件名字进行保存，因此不存在说两者是一个文件。为了说明这个问题，将上述样本的样本名字去除架构名字之后，绘制图云如图7所示。

图7. 恶意ELF名字

图8. 数据库中的同名文件（第一栏为sha256值）

图7中大的字体说明这个文件名字出现次数更多，图8中是某个ELF的数据库记录，也从侧面证明了并非同一文件。

2.3 小结

利用ssdeep作为指纹计算方式，能够容忍ELF中小部分的修改，使ELF文件能够得到相似度的比较；但从力导向图中可以看出，节点在连接在一起时，均为同架构的ELF，不同架构的ELF无法连接在一起（powerpc和Motorola m68k是例外）。

三、neo4j分析细粒度相似度

前文中，利用ssdeep对ELF的相似度进行了分析，但采用ssdeep的方法，有两个问题：一方面粒度比较粗，只能得出两个ELF是相似的结论，但是不知道他们在什么内容上是相似的；另外一个方面，就是前文提到的，不同架构的ELF没有相似度可言。但日常分析的过程中，不仅仅需要多少相似度，同样也需要为什么相似，什么地方相似。

文章revealing-malware-relationships-with-graphdb[4]通过提取PE文件的文件信息，例如软件编译时间，导入的链接库，使用的函数等内容，然后利用图数据库来展示他们的关系，是可以借鉴的思路。但原文中比较的对象是PE文件，对于本文中使用的ELF文件来说，可以使用符号表中的信息作为图数据库的节点。但一般恶意软件编写者都会去除符号表，那么函数表等信息都很难还原。为了降低难度，本文首先考虑符号表没有被去除(not stripped)的ELF，利用图数据库来展示其细粒度的关系。

相比与传统的关系数据库，图数据库将数据之间的关系作为关注重点，这样的好处是在深度关联查询过程中，速度更快，在neo4j发布的电子书中[6]，将图数据库的查询速度与传统关系数据库进行了对比，可以看到非常明显的性能提升。本小节将利用neo4j这款图数据库来展示节点关系，关于neo4j的部署及本文相关的代码，请看后面部署部分。

3.1 提取符号表

符号表是ELF保存了程序实现或使用的所有全局变量和函数等信息，在分析细粒度的过程中，利用命令readelf来提取ELF的符号表。

readelf -s some_malware

图9. 某个ELF文件（not stripped)的符号表信息

从图中可以看出，符号表中包含了文件，函数，变量等信息，本次实验中，使用函数和文件信息作为关系查询。

3.2 利用yakuza样本说明函数及文件关系

在使用图数据库的过程中，有很多内容可以定义，例如一个节点的标签，属性等，这里不深入说明图数据库的使用方法，仅介绍与本文实验中使用的方式，有兴趣的读者可以自己定制自己的关系库。

首先，明确定义一个节点可以是一个ELF文件、一个函数、一个文件，在编程过程中，创建一个需要传递标签（label），名字（name）两个参数。
然后，实验过程中采用两种关系，分别是，是否包含某个文件（file关系），是否包含某个函数(func关系）

为了能够展示关系图，将前文提到的yakuza的ELF文件，选取其中同一个IP下的多个架构的文件。注意，以下图中的节点对于函数节点和文件节点的数量均有限制，并非这些文件只有这些文件或函数。

图10. yakuza函数关系示意图（节点位置为手动调整，非数据库自动绘制）

图10中，紫色圆圈代表着某个函数，深绿色的直线代表着某个ELF文件包含了此函数，其他颜色节点分别代表着不同架构的ELF，具体图例在上方说明。从图10中的函数关系可以看出，除了getrlimit64这个函数，其他的几个函数均被这8个ELF共享，getrlimit64应该是x86-64架构下的某个函数。下面来看文件关系。

图11. yakuza文件关系示意图（节点位置为手动调整，非数据库自动绘制）

从图11的yakuza的文件关系中可以看到，8个文件共享了yakuza.c这个文件，毕竟他们是同样的源代码编译出来的，只是不同架构而已。

但在前一小节中，利用ssdeep的方式中，无法发现不同架构的文件存在相似度。从这个角度而言，利用图数据库的方式，可以找出ELF文件（未剥离符号表的情况下）他们共享的函数，以及文件，在后面的研究中，可以通过一定的算法来计算相似度，而且能够说明这些软件在什么地方是相似的。

3.3 小节

本小节利用图数据库来展示了跨平台的ELF（带有符号表）的细粒度关系，信息包括文件，函数。但这种方法存在一定的局限性，即必须能够提取相应的符号表信息。

四、恶意ELF自动化获取系统及图数据库的搭建

源码地址：elf_similarity

4.1 ELF自动获取

本应用使用python3+django 2.2.14开发，使用gentelella，一款开源bootstrap4 Dashboard模板作为前端来展示数据。利用docker来分别部署web应用和mysql数据库，采用docker部署的方式可以帮助读者快速搭建系统。该web应用将采用定时任务的方式，定期爬取两个url源，分别是

https://urlhaus.abuse.ch/downloads/csv_online/ 每5分钟更新一次在线的ELF
https://osint.digitalside.it/Threat-Intel/lists/latesturls.txt 每天更新一次

大致的工作流程如下：

获取两个URL源中的ELF url信息，并利用head方法请求文件是否还存在，添加至url表中
从url中下载可用的文件，并检测文件的一些信息，例如sha256数值，文件架构信息，添加至download表中
在download表中新下载的文件，利用sha256作为主键插入到binary表中
计算elf二进制两两之间的ssdeep相似度

正常情况下，该web应用定时任务每两个小时进行一些数据爬取及入库，但在web应用启动之后，会强制进行一次，来应对没有数据的情况。笔者在阿里云的1核2G服务器中测试，每次完成一次定时任务大致需要4分钟。

图12. dashboard界面

关于应用的部署过程，将在github上进行具体说明，保证后续的版本更替时部署方法一起变化，这里不在赘述。采用docker化的部署方式，构建过程很方便，只需要利用docker构建镜像，然后启动容器即可。笔者并非专业web开发人员，该web应用只是用来满足平时的需求，对这部分内容的学习周期不长，开发时间也较短，不免存在bug，代码质量以及执行性能未必满足读者需求，请不要将应用部署在生产环境下，读者可以根据自己的需求进行修改。

4.2 图数据库的关系展示

在第三小节中，利用neo4j这款图数据库进行了关系的展示，代码同样已经上传至github上，脚本位于elf_neo4j文件夹下。需要说明的是，图数据库的关系展示并非前面介绍的web应用的内容，其展示效果使用neo4j的原生web进行展示。同样搭建neo4j的方法也是利用docker。

执行命令：

docker run -it -d -p 7687:7687 -p 7474:7474 neo4j:3.4

然后进入h\t\t\p://your_machine_ip:7474进行密码的设置，之后对python脚本中的地址、密码进行设置，并将要进行关系提取的ELF文件放置到相应的路径（需要在代码中进行修改），运行脚本即可在neo4j的web界面中查看相应的ELF与函数和文件的关系。

五、总结

前文介绍了笔者在ELF二进制文件相似度方面的初步研究过程：

1）为了获取大量的样本，开发了一款基于django+bootstrap4的web应用，通过定时任务的方式来抓取两个源的URL信息。

2）在相似度方面，利用ssdeep作为粗粒度的关系，并于开发的web应用中进行展示，从图中可以得出结论，不同架构的ELF文件无法进行相似度的比较。

3）研究了not stripped的ELF文件基于图数据库的关系展示，通过neo4j图数据库自带的界面来查看ELF文件之间共享文件、函数的情况，但没有深入研究这种情况下的相似度如何计算。

当前的研究内容还比较浅，还有很多值得深入研究的部分：前文中也提到在判断elf的函数关系时，需要文件的符号表存在，但大多数的恶意ELF文件的符号表都被剥离，如何通过其他的方式来关联这种ELF文件的细粒度相似度关系；图数据库在本文中只是作为可视化的方式，没有进行深层次的挖掘，等等。后续，将深入研究这些问题，也希望有兴趣的读者一起研究。