2020年6月，Sysinternals工具集放出一波更新，Autoruns 13.98、Sigcheck 2.8、Sysmon 11.10三个常用工具在同一批发布。很多放下这段不用的朋友只注意到版本号又跳了一级，但对我来说真正有意思的是Sysmon在“Mark of the Web（MOTW）”取证上的实际玩法，以及Autoruns和Sigcheck组合起来之后，对终端启动项和文件信任链的排查效率能提升一个档次。这篇文章就是我的速记，把三个版本的使用场景、关键参数和分析思路记录下来，适合做系统运维、安全监测和应急响应的朋友按需取用。

1. 更新速览：三个版本放在一起看的价值

1.1 版本变化不是重点，组合使用才是

单看版本号，2020年6月这批更新里数字变化不算激进：Autoruns从13.90多跳到13.98，Sigcheck来到2.8，Sysmon则是11.10。如果你之前一直在用旧版，升级后你会发现界面布局、命令行参数基本没动，学习成本几乎为零。Autoruns依旧是那个能扫出注册表、计划任务、驱动、服务等几十个启动位置的“开机自启全家桶”；Sigcheck依然是验证文件签名和哈希的标准级工具；Sysmon则继续扮演终端行为日志的“放大器”。

但把三个工具放到一起看，这波更新实际是在补同一块拼图：让调查者能回答“这台机器上什么程序被允许启动了、什么文件带着互联网属性进来了、进程是怎么执行的”。Autoruns在加固签名校验策略，Sigcheck在提升签名和Zone信息识别的准确性，Sysmon在让文件流转过程产生更细粒度的日志。三者连起来，正好覆盖一条终端的信任链：文件从外面进来（MOTW）→ 文件被落盘（Sysmon文件事件）→ 进程被拉起（Sysmon进程事件）→ 进程把自己写进自启动（Autoruns找得到）。

这也是我写这份速记的出发点。工具本身不难，难的是版本更新后你知道该去看哪些字段、用什么参数能把场景串起来。

1.2 三个工具的适用场景对照

三者不是替代关系。Autoruns看的是“静止状态”的启动配置，Sigcheck看的是“单个文件”的信任属性，Sysmon看的是“运行过程”的动态行为。实际排查时我通常按这个顺序走：先让Sysmon记录行为，出事后用Autoruns找持久化条目，再用Sigcheck验证可疑文件的签名来源。反过来，如果你只有一份刚刚截图下来的启动项清单，也可以用Sigcheck把可疑项的签名和Zone信息查清楚，再回Sysmon日志里追这个文件是什么时候出现的。

1.3 更新带来的“隐形改动”

这批更新里最值得注意的不是新按钮，而是对已有能力的细节打磨。Autoruns 13.98对同类启动位置的扫描结果进行了更好的归并，部分老签名证书会被识别为“已过期/不受信任”，新增的校验逻辑也让白名单对比更干净。Sigcheck 2.8在解析Zone信息时能更稳定地识别从浏览器、下载工具、聊天软件等来源落地的文件，这对后面要讲的MOTW取证很重要。Sysmon 11.10则继续保持小步快跑，性能更稳，配置包兼容性没有大变化，可以平滑替换旧版本。

我个人的经验是：Sysinternals这套工具不要一直停在旧版。它是安全排查的“眼睛”，眼睛的视力不更新，后面所有判断都会带着误差。尤其当你手里的Windows系统版本在持续变化时，旧版工具对新机制的识别能力一定会越来越弱。

2. 先读懂 Mark of the Web，再看取证玩法

2.1 MOTW到底是什么

Mark of the Web，简写MOTW，字面意思是“来自Web的标记”。当一个文件通过浏览器、邮件客户端、即时通讯工具等互联网渠道下载到本地时，操作系统会在文件上额外写一条名为Zone.Identifier的NTFS数据流，并且在这个数据流里保存类似ZoneId=3的标识。ZoneId为3代表“互联网区域”，为4代表“受限区域”。你可以用命令最直观地看到它：

notepad.exe "C:\Downloads\sample.exe:Zone.Identifier"

如果能打开一个文件内容只有[ZoneTransfer]、ZoneId=3的记事本窗口，就说明这个文件带着MOTW标记。这条标记的作用原本是安全提示：桌面Shell和部分应用会依据它弹出“来自Internet的文件可能对计算机造成危害”的警告，Office也会据此禁用宏和ActiveX。

但对取证人员来说，MOTW更重要的价值在于它可以回答一个经典问题：“这个文件是怎么到这台机器上的？”互联网下载、U盘拷贝、内网共享、压缩包内解压，这几种途径产生的MOTW状态完全不同，因此它成了攻击链起点的高价值痕迹。

2.2 MOTW在事件链中的位置

一套典型的钓鱼攻击链路是这样开始的：受害者在浏览器里点开一个链接，某个文件被下载到Downloads目录，文件带着MOTW；随后受害者双击这个文件，系统会弹出警告，但攻击者只要把文件名伪装成PDF或者利用供应链软件的漏洞，依然能诱导执行。文件被执行后，一系列恶意行为才真正开始。

在这个过程中，MOTW是受害者机器上第一条与“外部来源”相关的证据。传统排查思路喜欢先找恶意文件路径、再看注册表启动项，但如果恶意文件在运行后自删，或者伪装成系统文件名，路径线索会断掉。而MOTW所对应的下载痕迹、浏览器记录、NTFS ADS记录，往往比文件本体存活得更久。

举一个我实际遇到过的场景：某天监测到一台主机频繁外连异常域名，找遍启动项和计划任务都没有发现可疑项。最后在Sysmon的FileCreateStreamHash事件里看到某个可执行文件的Zone.Identifier流哈希，顺着时间戳往前翻了浏览器的下载历史，才定位到最初落地的样本。这个样本已经自删了，但MOTW痕迹和它被释放出来的时间线仍然在日志里完整保留着。

2.3 Sysmon怎么把MOTW变成可审计证据

Sysmon的价值在于把“文件带不带MOTW”这件事从“需要手动查看ADS”变成“自动产生事件”。具体实现的机制是FileCreateStreamHash，对应系统日志里的“文件流已创建”事件。当一个文件被创建或修改，并且伴随NTFS数据流生成时，Sysmon会记录文件名、流名、流内容哈希等信息。Zone.Identifier就是一个典型的流名，所以下载文件落地时，Sysmon通常会同时产生一条文件创建事件和一条带Zone.Identifier流哈希的事件。

这里有一个版本细节需要留意：如果你的Sysmon版本相对旧，可能看不到独立的文件流创建事件，那么MOTW取证就需要退而求其次，结合进程创建事件、文件创建时间和浏览器下载记录来交叉验证。我在2020年6月这批更新里反复测试过11.10，整体表现稳定，配置文件兼容旧规则，但如果你需要完整的ADS捕获能力，尽量把Sysmon升级到支持文件流事件的版本再下结论。实践里，我见过不少分析人员直接拿旧版Sysmon日志去判断“这个文件是否带MOTW”，最终因为事件缺失得出了完全相反的方向。

3. 实操：Autoruns 13.98 启动项大清点

3.1 启动项三大入口

Autoruns的主界面看起来信息量很大，几十个Tab分类让人发怵。但其实日常排查只需要抓住三个最常被利用的入口：登录项、计划任务、服务与驱动。

登录项对应“登录”和“任务计划程序”两个Tab。恶意软件最省事的持久化方式就是往当前用户启动文件夹里丢一个文件，或者写一条Run注册表键。击键记录器、剪贴板窃取器都爱这么干，因为用户一登录就自动跑，重启也杀不死。排查时先按“按名称排序”，看到某个启动项路径在临时目录或用户目录下，就值得多看两眼。

计划任务Tab经常被人忽略，实际上攻击者现在越来越喜欢用计划任务做持久化，因为它可以指定在特定时间触发、以高权限运行，而且在默认资源管理器里不如启动项显眼。看的时候重点看任务名称、要执行的命令、触发条件、运行账户是不是常规项。如果看到一个名字很像系统更新、路径却指向AppData下的奇怪目录，基本可以确定有问题。

服务与驱动Tab是更底层的入口。普通恶意软件写服务是为了开机自启，更高级的则会加载内核驱动。排查驱动时一定要结合签名一起看，因为历史上不少深度攻击都靠着伪装成知名驱动厂商的证书落地。Autoruns能在这里直接显示驱动文件的签名状态，可以省掉不少来回验证的时间。

3.2 用“签名+镜像路径”快速过滤

从13.98这个版本开始，我把自己的排查流程固定成两步。

第一步是勾选“隐藏已签名的Microsoft条目”，这一步能瞬间过滤掉大量系统自带启动项。注意不要直接勾选“隐藏所有已签名条目”，因为很多第三方软件也带有效签名，全隐藏容易把白名单里的异常项一起盖住。先只过滤系统签名，人工过一遍剩余项，再决定要不要继续过滤第三方签名。

第二步是看“路径”列。合法软件通常从Program Files、Windows目录、系统服务目录启动；不合法软件则偏爱%Temp%、%AppData%\Roaming、C:\Users\Public、回收站这种冷门位置。路径一旦出现在这些区域，就算签名看着正常，也要单独拎出来跑一趟杀毒引擎。

实际操作里Autoruns还内置了一个“隐藏空条目”按钮，强烈建议打开。它可以把指向不存在文件或已删除注册表项的残留启动项隐藏掉，界面清爽很多。很多朋友第一次用Autoruns吓一跳，觉得开机启动项有几百条，其实真正活跃的只有几十条，剩下的都是孤儿项。

3.3 用快照diff找变化

排查正常机器时，启动项往往都是可信的，谁都能一眼看出异常的是少数。所以更高阶的用法是做“快照diff”：先在系统干净时用Autoruns.exe -accepteula -a -m -c > base.csv导出基线，等系统表现异常后再导出一次：

Autoruns.exe -accepteula -a -m -c > after.csv

把两个CSV丢到任意文本对比工具里，新增条目的价值立刻凸显。这个做法在取证里几乎每次都能快速定位“最近出现了什么新启动项”。注意输出格式里默认会把启动项所属位置、执行命令、签名状态都带上，对比时间不要拖太长，否则当天正常软件更新也会产生大量噪音。

快照diff有个容易被忽略的坑：Autoruns默认只扫描当前用户和系统全局的启动点，如果恶意软件藏在其他用户账户的启动文件夹里，普通运行看不出来。建议用管理员权限执行，并在命令行里确认扫描范围覆盖所有用户配置。

4. 实操：Sigcheck 2.8 签名与哈希批量审计

4.1 单个文件的数字签名查看

Sigcheck最直接的用途是查看单个文件的签名信息。命令形式很简单：

sigcheck.exe -accepteula -m C:\path\to\file.exe

输出会列出文件版本、公司名、签名状态、签名者、证书有效期等信息。相比资源管理器里“右键-属性-数字签名”的查看方式，Sigcheck能给出更完整的链信息，还能把签名状态标成“已签名”、“已过期”、“无法验证”等几种明确结果。排查可疑文件时，先看“签名者”是否对得上文件声称的身份来源，再看“证书时间戳”是否落在可疑区间，最后用-h参数打印文件的SHA256，去威胁情报平台比对。

很多朋友会只看“已签名”就放松警惕，这是我在实际排查中反复纠正的习惯。签了名不代表安全，证书可能是被盗用的，也可能是攻击者自己注册的公司证书。尤其当签名者是一个陌生公司名、文件路径又在临时目录时，签名反而会成为掩饰工具。Sigcheck输出里还会标注“签名验证”为“有效”还是“无效”，无效签名未必恶意，但至少说明文件被改动过或者证书链不完整。

4.2 批量脚本化审计

单文件查看适合点状排查，面对一个目录或一台机器的大量文件时就需要批量跑。Sigcheck支持通配符递归扫描：

sigcheck.exe -accepteula -s -c -h C:\Windows\Temp\*.exe > result.csv

-s表示递归子目录，-c表示CSV输出，-h附带哈希值。生成的结果可以直接用Excel或脚本过滤出“未签名”、“签名无效”、“哈希值重复”的可疑项。

我常用的一个加强版做法是把它接到Autoruns后面用。先让Autoruns导出启动项路径列表，再用一个循环把列表里的每个exe、dll都交给Sigcheck做签名与哈希校验，最后统一和已知白名单比对。这个链路看着原始，但在没有商业化情报工具的情况下，能解决80%的“这玩意儿到底是谁家的”疑问。

for /f "delims=" %i in (startup_paths.txt) do sigcheck.exe -accepteula -c -h "%i" >> audit.csv

注意CSV模式下有些字段含逗号会破坏列对齐，建议输出后用工具转成TSV再看；同时在批处理里加入-nobanner参数能让输出更干净。

4.3 配合MOTW的Zone参数

Sigcheck 2.8让我觉得最实用的一点，是它对Zone信息（也就是MOTW）的支持。新版本里可以用-z参数查看文件是否带互联网区域标记：

sigcheck.exe -accepteula -z C:\Downloads\sample.exe

输出里如果出现Zone : Internet或类似字段，说明这个文件被系统判定为来自互联网。这个信息在事件响应中非常关键：如果在一台内网服务器上发现一个带MOTW的可执行文件，几乎可以断定有人在服务器上访问过外部资源，排查范围会瞬间缩小。

把这个参数和大批量扫描组合起来，能更直观地回答“哪些落盘文件来自外部”。例如审计整个用户下载目录：

sigcheck.exe -accepteula -s -z C:\Users\*\Downloads\* > zone_result.csv

再按Zone字段排序，外部来源文件一眼可见。值得注意的是，MOTW不是不可删除的，攻击者完全可以用脚本手工清理Zone.Identifier数据流，所以Zone信息的“有”是强证据，“无”不能当作否定依据。后者需要通过Sysmon历史事件的时间线来补充判断。

5. 实操：Sysmon 11.10 部署与 MOTW 链路还原

5.1 最小化部署配置

Sysmon部署方式一直是“一把配置走天下”，但我不建议直接套用网上动辄上千行的大全规则。监控规则越多，日志量越大，最终淹没真正有价值的事件。我在生产环境里用的是一套精简配置，只保留核心事件：进程创建（事件ID 1）、进程终止（5）、网络连接（3）、文件创建（11）、文件流创建（15）、驱动加载（6）、注册表改动（12、13、14）。

对应的最小配置片段大概是这样的思路：

<Sysmon schemaversion="4.50"> <EventFiltering> <ProcessCreate onmatch="exclude"> <!-- 排除正常的系统进程，减少日志量 --> </ProcessCreate> <FileCreate onmatch="exclude"/> <FileCreateStreamHash onmatch="include"> <StreamName condition="is">Zone.Identifier</StreamName> </FileCreateStreamHash> </EventFiltering> </Sysmon>

部署命令直接用管理员权限执行：

sysmon.exe -accepteula -i sysmon-config.xml

重点在于FileCreateStreamHash这个事件的过滤条件，我一般只保留StreamName等于Zone.Identifier的规则，这样既不会漏掉MOTW痕迹，又不至于把每个临时文件的数据流都记录下来。如果当前Sysmon版本不支持文件流事件，至少要保留FileCreate和ProcessCreate，后续用时间线分析来补足MOTW的推理链路。

5.2 关注哪几个事件ID

MOTW链路还原不是靠单条事件完成的，而是靠多条事件的“时间咬合”。我通常把下面几个事件ID作为核心：

一次典型的下载执行过程，在Sysmon里应当能拼出这样的时间线：浏览器进程发起网络连接得到响应，随后某个文件在Downloads目录被创建，同一条ADS流产生Zone.Identifier事件，接着该文件以进程形式启动。如果这五类事件的时间间隔在几十秒以内，那么“下载→执行”的关联度就很高。

5.3 一条完整线索的推导示例

假设领导给你一台机器，说内部监控报了异常外连，让你判断样本源头。你打开Sysmon日志，先查目标外连IP的时间点，得到进程名和PID。再按PID反查进程创建事件，发现父进程是wscript.exe，而wscript.exe的父进程又是来自Downloads目录下的某个JS文件。

现在去查这个JS文件的文件创建事件，时间显示为当天上午。同一条文件创建记录的附近如果存在FileCreateStreamHash事件，且流名是Zone.Identifier，你就拿到了关键证据：这个文件是从互联网下载的。再往回追网络连接事件，能看到浏览器在文件落地前访问过某个外部域名，域名和文件内容一对，钓鱼来源就找到了。

如果Sysmon没有记录Zone.Identifier，也不要灰心。你还可以用文件的创建时间戳去和浏览器历史、下载文件夹里的其他残留文件做交叉印证；甚至直接看文件属性里有没有MOTW的残留字符串。证据链不完整时，宁可多查一层，也不要急着下结论。实际工作中我吃过一次亏，因为只看到文件创建事件就断言是U盘拷贝，结果忽略了下载记录，后来才发现是邮件附件落地，方向性错误浪费了一天时间。

6. 常见问题与排查技巧实录

6.1 Autoruns 启动项显示“未验证”怎么办

接到问题“Autoruns显示某个启动项签名未验证，是不是中毒了”的次数非常多。首先要明白“未验证”不等于“恶意”，它代表系统无法用当前信任根验证该文件的签名链。常见原因有三个：文件被加壳或修改、证书链断裂、文件本身是旧版驱动且证书已过期。

处理方式是先用Sigcheck单独查一遍签名，看看证书详细信息，再用哈希去在线查一下知名度。如果哈希完全陌生、路径在用户目录、文件名还是随机字符，那基本可以直接拉黑；如果是一个正规软件的老版本，结合公司名和文件版本往往能确认清白。我习惯了把Autoruns和Sigcheck一起打开，左侧看启动项位置，右侧查签名，效率远高于来回切换界面。

6.2 Sigcheck 命令行参数记不住怎么办

Sigcheck的参数不算多，但第一次用的人常被-a -c -h -s -z搞晕。我自己的记忆方法很简单：-c表示输出成表格（CSV），-s表示往下钻（递归子目录），-h表示顺便打印哈希，-z表示看Internet区域标记，-a表示把扩展属性也带出来。真正需要背的其实就是-c -h -s这组审计组合。

遇到不确定的参数，直接执行sigcheck.exe -?看帮助即可，帮助信息里每个参数都有说明。另外，命令默认会接受EULA弹窗，写脚本时一定要加-accepteula，否则脚本会在第一次运行时卡住。这是我见过的自动化采集脚本最常犯的错。

6.3 Sysmon事件流缺少Zone字段时怎么排查

排查MOTW最怕遇到“明明下载了文件，Sysmon却没有Zone.Identifier事件”。先确认不是版本问题，再按下列顺序查：

1. 检查配置文件是否包含了对应事件ID，并确认过滤条件没有误伤。
2. 检查事件日志里是否有文件创建事件，只有文件真的在监控目录下创建才会有后续。
3. 检查浏览器下载目录是否在Sysmon监控范围内，有些配置会把用户目录排除掉。
4. 确认文件下载是不是发生在Sysmon启动之前，事件日志不会追溯旧文件。

最后这条最容易被忽视。假设Sysmon是今天装的，你却在查昨天的样本来源，那日志里本来就什么都不会有。这种情况下只能去翻浏览器历史、HTTP代理日志、NTFS的ADS残留来做事后推断。Sysmon给的是实时记录能力，不是历史回溯能力，理解了这个边界，排查思路才不会跑偏。

6.4 MOTW在压缩包和U盘场景会失效

还有一个实操细节值得单独提醒：MOTW不是永远跟着文件走的。如果你把一个带MOTW的exe打包进zip再解压，解压出来的文件往往不再带Zone.Identifier；如果通过U盘从外部拷入文件，也不会有互联网区域标记。某些攻击者就是利用这一点，让样本“洗”掉MOTW，让取证人员无法直接判断来源。

遇到这种情况，我的处理思路是不要只盯着Zone.Identifier这一条路，而是去追文件的创建时间、修改时间、最近访问时间，以及文件在目录中的出现顺序。如果某个内网目录里突然多出一批时间落点集中的新文件，又没有一个正常的软件安装行为与之对应，那就要考虑是从U盘或内部共享导入的，排查物理接触来源比追网络记录更有效。

6.5 三件套组合使用的最终建议

把这套更新和个人长期使用的经验放到一起说，给你一个可以直接抄的作业顺序：日常在关键终端部署Sysmon，用前面说的最小化配置记录进程和文件流；每隔一段时间用Autoruns导出一次启动项基线保存归档；遇到可疑文件就交给Sigcheck把签名、哈希、Zone信息一次性查完，然后回到Sysmon日志里做时间线关联。

这套流程不需要复杂平台，也不需要付费工具，只要三个命令窗口就能跑起来。真正难的不是敲命令，而是理解每一项输出的含义，以及知道哪种情况会被数据误导。比如MOTW缺失不能证明文件安全，签名有效不能证明文件可信，启动项数量变多也不等于入侵发生。这些边界想清楚了，版本号升级才真正转化成了排查能力。

最后分享一个我在实际使用里养成的小习惯：每次Sysinternals出新版本，我都会把旧工具替换成新版本，并顺手在干净的虚拟机上重放一遍常用命令的完整流程。这样既能熟悉新版输出的微小变化，也能确保应急响应时用的工具和命令都是顺手的那一套。工具不在多，关键是在紧急时刻拿起来就能用。