译者：nstlBlueSky

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

你发现了一个恶意的可执行文件，现在你有一个关键的问题要回答：文件是否执行？这篇文章中我们将讨论一些可用于回答这个问题的一些依据。在文中，我们将重点介绍Windows系统上的静态或“死锁”取证。我们将介绍四个主要的依据：Windows预读取，注册表，日志文件和文件信息。

预读取

Windows 预读取是最开始查找文件执行证据的好地方。 微软设计的Windows 预读取允许常用程序可以很快的打开。默认情况下，它将最近128个执行文件的信息存储在“C:\Windows\Prefetch”中的预读取文件中。预读取文件被命名为"可执行文件名"+文件路径的哈希值+.pf。预读取文件中存储进程执行前十秒内的第一次和最后一次运行日期、文件路径、执行的次数以及需要加载的文件。因此，如果您的恶意软件存在文件名显示为“DABEARS.EXE-12F3B52A.pf”这样的预读取文件，那么您将知道该文件已经在执行了。不过请注意：在Windows服务器上，默认情况下是禁用预读取功能的。

注册表

正如人们所期待的那样，Windows注册表中包含大量有关Windows系统中程序运行的信息。由于注册表很大，下面的列表可能并不全面，但它显示了我们需要检查的主要注册表项以用来确定文件是否在执行：

1. ShimCache

Microsoft创建了ShimCache或“AppCompatCache”来识别应用程序兼容性问题。高速缓存数据跟踪文件路径，大小，最后修改时间和最后“执行”时间（取决于操作系统）。如果使用Windows的“createprocess”执行文件，则系统会将其记录在ShimCache中。虽然文件在ShimCache中的存在不能100％证明文件执行，但它确实显示Windows与文件进行了交互。以下注册表键值包含了ShimCache数据：“HKLMSYSTEMCurrentControlSetControlSession

ManagerAppCompatibilityAppCompatCache(XP)和“HKLMSYSTEMCurrentControlSetControlSession

ManagerAppCompatCacheAppCompatCache”（非XP）。有关ShimCache的更多信息，请参阅Andrew Davis的博客条目 - 或Mandiant的SANS DFIR会议介绍。

2. MUICache

当通过Windows资源管理器执行文件时，shell程序会在MUICache中创建一个条目。 Windows事件响应博客上有一篇很好的文章介绍了整个过程。 Windows使用MUICache来存储从资源部分中的PE版本信息检索到的应用程序名称。信息存储在以下键中：

“HKCUSoftwareMicrosoftWindowsShellNoRoamMUICache”（XP，2000,2003）和

“HKCUSoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache”（Vista，7，2008）。

3. UserAssist

UserAssist跟踪在Explorer.exe中打开的可执行文件和链接。 UserAssist键跟踪文件在注册表项中运行的最后执行时间和次数：“HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist”。 UserAssist键下内容对应于可执行文件名称和用ROT13加密的文件路径值;因此，如果您在解码之前进行关键字搜索，您可能会错过该键值内的依据。有许多解密注册表键值的工具，包括RegRipper userassist.pl插件。

日志文件

您可以分析几个日志来确定文件是否执行。从Windows系统事件日志开始，因为此日志记录服务启动。图1中的事件显示一个管理员（SID =“ - 500”）执行了PSEXECSVC远程执行服务：

图1：事件ID 7035 -服务启动

服务启动时，通常会执行ImagePath中指定的文件或加载所需的服务DLL。 例如，“Netman”服务在执行时使用合法的文件“netman.dll”。 但是，如果注册表中的ServiceDll包含了一个名为“tabcteng.dll”的后门路径，则“Netman”服务将执行“tabcteng.dll”。 所以，在启动服务程序时有必要验证ImagePath的文件以及ServiceDlls。

如果在Windows事件日志审核设置中启用了审计流程跟踪，则Windows安全事件日志中包含了大量有关执行进程的信息，以此可以用来证明文件是否在执行。 图2和图3显示了恶意文件和关联进程ID，以及父进程ID和用户名，可以帮助进一步调查。

图2：XP事件ID 592 - 进程创建

Windows Vista 记录了类似的进程创建事件，但EventID为4688。

图3：Vista EventID 4688 - 流程创建

在比较新版本的Windows系统中，审核功能会更精细，并且在Windows Server 2008 R2和Windows 7中与组策略集成在一起。高级审核策略设置可以在图3中找到。

在这篇文章中有太多的供应商可以覆盖，但是基于主机的IPS或AV产品日志可能会在文件运行或尝试对其他文件进行操作时显示。 图4包含来自McAfee Access Protection日志的示例事件。

图4：McAfee Access Protection日志事件

Windows计划任务日志可以用来确认攻击者是否在使用计划任务来执行恶意软件。 计划任务记录在名为“SchedLgU.txt”的日志文件中，如下所示：

图5：计划任务日志中的事件

在Windows Vista +中，计划任务执行也记录在事件ID 为200和201下的“Microsoft-Windows-TaskScheduler / Operational”事件日志中。

图6：事件ID 200和201 - 计划任务执行

最后，如果应用程序崩溃，Watson日志可能会记录运行的恶意任务。

图7：在Dr. Watson Log中捕获的运行任务

文件信息

确定文件是否被执行的另一种方法是查找与该文件相关的任何其他输出文件。分析恶意文件时，观察它是否配置为创建数据？例如，如果您发现的恶意文件是键盘记录器，并且系统中存在相关的密钥记录文件，则攻击者可能会执行该文件。如果恶意软件已配置为连接到特定域名，则浏览器历史记录可能已记录关联的域。表1包含从相同后门在浏览器历史记录中捕获的两种通信机制的示例。

表1：浏览器历史记录中的恶意通信

要确定系统是否执行了恶意文件，请分析文件的功能，并查找磁盘上是否有生成的其他文件。 恶意软件功能还可以帮助您评估攻击者的动机，最终目标，并可能揭示其他恶意文件。

虽然这篇文章涵盖了我们用来检测文件执行的主要依据，但还有更多的注册表项和其他Windows文件可以提供恶意软件执行的依据，特别是在Windows Vista及更高版本中。 类似地，在系统内存中发现的信息对于证明文件执行可能更有价值，并且可以提供特定的攻击者执行的命令和访问的资源。 所以如果您在正在运行的系统上发现恶意可执行文件，请确保在执行其他操作之前保存内存快照。 您可以使用Mandiant Redline™读取和分析内存。