恶意软件开发档案解密之根据PDB路径和其他调试细节来推测相关的恶意活动(下)

luochicun 恶意软件 2019年9月18日发布
Favorite收藏

导语:在上一篇文章中,我们介绍了PDB路径是如何生成的以及其中包含的信息。今天,我们讲接着讨论通过PDB路径展示出的异常和其他恶意行为。

timg.jpg

上一篇文章中,我们介绍了PDB路径是如何生成的以及其中包含的信息。今天,我们讲接着讨论通过PDB路径展示出的异常和其他恶意行为。

PDB路径展示:异常和其他恶意行为

互联网是一个奇怪的地方,在足够大的范围内,你最终会看到你从未想过你会看到的内容。比如那些偏离常规的事情,那些逃避标准的事情,那些完全无法解释的事情等。我们期望PDB路径以某种方式显示,但是我们遇到过几个没有这样做的示例,而且我们并不总是确定发生的原因。下面的许多示例可能是错误、损坏、混淆或各种形式的故意操作的结果。我们在这里演示它们是为了说明,如果你正在尝试PDB路径解析或检测,你需要了解各种各样的路径,并为各种各样的恶意行为做好准备。以下示例中的每一个都来自确认的恶意软件样本:

19.jpg

恶意操作的进程差异

即使入侵操作被成功执行,其过程也存在许多差异。由于APT36有数百条泄漏的PDB路径,所以在某些活动中执行良好OPSEC的团队可能在会其他活动中执行不好的OPSEC。当PDB路径出现时,PDB路径中出现的关键字、术语和其他字符串项的类型都具有专业性和复杂性。一方面我们看到“njRAT-FUD 0.3”和“1337 h4ckbot”,另一方面我们看到“minidionis”和“msrstd”。

研究人员对基于字符串的检测的常见批评是这样的:

恶意攻击者不像你想的那么脆弱不堪,他们会混淆和逃避签名。

在上面关于PDB路径关键字、术语和异常的表中,我们认为我们已经展示了真实的APT/FIN组、国家支持的攻击者以及最好的攻击者有时确实会出错,这给了我们一个发现的机会。

下面,让我们从一些很高级的威胁恶意软件中挑选一些具体的示例来进行说明。

Equation Group

方程式组织(Equation Group)是一个由卡巴斯基实验室发现的尖端网络犯罪组织,后者将其称为世界上最尖端的网络攻击组织之一,同震网(Stuxnet)和火焰(Flame)病毒的制造者紧密合作且在幕后操作。该组织被怀疑与美国国家安全局(NSA)有联系。此外,在方程式组织使用的恶意软件中,发现了诸如“STRAITACID”和“STRAITSHOOTER”之类的美国国家安全局代号。

2016年,“The Shadow Brokers”(影子经纪人)声称他们入侵了“Equation Group”(方程式组织),并将他们从该黑客组织的计算机系统中所获取到的大部分黑客工具全部泄漏在了互联网上。除此之外,该黑客团伙还表示,他们手中目前仍掌握着大量的机密数据,他们计划在网上举行一次拍卖会,并将这些机密信息出售给竞价最高的竞标者。

一些方程式组示例显示了完整的PDB路径,这表明某些恶意软件是在用于开发的工作站或虚拟机的调试模式下编译的。

c:\users\rmgree5\co\standalonegrok_2.1.1.1\gk_driver\gk_sa_driver\objfre_wnet_amd64\amd64\SaGk.pdb

其他方程组样本具有部分限定的PDB路径,它们表示一些不太明显的内容。这些独立的PDB名称可能反映了更适合的多开发人员环境,在这种环境中,为单个开发人员系统指定完全限定的PDB路径是没有意义的。相反,指示链接器只在构建的可执行文件中编写PDB文件名。尽管如此,这些PDB路径对于他们的恶意软件样本来说是独一无二的:

· tdip.pdb

· volrec.pdb

· msrstd.pdb

Regin

Regin是一款先进的隐形恶意软件,可躲避常规反病毒软件检测。该恶意软件从2008年起,就被黑客用于监视政府、公司和个人。2014年11月24日,赛门铁克在周日发布的一份最新报告称,近日发现了一款名为“Regin”的先进隐形恶意软件,并称该恶意软件从2008年起,就被黑客用于监视政府、公司和个人。

Regin间谍工具使用了多项隐形技术,可躲避常规反病毒软件检测。从Regin的复杂设计来看,开发这一恶意软件需要投入大量时间和资源,间接表明该恶意软件是一个“国家”所开发的产品。但赛门铁克并未指明哪个国家开发了这一恶意软件。赛门铁克同时表示,Regin的设计,使它非常适用于对目标进行长期监视活动。

在目前的恶意软件开发领域,把恶意软件看作是“后门”的想法越来越过时。目前,很多人愿意将恶意软件称为“植入物”。在Regin平台的这个组件中,我们看到了一个命名意识非常超前的开发人员:

C:\dev\k1svn\dsd\Implants\WarriorPride\production2.0\package\E_Wzowski\Release\E_Qwerty.pdb

APT29

APT29之所以被大家熟知,原因就在于人们怀疑它在俄罗斯政府操控下侵入民主党网络系统,,干预了美国的正常选举。它在全球范围内肆无忌惮的入侵行为经常包含一些创造性的、精心设计的、隐秘的恶意软件。APT29是比较擅长隐蔽自己的恶意软件,但是在成千上万的恶意软件中,这些通常训练有素的操作人员还是泄漏了一些PDB路径,比如:

c:\Users\developer\Desktop\unmodified_netimplant\minidionis\minidionis\obj\Debug\minidionis.pdb
C:\Projects\nemesis-gemina\nemesis\bin\carriers\ezlzma_x86_exe.pdb

即使最重要的设备中没有使用显眼的关键字,在PDB路径中仍然可能存在一些字符串术语、异常和独特的值,每一个都代表了一个检测的机会。

ConventionEngine规则

我们从所有可执行文件中提取并索引所有PDB路径,这样就可以轻松地搜索和查看检测的数据了。但并不是每个人都能轻松做到这一点,所以我们快速收集了近100条Yara关于PDB路径关键词,术语和异常的规则。我们相信,研究人员和分析人员可以使用这些规则来检测到可能出现的恶意攻击。我们将这个规则集合命名为“ConventionEngine”,但在幕后,这些规则只是乱七八糟的脚本和签名。

你可以把这些看作是“信号”或“发现规则”,它们旨在构建不同大小和保真度的干草堆,供分析人员搜索。具有低信噪比(SNR)的那些规则可以被发送到用于记录或文件对象的上下文化的自动化系统,而具有更高SNR的规则可以被直接发送到分析员以供审查或调查。

注:信噪比,英文名称叫做SNR或S/N(SIGNAL-NOISE RATIO),又称为讯噪比。是指一个电子设备或者电子系统中信号与噪声的比例。这里面的信号指的是来自设备外部需要通过这台设备进行处理的电子信号,噪声是指经过该设备后产生的原信号中并不存在的无规则的额外信号(或信息),并且该种信号并不随原信号的变化而变化。

如果攻击者犯错,研究人员就可以抓住他们。我们很高兴地发布了ConventionEngine规则,所有人都可以使用该规则。这些规则涵盖了300多个命名恶意软件家族、数百个未命名恶意软件家族、39个不同的APT和FIN威胁组以及200多个UNC(未分类)活动组的样本。

我们希望你可以使用这些规则作为模板,或者作为进一步PDB路径检测想法的起点。有足够的空间添加关键字、术语和异常,需要注意的是,无论是用于检测、搜索还是仅仅用于上下文,你都需要对这些规则进行调优并添加额外的逻辑,以使生成的规则的大小适合你的检测目的、运营和技术。我们相信,这些规则可以帮助研究人员分析并发现遗漏的潜在攻击。

智能团队的PDB路径

APT31示例

在一次事件响应调查中,我们发现Github上的一个APT31账户被用于存放恶意软件文件和恶意软件通信。使用该帐户的入侵操作人员会毫不犹豫地将完整的代码包放入存储库,我们能够恢复与多个恶意软件生态系统相关的实际PDB文件。使用实际的PDB文件,我们能够看到原始恶意软件源代码的完整目录路径,这代表了关于恶意软件原始开发环境的相当大的智能收益。我们使用我们在PDB中找到的内容来搜索与这个恶意软件开发者相关的其他文件。

使用PDB查找恶意软件源代码

恶意PDB本身比人们想象的更容易找到,当然,有时候开发者会把所有的内容都放在Github上。但也存在其他一些情况:有时恶意软件源代码会无意中被反病毒或端点检测和响应(EDR)代理标记,而有时恶意软件源代码将保留在打开的目录中,甚至有时恶意软件源代码会被上传到大型恶意软件库。

你可以通过查找诸如Visual Studio解决方案文件之类的内容来找到恶意软件源代码,或者只使用Yara规则在归档中查找具有非零检测率的PDB文件或其他元数据,这些元数据会提高归档中某些组件的恶意检测率。

rule PDB_Header_V2
{
    meta:
        author="@stvemillertime"
        description = "This looks for PDB files based on headers.
    strings:
        //$string = "Microsoft C/C++ program database 2.00"
        $hex = {4D696372 6F736F66 7420432F 432B2B20 70726F67 72616D20 64617461 62617365 20322E30 300D0A}
    condition:
        $hex at 0
rule PDB_Header_V7
{
    meta:
        author="@stvemillertime"
        description = "This looks for PDB files based on headers.
    strings:
        //$string = "Microsoft C/C++ MSF 7.00"
        $hex = {4D696372 6F736F66 7420432F 432B2B20 4D534620 372E3030}
    condition:
        $hex at 0
}

攻击性团队的PDB路径

研究人员根据恶意软件样本中泄露的PDB路径,确认了真实攻击者的个人身份。其他分析人员通常使用PDB路径来分析相关的恶意软件家族,同时为恶意软件开发人员的归属、跟踪或追踪建立一个案例。当然,进攻操作人员应该意识到编译过程中遗留下来的组件,并避免在启用符号生成的情况下进行编译。一句话,就是要使恶意软件使用良好的OPSEC,如果有意引入这个组件,就有机会创建人工PDB路径。

使PDB路径看起来更“合法”

恶意软件和非恶意软件的一个显著区别是,恶意软件通常不是在“企业”或“商业”软件开发环境中开发的。在大型开发环境中,软件工程师通过开发工具来处理大型项目,并且通过自动化的“持续集成”(CI)或“持续交付”(CD)套件不断地更新和重建软件。这意味着,当PDB路径出现在合法的企业软件包中时,它们通常会在CI/CD构建服务器上有显示编译路径的工具标记。

以下是一些在CI/CD环境中构建的合法软件可执行程序的PDB路径示例:

D:\Jenkins\workspace\QA_Build_5_19_ServerEx_win32\_buildoutput\ServerEx\Win32\Release\_symbols\keysvc.pdb
D:\bamboo-agent-home\xml-data\build-dir\MC-MCSQ1-JOB1\src\MobilePrint\obj\x86\Release\MobilePrint.pdb
C:\TeamCity\BuildAgent\work\714c88d7aeacd752\Build\Release\cs.pdb

不可否认一些恶意软件开发人员正在使用CI/CD构建环境,我们知道,一些攻击者和恶意软件开发者确实采用了现代企业开发流程,但像以下这样的恶意PDB非常罕见:

c:\users\builder\bamboo~1\xml-data\build-~1\trm-pa~1\agent\window~1\rootkit\Output\i386\KScan.pdb

在Visual Studio中指定自定义PDB路径

在开发环境中,为PDB文件指定自定义路径并不罕见。攻击者可能希望指定一个伪PDB路径,并且可以使用编译器链接选项轻松地做到这一点。

正如我们以上所述的恶意软件开发者“smiller”一样,他们可能采用一种更隐秘的方法,并选择在新的恶意软件编译中包含一些更“合法”的PDB路径。

以位于路径中的smiller示例恶意软件项目为例:

D:\smiller\projects\offensive_loaders\shellcode\hello\hellol\

21.png

Visual Studio中显示的带有调试版本信息的hellol.cpp代码

默认情况下,在调试配置中编译的项目会将hellol.exe文件和hellol.pdb文件放在下面的路径中:

D:\smiller\projects\offensive_loaders\shellcode\hello\hellol\Debug\

22.png

hellol.exe和hellol.pdb,由调试配置默认编译到其常驻文件夹中

可以很轻松更改此项目的属性并手动指定PDB文件的生成路径,在Visual Studio任务栏中,选择“项目”>“属性”,然后在侧窗格中选择“链接器”>“调试”并填写“生成程序数据库文件”选项框。此选项接受Visual Studio宏,因此脚本和创建自定义具有足够的灵活性构建用于伪造或随机化PDB路径的配置。

23.png

hellol项目属性显示PDB路径的默认值

24.png

hellol项目属性现在显示了伪造的PDB路径的手动指定路径

当检查原始的ConsoleApplication1.exe时,我们可以看到链接器在可执行文件中包含了调试信息,并指定了指定的PDB路径,这当然是伪造的。或者,如果在命令行中构建,你可以指定/PDBALTPATH ,它可以创建不依赖于构建计算机的文件结构的PDB文件名。

25.png

通过PEview实用程序看到重建的hellol.exe,它向我们显示了可执行文件的IMAGE_DEBUG_TYPE_CODEVIEW目录中的伪PDB路径

攻击者可以故意在恶意软件中包含一个PDB路径,使可执行文件看起来像是在CI/CD服务器上编译的,这可以帮助恶意软件躲避检测。此外,操作符可以包含与已知恶意软件家族或威胁组织相关联的PDB路径或字符串,以迷惑分析人员。比如臭名昭著的APT33 persona xman_1365_x或者你可以加上一个“\Homework\CS1101\”,让这个活动看起来更学术化?无论出于什么原因,如果要进行PDB操作,通常可以使用常见的软件开发工具进行。

恶意行为并不是一定和命名名称有关

在PDB路径和恶意软件开发者命名约定的背景下,重要的是要承认“攻击”和“防御”的相互依赖(通常是循环的)关系。首先,一个防御者将一块恶意软件称为“木马”或一个恶意软件开发者将他们的代码项目命名为“木马”?一些恶意软件受到以前工作的启发。开发者将代码项目命名为“MIMIKATZ”,多年后,有数百个相关项目和脚本具有衍生名称。

虽然定义可能有所不同,但我们看到攻击和防御双方都使用相同的术语和灵感来描述恶意软件的功能或作用。我们怀疑这是从“病毒”开始的,并且随着公共话语推进恶意软件分类,一系列细粒度的描述性术语将继续增长。谁会怀疑我们如何谈论恶意软件最终会导致发现它的可能性?毕竟,任何其他名称的rootkit都会变得邪恶吗?

总结

PDB路径确实是文件的一个不可靠的属性,在可执行文件中仅仅存在这些路径并不是坏事,但是当这些路径出现在恶意软件片段中时,它们通常表示操作者的行为不是很谨慎。基于PDB路径检测恶意软件的想法有点像根据一个人的穿着来判断他的身份。

在实践中,我们成功地将PDB路径主要用作一个分析起点,帮助我们对恶意软件家族进行分析,并跟踪恶意软件开发人员。当我们开始全面研究PDB路径时,我们注意到许多恶意软件开发者对他们的文件夹和项目文件使用了许多相同的命名约定。他们用恶意软件本身的功能来命名他们的恶意软件项目,并且经常用独特的描述性语言来标记他们的项目。

我们发现,许多恶意软件开发者和操作人员泄露了描述恶意软件本身功能的PDB路径,并让我们有机会深入了解了开发环境。此外,在恶意软件开发文件和环境的描述符之外,当存在PDB文件时,我们可以识别出一些异常,这些异常会帮助我们识别更可能在特定情况下具有特殊功能的文件。攻击者有能力通过伪造PDB路径来提高他们的交易技巧,以达到隐身或躲避检测的目的。

有理由相信,当PDB路径存在时,我们一定可以从其中获取一些关键信息。通过对2200个已命名恶意软件家族(包括41个APT和10个FIN组以及其他数百万未分类可执行程序的所有样本)的调查显示,PDB路径在恶意软件中出现的概率大约为5%。

我们用于PDB路径关键字,术语和异常检测的ConventionEngine规则包非常有趣,并且发现了大量可能错过的恶意软件。但是恶意软件中有很多PDB路径没有这么明显的关键字,这让这个方法用起来很困难。

在下一篇文章中,我们将探讨如何把PDB路径的这些分析特性变得明显化,让该方法得以广泛应用,敬请关注。

本文翻译自:https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html如若转载,请注明原文地址: https://www.4hou.com/malware/20245.html
点赞 1
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论