很不幸，你在自己的电脑里发现了一个恶意的可执行程序！那么问题来了：这个文件到底有没有执行过?
在这篇文章中，我们会将注意力放在Windows操作系统的静态取证分析之上，并跟大家讨论一些能够帮助你回答上面那个问题的方法以及证据源，其中涉及到的四大主要的证据源包括Windows Prefetch、注册表、日志文件以及文件信息。
Windows Prefetch
Windows Prefetch（Windows 预读取）是一个查找文件执行证据的好地方。根据微软的设计方案，Windows Prefetch的功能就是允许那些经常需要使用到的程序打开得更加快。默认设置下，它会在预读取文件（存储路径为”C:WindowsPrefetch”）中存储最近执行的128个文件的信息。一个预读取文件的命名规则为”可执行文件名+文件路径的哈希+后缀名.pf”，预读取文件中会保存文件的第一次和最后一次运行日期、文件路径和执行次数等信息。所以说，如果你的恶意软件文件名或路径哈希出现在了一个预读取文件（例如” DABEARS.EXE-12F3B52A.pf”）之中，那就说明这个恶意文件曾在你的电脑中执行过了。
注：Windows Server默认禁用了预读取功能。
注册表
没错，Windows注册表可是一个巨大的“宝藏”，注册表可以算是Windows系统能够正常运行的基石了。虽然注册表非常“庞大”，但是我们接下来给出的表单却并没有那么复杂。因为如果要确定一个文件是否执行过，我们只需要检查几个重要的注册表键即可：
1. ShimCache
微软使用了ShimCache或“AppCompatCache”来识别应用程序的兼容性问题。缓存数据能够追踪文件路径、大小、最后修改时间和最后一次运行的时间。如果一个文件以Windows进程的形式执行过，那么它的信息将会被记录到ShimCache中，但是ShimCache中记录的文件信息并不能100%证明一个文件执行过，因为它只能证明Windows曾与该文件交互过。下面这个注册表键中包含了ShimCache数据：
HKLMSYSTEMCurrentControlSetControlSessionManagerAppCompatibilityAppCompatCache(for XP)
HKLMSYSTEMCurrentControlSetControlSessionManagerAppCompatCacheAppCompatCache(for Non-XP)
更多关于ShimCache的内容，请参考Andrew Davis的【这篇文章】以及Mandiants的【会议报告】。
2. MUICache
当一个文件通过Windows Explorer（资源管理器）运行，程序Shell会在MUICache中创建一个入口。Windows使用MUICache来存储应用程序名以及其他相关信息，获取来的信息主要存储在下面的注册表键中：
HKCUSoftwareMicrosoftWindowsShellNoRoamMUICache(for XP, 2000, 2003)
HKCUSoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache(for Vista, 7, 2008)
关于MUICache的更多内容，请参考windowsir的【这篇文章】。
3. UserAssist
UserAssist可以追踪可执行程序以及资源管理器中打开的链接，UserAssist键能够追踪文件的最后一次执行时间以及执行次数，并将信息存储在下面这个注册表键中：
HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssistUserAssist键的值对应了可执行程序的名称以及文件路径，并使用了ROT13加密。因此，如果你想直接通过搜索关键字来查找文件执行的证据的话，在不解码的情况下是无法做到的。目前也有很多工具可以解密这个注册表键，例如RegRipper userassist.pl插件【点我获取】。
日志文件
为了确定一个文件是否执行过，我们还可以根据日志文件的分析结果来判断。首先我们来看一看Windows System Event Log（系统事件日志），因为这个日志文件记录了服务的启动信息。下图显示的事件（Event ID=”7035″）信息表明，一个管理员（SID=”-500″）运行了PSEXECSVC远程执行服务：
当一个服务启动时，它通常会执行ImagePath中定义的文件或一个已加载的服务DLL。比如说，”Netman”服务在执行时使用了一个合法文件”netman.dll”。但是，如果注册表中的ServiceDll（例如”tabcteng.dll”）包含一条指向后门的路径，那么”Netman”服务将会执行”tabcteng.dll”。所以，你可以通过分析ImagePath和ServiceDll的有效性来判断是否有恶意服务启动过。
如果Windows Event Log（事件日志）的审计设置开启了Audit Process Tracking（审计进程追踪）功能，那么Windows Security Event Log（安全事件日志）中将会记录大量关于进程的信息，而这些信息绝对能够证明一个文件是否执行过。下面这两张图片显示了恶意文件、相关进程ID、父进程ID和用户名，这些信息可以帮助我们进行进一步分析：
XP EventID 592 – 进程创建：
Windows Vista+记录下了类似的进程创建事件，EventID为4688：
在更新版本的Windows中，审计功能所能记录的信息将更加精确化，并且微软从Windows Server 2008 R2以及Windows 7中将这个功能整合到了Group Policy（组策略）中。关于审计策略设置的更多信息请参考微软给出的【这份文档】。
除此之外，基于主机的IPS或反病毒产品日志同样可以表明一个文件是否执行过，或者曾经尝试执行过。下图给出的是McAfee Access Protection日志中记录下的一次访问事件样本：
Windows Scheduled Task Log（计划任务日志）可以帮助我们判断攻击者是否使用了Windows的计划任务功能来运行恶意软件。计划任务的信息会被记录在一个名叫”SchedLgU.txt”的日志文件中：
在Windows Vista+平台中，计划任务的执行信息还会记录在”Microsoft-Windows-TaskScheduler/Operational”日志中：
最后，如果一个程序崩溃了，那么Dr.Watson日志可以记录下恶意任务的运行信息：
文件功能
另一种判断文件是否运行过的方法就是寻找可疑的输出文件。当你在分析一个恶意文件时，它是否会创建任何的数据呢？比如说，如果你发现的这个恶意文件是一个键盘记录器，然后你又在系统中发现了键盘记录文件，则说明攻击者已经执行过这个keylogger了。如果恶意软件能够与特定的域名进行链接，那么浏览器的历史记录中肯定也会记录下相关域名。下表中显示的是我们在浏览器历史纪录中捕捉到的样本，这个后门样本使用了两种通讯机制：
想要判断恶意文件是否执行过，我们可以分析文件的功能并在磁盘中寻找相应功能的运行结果/证据。分析恶意软件的功能不仅可以帮助我们了解攻击者的动机和最终目标，而且还有可能帮我们找出其他相关的恶意文件。
注：如果你在自己的系统中发现了恶意的可执行文件，别忘了先将当前系统内存中的数据导出，你可以使用MandiantRedline服务捕捉并分析内存数据。