[译文] 恶意软件行为综述 - A View on Current Malware Behaviors

 

A View on Current Malware Behaviors

Ulrich Bayer, Technical University Vienna; Imam Habibi, Davide Balzarotti, and Engin Kirda,Institute Eurecom; Christopher Kruegel, University of California, Santa Barbara

发布于LEET ‘09

通过对Anubis系统收集到的恶意程序样本的动态分析结果进行行为特征方面的总结和统计，比较全面。

原文地址：http://www.usenix.org/events/leet09/tech/full_papers/bayer/bayer_html/

下面是译文： 

 

恶意软件行为综述 

 

 摘要

      Anubis是一个提供可控环境来执行用户提交的二进制文件的动态恶意软件分析平台。该系统通过监视关键的Windows API和系统服务调用、跟踪网络数据流、记录网络通讯，实现对二进制文件的分析，并生成综合分析报告。由于它通过公开的网络接口和很多安全组织、反病毒公司获得恶意程序样本，用户群广泛，所以收集到的样品体现了互联网上广泛而多样的恶意程序。本文针对互联网上具有普遍性的恶意行为进行阐明。最后，我们将对Anubis平台近百万恶意文件样本的分析结果和研究趋势以及两年期间的恶意程序的行为特征进行评估，并考虑到了多态性恶意程序代码对统计结果的影响。

1 简介

      恶意软件是当前互联网面临的最紧迫最主要的安全威胁之一。反病毒公司每天需要处理数以万计的新恶意样本，鉴于静态分析的局限性，往往采用动态分析工具进行分析，从而得知它们的行为以及攻击方式。得知这些很重要，因为这样有利于制定有效的防护对策。

      本文研究具有普遍性的恶意软件行为，分析和经验都基于动态恶意程序分析平台——Anubis[1, 5]收集到的恶意代码样本。每得到一个样本，Anubis执行该样本并监视关键系统调用Window API调用，并记录网络行为，跟踪数据流向。这样得到的恶意程序的行为是仅通过监视网络数据流所不能获得的。

      Anubis通过公开的网络接口和很多安全组织、反病毒公司获得恶意程序样本。这些样本来源于蜜罐、网页爬虫、垃圾邮件圈套和安全分析员的被感染机器。因此，体现了网络上广泛而多样的恶意程序。该系统已经运行了约两年时间，此间分析了近百万不同的二进制代码（基于MD5值）。如果按时间考虑，分析每个恶意程序需要几分钟，那么这需要12个CPU有效工作超过一年的时间。

      收集恶意代码行为的统计数据时，我们考虑恶意代码家族的多态性。由于样本的识别是基于MD5值的，比起非多态的恶意代码家族，每个恶意代码集合包含更多多态的恶意代码程序。这样，一个多态性恶意代码家族就足以影响整个统计结果，为了弥补这一点，我们除了分析单独的样本的行为，也进行了恶意代码家族的行为分析。

      本文是在分析了近百万的恶意程序样本后的总结，主要贡献在于总结和统计了不同范围的众多程序的一般性行为。我们也考虑了程序多态性对统计结果的影响。最后，我们把基于单个恶意程序样本和基于恶意代码家族的分析结过进行了对比。

2 相关工作

      研究人员对恶意程序问题领域进行了广泛研究。一个研究分支致力于获得各种恶意软件感染网络的范围。比如确定僵尸网络的大小[17]，可执行间谍软件的数量[14]，通过提供下载运营的恶意站点的数量[16]。另一个分支致力于研究恶意软件的收集和研究工具。研究者们引入了多种形式的蜜罐[3, 18]，静态分析技术[7]，动态监控工具[8, 19]。最后，提出当恶意程序感染机器时基于特征码或基于行为的检测和移除它们的方法。

      此前的研究者们解释了恶意代码的很多方面，但是很少涉及它们感染主机前后的行为。而通过这些行为，我们能够把恶意程序和主机的操作系统、应用程序和网络联系起来。当然，有些流行恶意程序家族已经被广泛了解[13]，民间智慧也告诉我们恶意程序会执行自身并复制到Windows的系统文件夹中，网络行为也因为容易采集和评估而被详尽地分析[11]。然而，这些很难让我们知道大量多样的恶意程序家族所具有的普遍的与主机的交互信息。比如，恶意代码传播、持久存在和避免检测的一般机制。一方面，这些信息有助于更好地理解恶意程序作者的动机、目标和恶意程序演变的方式，另一方面，这些信息对开发更优的基于行为的检测技术有重要作用。

3 数据集

      这一节，我们将对Anubis收集的数据进行概述。如前面所提到的，二进制程序在一个操作系统仿真环境（一个Qemu的修改版本[6]）下被分析和行为监控，它产生的Windows的本地系统调用和API函数被记录下来。系统的一个重要特征是不对它执行的程序做任何修改（如通过劫持API调用或设置断点），从而使它难以被恶意程序检测。同时，系统使二进制程序在未经修改过的Windows环境下，以使仿真更为准确。每个样本执行后都会在所有进程结束时退出或设置的4分钟的超时时间到达时终止。一旦分析结束，监测到的行为会被集入报告并存入数据库。

      数据集覆盖了2007年2月7日到2008年12月31日期间提交给Anubis的所有文件的分析报告，这些二进制文件在2007年2月7日到2009年1月14日之间被动态分析系统顺次分析。数据集包括了901,294个不同的样本（基于MD5值）和1,167,542次提交。一个相同的样本被再次提交时，系统不再分析，会返回此前的分析报告。

      图1按月表示了Anubis收集到的样本总数、新样本数和实际分析的样本数，这里所说的新样本数是指提交文件的MD5值是数据库里没有的。如图所示，2008年平均每月分析50000个样本。起先，Anubis在线样本提交服务只能收集到少量样本，然而随着影响力的扩大，计算能力成为瓶颈，以至于2008年8至9月，不得不暂停自动批处理来分析积压的样本。

 

 

图1 Anubis提交文件统计表

      通过修复漏洞和增加新功能，Anubis对版本进行升级。考虑到始终有新的恶意程序样本的提交和处理分析的昂贵代价，此前的样本没有在新版本系统中再执行。这使得各版本的分析结果难整合。某些时候，这些不同没有什么影响，而另一些时候（特别是对利用反沙盘技术的样本的分析，见4.6），因为此前版本的报告里缺少信息，我们只得到一个很小的子集——330,088个分析过的PE文件。

3.1 提交的样本

      图2描述了不同样本来源的样本数目，大多数样本提交于同一个来源，相比之下，其它来源提交的样本量要少得多，但也有10到30个提交了数量可观的样本。

 

 

图2 样本的不同来源数目

      通过检测样本来源有助于说明互联网上该样本的流行程度。事实上，通过使用多种病毒扫描工具对收集到的恶意程序样本进行扫描也支持了这一点。比如，单一来源提交的样本有73%被2/5的病毒扫描工具归为恶意程序，由至少3个不同来源提交的样本有81%被反病毒软件定义为恶意程序，而由超过10个不同来源提交的样本则有91%被认定为是恶意的。

3.2 样本文件类型

PE文件（770,960）	DLL文件（75,505） 驱动文件（4,298） 可执行文件（691,057）
非PE文件(130,334)	ZIP文件（17,059） RAR文件（25,127） HTML （27,813） 其它（60,335）

表1 Anubis获得的样本文件类型

      公开在线恶意程序分析服务的一个问题是接收到的文件不仅仅是恶意程序。事实上，用户可能上传一些应用程序诸如微软的Word或是IE仅仅想看看系统的反应，甚至有的上传样本不是Windows PE可执行文件[12]（大约14%不是）。表1统计了Anubis获得的样本文件类型详细条目，大多数文件可以被分析。非PE文件主要包括不同的存档格式（如ZIP和RAR）和微软的Office文档（如Word和Excel），但也有少量Shell脚本和其它操作系统（如DOS, Linux）的可执行文件。通过一个基于特征码扫描加壳方式的工具SigBuster，我们发现40.64%被分析的PE文件经过加壳，图3是最常用的加壳方式概览。

 

 

图3 加壳类型概览

3.3 样本来源

      Anubis在两年间获得的样本来自超过120个国家，我们根据获得的样本对提交者进行了分类：大型，中型，小型，个体。大型提交者定义为提交超过1000个不同样本（根据MD5值）的实体（组织或个人），中型提交者定义为提交100～1000个不同样本的实体，小型提交者定义为提交10～100个不同样本的实体，个体提交者定义为提交少于10个不同样本的实体，表3是对此的一个总结。

提交者	数量	提交样本数占 总数本百分比
大型（1000-*） 中型（100-1000） 小型（10-100） 个体（1-10）	20 112 1279 30944	89.1% 3.8% 2.5% 4.5%

表3 样本提交来源

      值得注意的是20个大型提交者（提交了超过1000个样本）提交样本数几乎占到了总样本数的90%，而数目庞大的个体提交者的样本数仅占总数的5%。通过每个样本分析后的报告发现，中型提交者（可能是恶意程序分析员）提交的样本更可能是恶意程序（75%样本被标记为恶意的），相比之下，个体提交者提交的样本只有50%被认为是恶意的，由此推断个体提交者更倾向于上传随机文件，也许只是为了测试Anubis系统。

4 观测到的恶意程序行为

      本节，我们详细讨论通过Anubis观测到的样本的文件、注册表、网络行为以及僵尸网络特征，来提取不同来源的众多恶意程序的一般性行为。表2描述了一些我们感兴趣的一般性行为，以及样本所占百分比，考虑到恶意程序家族的影响，我们也对聚簇样本的这些行为进行了分析[4]。可以看到，二者百分比差距不大，究其原因，一方面当且仅当样本表现出相似的行为时，它们才会被归为一个聚簇，另一方面表2描述的行为都是一般性行为，无法表现个别样本和恶意程序聚簇的区别。而假如我们关注个别资源（比如文件、注册表键）的时候，就不是这样了。比如，4.49%的样本新建了文件C:"WINDOWS"system32"urdvxc.exe，但是样本聚簇中只有0.54%。这个文件是由一个广为人知的多变种蠕虫allaple建立的，而大量allaple实例被划分到了很少的一些聚簇里面。 

观测到的行为	样本百分比	聚簇百分比
安装Windows驱动程序 安装Windows服务 修改hosts文件 新建文件 删除文件 修改文件 安装IE BHO 安装IE工具条 显示图形窗口 网络通讯 写入标准错误 写入标准输出 修改注册表值 新建注册表键 新建进程	3.34% 12.12% 1.97% 70.78% 42.57% 79.87% 1.72% 0.07% 33.26% 55.18% 0.78% 1.09% 74.59% 64.71% 52.19%	4.24% 7.96% 2.47% 69.90% 43.43% 75.62% 1.75% 0.18% 42.54% 45.12% 0.37% 1.04% 69.92% 52.25% 50.64%

表2 观测到的行为

自启动位置	样本百分比	聚簇百分比
HKLM"System"Currentcontrolset"Services"%"Imagepath HKLM"Software"Microsoft"Windows"Currentversion"Run% HKLM"Software"Microsoft"Active Setup"Installed Components% HKLM"Software"Microsoft"Windows"Currentversion"Explorer"Browser Helper Objects HKLM"Software"Microsoft"Windows"Currentversion"Runonce% HKLM"Software"Microsoft"Windows"Currentversion"Explorer"Shellexecutehooks% HKLM"Software"Microsoft"Windows NT"Currentversion"Windows"Appinit Dlls HKLM"Software"Microsoft"Windows NT"Currentversion"Winlogon"Notify% HKLM"Software"Microsoft"Windows"Currentversion"Policies"Explorer"Run% C:"Documents and Settings"%"Start Menu"Programs"Startup"% 0.20% 0.95%	17.53% 16.00% 2.50% 1.72% 1.60% 1.30% 1.09% 1.04% 0.67% 0.20%	11.67% 17.80% 2.79% 1.75% 3.07% 2.29% 0.89% 1.89% 1.04% 0.95%

表4 排名前十位的自启动位置

      表4是另一个例子，17.53%的样本为了持久隐藏修改Imagepath位置的注册表，而从聚簇的角度来看，百分比下降到11.67%，这也是因为allaple。通过以上例子说明，当数据集中属于同一家族的多态恶意程序样本很多时基于聚簇的统计更加健全和可信。

4.1 文件系统行为

      通过表2可以看出，大量恶意样本（总数的70.8%）的执行会导致文件系统的改变——新建文件或修改已有文件。

      详细分析新建文件的时候，我们发现这些文件主要分为两种类型。一种是可执行文件，典型的原因是恶意程序需要复制或移动它的二进制文件到另一个位置（比如Windows系统文件夹），这个二进制文件常常是一个变异后的新文件。经统计，37.2%的的样本会创建至少一个可执行文件，然而有趣的是，样本中只有23.3%（创建可执行文件的样本的62%）选择Windows目录或其子目录作为目标文件夹。一个很大的比例——15.1%会在用户文件夹（Document and Settings目录下）创建可执行文件。这很有趣，并且我们可以推断，今后这种在普通用户权限下（不能修改系统文件夹）能够成功执行的恶意程序将日益增多。

      第二种类型的文件包括非可执行文件，样本中有63.8%创建了至少一个这种文件。这些文件有临时文件、必要的库文件（DLLs）和批处理脚本，它们中的多数在Windows文件夹（所有样本中的53%）或用户文件夹（可以在不同位置产生多个文件的样本中的61.3%）。值得注意的是，会有相当数量的临时Internet文件被IE生成（事实上，21.3%的样本的执行会产生至少一个这样的文件）。由于IE（更精确地说，ierturil.dll里的导出函数）在下载数据时会产生这些文件，而恶意程序这经常用IE下载额外组件。而大多数DLLs会被放入Windows系统文件夹。

      对已有文件的修改则没有这么有趣，因为大多数这类行为是由系统审计文件system32"config"SysEvent.Evt这个Windows事件日志产生的。少数情况下，恶意程序也会感染系统工具或某些众所周知的程序（比如Internet Explorer或是Windows media player）。

      接着，我们详细地检查了被删除的文件。我们发现大多数删除操作都指向了恶意代码自己产生的临时文件，我们又细致地检查了对日志文件和Windows事件审计文件的删除操作，发现，Windows下的恶意程序很少去清除日志数据里关于自身的行为记录（大概是作者假设用户不会查看这些日志），只有0.26%的样本会删除一个日志文件，只有0.0018%会删除事件文件。

      我们也检查了一些恶意程序可能在感染主机上寻找的特殊的文件或文件类型。为此，我们分析系统调用NtQueryDirectoryFile，它允许用户（或程序）隐藏文件。同时，我们发现许多有趣的模式，比如，数百个样本查询了后缀为.pbk的文件，这些文件存储了拨号电话本和通常访问的拨号。另一组样本查询了后缀为.pbx的文件，这是Outlook Express的消息文件夹。

4.2 注册表行为

      很多样本（62.7%）创建了注册表条目。这些样本中的37.7%，创建的注册表项与网络适配器的控制设置有关。这另一个很大一部分——22.7 ％的样本，创建的注册表键涉及到在Windows系统中注册的唯一标志符（SLSIDs）的COM对象。这些项是无害的，并且由于一些恶意程序不改变其组件的CLSID，所以这些标志符经常被用来检测特定恶意程序家族的存在。我们发现两个创建注册表项的恶意程序行为，1.59%的恶意程序在键SystemCertificates"TrustedPublisher"Certificates下创建了条目，这样它安装的证书将被系统信任，1.01%的样本创建了在Windows" CurrentVersion"Policies"System下面创建了键，阻止用户打开任务管理器。

      我们也检查了恶意程序通常修改的注册表项。最常见的这类行为是关闭Windows防火墙，有33.7%的样本为了实现这个目的修改Windows注册表项。同时，有8.97%恶意程序损坏了Windows的安全设置（键MSWindows"Security）。另一个和注册表相关的重要行为是程序设置自启动项，其目的是使机器重启后恶意程序仍能存活，我们发现35.8%的样本为实现自启动修改了注册表。如表4所示，列举了排名前10位的自启动位置，最常见的是占16.0%的Currentversion"Run和占17.53%的Services"Imagepath。键Services里存放了和Windows服务相关的所有配置信息。程序调用Windows API创建系统服务也是需要修改这个键下的注册表项的。

4.3 网络行为

行为	样本百分比	聚簇百分比
监听端口： TCP通讯： UDP通讯： DNS请求： ICMP通讯： HTTP通讯： IRC通讯： SMTP通讯： SSL： 地址扫描： 端口扫描：	1.88% 45.74% 27.34% 24.53% 7.58% 20.75% 1.72% 0.89% 0.23% 19.08% 0.01%	4.39% 41.84% 25.40% 28.42% 8.19% 16.28% 4.37% 1.57% 0.18% 16.32% 0.15%

表5 网络行为统计

      表5统计了恶意程序网络行为。图4描述了单个样本在一年半时间里使用的HTTP, IRC, SMTP协议，图5描述了通过聚类（使用[4]中的聚类方法）获得的恶意程序家族使用的HTTP, IRC, SMTP协议。对比之下，清楚地表明一些情况下聚类的好处：看了第一张图，你可能会想使用HTTP协议的样本数量增加了，然而当样本被聚类后，你会明白使用HTTP协议的恶意程序数差不多保持着一个常量，它并没有增加，可能只是因为多态样本的数量更多了。另一方面，通过图5我们看到IRC协议没有那么流行了。

图4 网络行为（单个样本）

图5 网络行为（聚簇/家族）

      此外，观察到有796个（样本的0.23%）样本使用SSL保护通讯。几乎所有使用SSL的样本都使用了HTTPS连接。并且，有8个采用SSL的样本使用了非标准SSL端口（443）去加密通讯。有趣的是，客户端进行SSL连接的多数时候，都无法完成握手。

      分析的样本中有一半（47.3%）通过查询DNS服务器解析域名。大多数情况下查询时成功的，然而有9.2%情况下没有返回结果。样本中有19%有扫描行为，通常是由扫描特定Windows端口（如139，445）或后门程序端口（如9988 – Trojan Dropper Agent）的蠕虫产生的。样本中8.9%通过连接远程站点下载其它可执行文件。图6描述了二次下载的恶意程序与提交给Anubis的样本的文件大小比照结果。正如你所预料的，平均下来，二次下载的可执行文件小于之前的恶意程序。

 

 

图6 样本大小

      注意有下载文件行为的样本中，超过70%的样本下载不止一个文件。甚至其中一个样本在4分钟的分析时间里将同一个文件下载了178次（如果一次下载没有成功，将立刻尝试下一次下载）。

4.4 GUI窗口

      表2表明样本中一个令人惊讶的比例（33.26%）会产生GUI窗口。更细致的分析表明只有很少（2.2%）是因为程序崩溃。最大的比例（4.47%）的GUI窗口没有标题栏和文本框，其它情况下我们提取出了窗口标题栏和文本框但是很难发现它们的共性。通过几十个手动分析结果我们确认，窗口名称和所含文本多种多样。大多数GUI窗口实际上是简单的消息框，伪装成某种类型的错误提示。我们认为这种情形出现的主要是为了减少用户的怀疑，毕竟一个错误框的出现比双击一个文件却没有反应引起的关注要小得多。比如，样本中1.7%会伪装一个消息框提示一个必须的DLL无法找到，然而如果这个消息是真的，它代表着创建csrss.exe这个进程。

4.5 僵尸网络行为

      虽然出现的时间不长，但僵尸网络已经迅速成为网络安全的最大威胁之一。近期的研究已经找到检测和终止僵尸网络的机制。为了知道样本中bots的数量，我们分析了Anubis记录的网络流量转储文件，这里我们关注三种bot：IRC，HTTP和P2P。

      通过分析报告识别bot的第一步是确定使用的网络协议，并且由于bot常常使用非标准端口，协议的检测不能基于端口。为此，我们是实现了IRC，HTTP和以下P2P协议——BitTorrent, DirectConnect, EDonkey, EmuleExtension, FastTrack, Gnutella, and Overnet的检测。

      下一步，我们需要定义捕获到的类bot行为的通讯特征库，基于对目前常见bots的了解：分布式拒绝服务攻击（DDoS），发送垃圾邮件，或是下载恶意的可执行文件。因此，如果报告中有任何这些已知行为（如地址扫描，端口扫描，DNS邮件交换记录（MX）查询，大数量的SMTP连接等），我们就认为它可能是一个bot。我们也使用一些启发式方法检测已知的bot，如IRC模式中的NICKNAME, PRIVMSG, TOPIC等，HTTP模式中的URL请求。分析这些bot被用来识别命令控制服务器并创建黑名单列表，黑名单持续更新，用以识别和证实新的bot样本。

      通过分析共识别出36,500个（5.8%）bot样本（30,059个IRC bots，4,722个HTTP bots，1,719个P2P bots）。这些样本中，97.5%后来被至少两个杀毒软件认为是恶意程序。然而，有时候杀毒软件也会吧样本进行错误的分类，比如，把Storm蠕虫的变种认为是HTTP木马，把我们所发现的所有P2P bots认为是Storm蠕虫的变种。

 

 

 

图7 僵尸网络样本统计（单个样本）

 

图8 僵尸网络样本统计（聚簇/家族）

      图7和图8描述了按照仅按照单个样本和仅按照bot家族进行统计的僵尸网络样本统计信息。通过比较两张图上的IRC僵尸网络，我们可以发现，2007年，大多数IRC僵尸网络属于不同家族，而到了2008年，数量仍然很多的IRC bots可能都是属于同一家族的变种了。比如，2008年5月出现的峰值是由Win32.Virut的大量变种产生的。

      有趣的是，在它第一次出现数月以后被我们识别出的样本仍然不能被杀毒软件识别。可能的原因是恶意程序使用了多态和变形技术。我们也查验了能够被一个杀毒软件厂商认为是bot但却能通过我们的检测的样本数量，这样的样本有105个，一个可能的原因是Anubis仿真系统采用的4分钟的最长运行时间的局限性。

      2007年1月19日，Storm蠕虫感染了欧美成千上万的计算机。然而，Anubis第一次大规模收集到Storm（96个样本）实在2007年4月。而在同年10月1日之后提交的大多数样本都有了加密能力，我们获得第一个使用加密进行会话通讯的样本实在2007年10月。

      详细分析IRC bot时发现13%的频道主题采用base64编码，并收集到13.000条僵尸网络控制着发送的真实命令。其中，88%命令客户端下载其它文件（如get和download命令），其它我们感兴趣的命令有ipscanm, login, keylog, scan, msn和visit。

      我们也统计了通过在非标准端口使用标准协议的样本的数量。HTTP bot中，99.5%的样本使用80或8080端口通信，只有62个样本使用了非标准端口。然而IRC bot就完全不同，92%使用非标准端口链接IRC服务器，例如最常用的两个端口：80和1863（Microsoft Messenger），用来绕过防火墙。

      最后，我们将收集到的1,719个Storm样本分成了两类：使用加密通讯信道的变种和不进行加密的恶意程序。至于解密密钥，我们只发现了一个对称密钥，它始终被用来加密Storm的通讯。

4.6 沙箱检测

      另一个有意思的恶意程序行为是它检测分析环境如Anubis的存在的能力。动态分析系统是收集恶意程序数据的流行方式，所以恶意程序使用技术防范这种分析并不是奇怪的事情。当一个恶意程序检测到沙箱时，最常见的行为是终止自己的执行。这一节，我们将评估使用反沙箱（一般的和Anubis）技术的样本数量。

      沙箱检测技术分为两类：一类是由通过真实CPU和一个仅仅利用CPU指令的仿真系统的区别来检测的指令级检测技术；另一类是通过调用一个或多个（Windows）API来查看环境的API级检测方法。

      不幸的是，目前我们没有一个好的指令级检测方法。虽然理论上在全系统仿真条件下可以监视单指令，但是出于性能原因，本质上来说，Anubis是工作在API（和系统调用）级别的。因为Anubis是利用Qemu来做全系统仿真，所以它很容易被能够检测到Qemu的方法检测出来。有几条检测策略（它们都是指令级检测策略）[9], [15]尤其容易发现Anubis。

      因为我们监视着Windows API调用，我们能够更好地发现API级的检测方法。写本文时，网络上已经公开了集中专用来检测Anubis的方法[2]。它们都是通过比较Windows API如GetComputerName的返回值与可识别Anubis的硬编码值来实现的。系统包括一个数据感染模块，当一个我们感兴趣的API调用的输出随即被作为操作数做比较的时候，我们就可以检测到。因此，如果有样本执行了博客和论坛上公开了的能检测Anubis的比较操作，它们能够被分析出来。表6总结了我们的发现。这里我们特别讨论一些发现。我们的系统将每个样本命名为“sample.exe”，于是一个众所周知的Anubis检测历程将Windows API – GetCommandLine的返回值和“sanple.exe”比对，同样，过去每个样本总是被作为一个名叫“user”的Windows用户来执行，因为可以通过将NtQuerySystemInformation的结果和“user”进行比对从而检测Anubis（顺便说一下，我们已经把用户名改成“Administrator”了）。

观测到的比较	样本数目	聚簇数目
Anubis的Windows产品Id CWSandbox的Windows产品Id Joebox的Windows产品Id 名为sample.exe的可执行文件 Anubis的计算机名 Qemu的硬盘名 VMWare的硬盘名 名为’user’的Windows用户名	55 32 32 35 4 2 1 2	28 14 14 17 4 2 1 2
任何反Anubis的比较 任何反沙箱的比较	99 100	54 55

 

表6 观测到的反沙箱比较统计

      我们总共只发现0.03%的样本（99个独立的恶意程序）包含已知的对Anubis的检测。这些样本中的大多数在执行的开始阶段进行检测，如果发现位于沙箱中则立即退出执行。当然，也许恶意程序还有别的沙箱检测方式。此外，正如前文所述，我们没有一个检测指令级沙箱检测和基于计时器的沙箱检测方法，所以，本报告中的数目只是一个下界。

      假设一个样本检测到Anubis（或者一个沙箱）之后不再表现过多的行为，我们也可以给出执行了沙箱检测的样本的上界。基于Anubis的经验，我们认为一个行为报告（一个简表[4]）包含少于150项时，表示“没有太多的行为”，而每个简表平均有1,465项。在这样的顶一下，我们发现12.45%的可执行样本（13.57%的聚簇）没有太多的行为。

      当然，不是所有样本真的都有反沙箱历程，还有多个原因使得Anubis不能做出一个更好的报告。比如，要用户输入（如安装者）的GUI程序无法充分分析，因为Anubis在模仿用户输入的方面做得有限，只能简单地关闭窗口。并且，有的程序在执行时需要不存在的组件（注意，这些程序执行失败是因为条件不满足，静态DLL依赖未被包含的占12.45%）。此外，至少0.51%的带壳样本因为Qemu不能正确仿真（比如Telock以及Armadillo和PE Compact的特定加壳版本）导致输出报告中没有太多的行为。最后但不是全部，Anubis和Qemu的漏洞也是可能的原因之一。

5 结论

      恶意程序是当前网络上最严重的问题之一。虽然已经存在恶意程序的很多方面的研究，但基于感染计算机后的主机级恶意程序行为的正式文献还是很少。

      在本文中，我们重点解释恶意程序的一般性行为。我们完成了几乎一百万恶意程序的综合分析并考虑到了恶意程序的代码多态性的影响。理解恶意程序的一般性行为对开发有效恶意程序防范和反击技术有重要意义。

鸣谢

      本文的工作得到了欧盟委员FP7-ICT- 216026-WOMBAT项目，FIT-IT的Pathfinder项目，FWF的Web-Defense项目（No. P18764）和Secure Business Austria的支持，再次表示感谢。

参考文献

[1] ANUBIS. http://anubis.iseclab.org, 2009.

[2] Forum Posting - Detection of Sandboxes. http://www.opensc.ws/snippets/3558-detect-5-different-sandboxes.html, 2009.

[3] P. Baecher, M. Koetter, T. Holz, M. Dornseif, and F. Freiling. The Nepenthes Platform: An Efficient Approach To Collect Malware. In Recent Advances in Intrusion Detection (RAID), 2006.

[4] U. Bayer, P. M. Comparetti, C. Hlauschek, C. Kruegel, and E. Kirda. Scalable, Behavior- Based Malware Clustering. In Symposium on Network and Distributed System Security (NDSS), 2009.

[5] U. Bayer, C. Kruegel, and E. Kirda. TTAnalyze: A Tool for Analyzing Malware. In 15^th European Institute for Computer Antivirus Research (EICAR 2006) Annual Conference, April 2006.

[6] F. Bellard. Qemu, a Fast and Portable Dynamic Translator. In Usenix Annual Technical Conference, 2005.

[7] M. Christodorescu and S. Jha. Static Analysis of Executables to Detect Malicious Patterns. In Usenix Security Symposium, 2003.

[8] M. Egele, C. Kruegel, E. Kirda, H. Yin, and D. Song. Dynamic Spyware Analysis. In Usenix Annual Technical Conference, 2007.

[9] P. Ferrie. Attacks on more virtual machine emulators.

[10] G. Gu, P. Porras, V. Yegneswaran, M. Fong, and W. Lee. BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation. In 16th Usenix Security Symposium, 2007.

[11] N. P. Michalis Polychronakis, Panayiotis Mavrommatis. Ghost Turns Zombie: Exploring the Life Cycle of Web-based Malware. In Workshop on Large-Scale Exploits and Emergent Threats (LEET), 2008.

[12] Microsoft PECOFF. Microsoft Portable Executable and Common Object File Format Specification. http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx, 2000.

[13] D. Moore, C. Shannon, and k claffy. Code-Red: A case study on the spread and victims of an Internet worm. In ACM Internet Measurement Workshop, 2002.

[14] A. Moshchuk, T. Bragin, S. Gribble, and H. Levy. A Crawler-based Study of Spyware on the Web. In Network and Distributed Systems Security Symposium (NDSS), 2006.

[15] T. Ormandy. An empirical study into the security exposure to hosts of hostile virtualized environments.

[16] N. Provos, P. Mavrommatis, M. Rajab, and F. Monrose. All Your iFrames Point to Us. In Usenix Security Symposium, 2008.

[17] M. Rajab, J. Zarfoss, F. Monrose, and A. Terzis. A Multifaceted Approach to Understanding the Botnet Phenomenon. In Internet Measurement Conference (IMC), 2006.

[18] L. Spitzner. Honeypots: Tracking Hackers. Addison-Wesley, 2002.

[19] H. Yin, D. Song, M. Egele, C. Kruegel, and E. Kirda. Panorama: Capturing System-wide Information Flow for Malware Detection and Analysis. In ACM Conference on Computer and Communication Security (CCS), 2007.