实测 Process Monitor 的系统启动日志功能确实强
之前的文章：《运维和网安必备：Sysinternals Process Monitor 4.01 更新（还有 Linux 版）》介绍了 Process Monitor 新版本功能，其中提到了不算是新功能的 Boot Logging，也就是启动日志。
相信对等级保护要求有了解的读者都知道网络安全日志的重要性。因此，Process Monitor 产生的启动日志、Windows MSCONFIG 程序产生的启动日志，以及 Windows 本身的事件日志（系统启动阶段产生的内容）这三者，可以放在一起比较一下。
笔者：国际注册信息系统审计师、软考系统分析师、软件工程硕士
为简化行文，以下一律用 PM 指代 Process Monitor。
产生启动日志的操作非常简单，只需要在 PM 的 Options 菜单中勾选 Enable Boot Logging，如图1：
图1
如图2确认然后关闭 Process Monitor，重启计算机即可。
图2
注意如果在 PM 中设置丢弃被过滤的事件，最终收集的日志内容就会不完整。所以，除非自己清楚要收集的目标内容，否则不要设置过滤器和勾选Drop Filtered Events，如图3。
图3
计算机完成重启后，一般要安排一段干预尽量少的运行等待时间，让 PM 充分收集系统后台各种进程产生的活动信息。
可先等待一段时间然后登录，又或者立即登录计算机后再等待一段时间。
也就是要预估 PM 能收集到所需要的启动日志的时间长度、需要分析的目标事件会在登录前还是登录后产生等情况，以此为条件去确定收集启动日志过程如何处置。
然后再次运行 PM，PM 就会提示是否保存本次产生的启动日志，如图4：
图4
确认并指定保存路径后，PM 就会把缓存了的启动日志保存为PM自有的 PML 格式文件如图5，并在完成保存后自动打开查阅。
图5
还可以把收集到的启动日志另存为 CSV 格式然后用电子表格软件进行简单统计，或者导入到 PSPP、数据库等环境作深入的统计和分析。但要注意 CSV 文件太大的话，电子表格软件是无法应付的。
以上过程也可以通过命令行进行。PM 的命令行参数如图6：
图6
即如果要设定启用启动日志，只需要在命令行输入：
procmon /EnableBootLogging
然后重启。完成重启登录过程后，再在命令行执行：
procmon /ConvertBootLog PML文件名
即可得到启动日志文件。
1）确保C盘有足够的空间让 PM 能暂存启动日志。一次完整的系统启动，其需要的启动日志空间至少1GB。
如果启用记录 Profiling 信息，所需的日志空间就更大了。但在安全分析方向一般不涉及 Profiling。
2）保存 PML 日志记录文件时，保存位置应指定为本地硬盘而不要指定到网络路径。
尤其是如果保存位置指定为 VMware Workstation Pro 宿主机和虚拟机之间的共享文件夹路径时，会有可能丢数据导致 PML 文件破坏，无法再被 PM 加载。笔者所用 17.6.1 版本测试了两次都出现该情况，原因不明。
3）PM 支持命令行操作使得它可以在脚本中被调用，还可以作为系统任务计划程序的自动任务而执行，读者可自行尝试。
由于 PM 收集启动日志的设计是每次被设置仅执行一次，如果要反复执行，就需要结合命令行操作和任务计划实现自动化。这也包括日常要机动调用 PM 收集进程事件日志的场合。
4）启动日志的设置有可能启用失败，PM 反馈说：“Unable to write PROCMON23.SYS. Make sure that you have permission to write to the %%SystemRoot%%\System32\Drivers directory.”
这种情况大多数是由于上一次的 PM 运行期间生成的 PROCMON23.SYS （文件名可能会随着版本不同）驱动程序文件没有被自动删除且仍在运行，导致本次运行就无法创建驱动程序文件。
解决办法就是到 Drivers 目录下找到已存在的 PROCMON23.SYS，然后将其改名（因为在使用中，删除不了），重启系统后再到 Drivers 目录下将之删除。
观察获得的启动日志，可见第一条日志是 SMSS.EXE 产生的。特别是，可以注意到它的 Parent ID 是4，如图7：
图7
SMSS.EXE （Session Manager Subsystem）是 Windows 中非常重要的系统程序文件，历史可以追溯到 Windows 3.1。它负责管理和启动用户会话环境[1]。
读者或者会问，PID=4 代表了啥？
点开任务管理器，详细信息，按 PID 排序（如果看不到 PID 就右击标题栏选择显示 PID），就会看到 PID=4 的进程如图8，也就是 System 这个伪进程本身（由 Ntoskrnl.exe 创建）：
图8
所以 PM 启动日志能截获的进程活动信息是在系统启动过程中相当早的位置就开始的，确实强。
回到最开头的问题，通过日志性质和内容的比对，观察它们的区别。笔者作了个简要的比对汇总如下表。其中提到系统引导的4个阶段，参考内容见[2]。
| PM 启动日志 |
MSCONFIG 启动日志 |
Windows 事件日志 |
|
|---|---|---|---|
| 性质 | 行为 | 信息 | 信息及行为 |
| 格式 | 平铺矩阵 | 清单 | XML 树状 |
| 控制 | 一次性 | 持续 | 持续 |
| 信息量 | 巨大 | 不具可比性 | 巨大 |
| 内容范围 | 基于进程 | 仅驱动程序清单 | 全面 |
| 时间范围 | 引导第3阶段启动 SMSS.EXE 开始至用户介入结束 | 仅引导第3阶段内 | 引导第3阶段开始直至系统关机 |
MSCONFIG 启动日志和 Windows 事件日志的设置方法、以及比对简评如下：
1）MSCONFIG 启动日志
运行 MSCONFIG.EXE，如图9勾选启动日志，确定退出MSCONFIG 后重启系统，就会在 Windows 目录下生成 NTBTLOG.TXT 文件，其内容如图10。该勾选项是持续有效的。
图9
图10
从日志文件内容可发现，MSCONFIG.EXE 产生的启动日志信息量太少，其使用目的只是为了列出系统启动期间加载的驱动程序的清单，和其他两项基本没有多少可比性。
而且，该日志很容易被篡改，导致在正常启动情况下意义不大。反观 PM 的 PML 日志文件，是带有校验措施的。
稍作扩展说说这个清单。它完全独立于系统事件日志之外，没有其他方法可以生成，事件日志里面包含的驱动程序加载信息只是这个清单的一部分。
但 Sysinternals Suite 里面有一个名为 Autoruns 的工具，可以检查列出系统启动时会自动加载运行的程序，包括驱动程序。这对于一般情况来说也够用，特殊情况除外。
2）Windows 事件日志
在组策略设置中开启一大堆审核开关（如图11）后才会产生足够丰富的输出，熟悉系统加固或经历过等保测评的读者肯定不陌生。例牌顺带吐个槽，“审核”实应为“审计”，因为英文原文为 audit。微软自从使用机器翻译后组策略编辑器内出现大量翻译错误。
图11
比如，在组策略中开启了审计进程创建后，如图12的事件日志（自定义视图，结合了系统日志和安全日志）就可以显示从 Registry 这个伪进程被创建开始的进程创建信息。
图12
它这比 PM 的记录从 SMSS.EXE 开始还要早，但差别不大，也就一个身位。
两厢对比就会发现，Windows 系统事件日志，在记录系统启动过程这个使用范围内，PM 启动日志对其是很好的补充。
关键在于，Windows 系统事件日志的定位是记录系统运行逻辑，以信息及行为共同表达。所以它提供的信息的详尽性是侧重于表达运行逻辑的，缺乏了像 PM 输出的这种进程活动行为情况。
而且，PM 提供的信息比事件日志要丰富，工具使用人的自主针对性也更强。
另外，Windows 系统事件日志的查阅筛选操作在事件查看器内十分不方便，一般还要使用事件日志查看工具才能提高效率[3]，这和 PM 比有距离。
太长没人看，简单测试到此结束，小结一下：
1）PM 的启动日志功能颇为有用，适宜作为 Windows 事件日志的补充；
2）高风险环境可考虑通过任务计划程序设置每次开机均记录和存档 PM 启动日志；
注：题头图为笔者自行拍摄。
参考引用：
[1] Understanding Windows Boot Process
https://knowitlikepro.com/understanding-windows-boot-process/
[2] The magic trick I discovered in the Windows 10 boot process...
https://jon.glass/blog/looks-at-the-win10-boot-process/
[3] NirSoft - FullEventLogView
https://www.nirsoft.net/utils/full_event_log_view.html
本站微信订阅号：
本页网址二维码：