2020年6月中旬Sysinternals 照例挂出了一批工具更新。我像往常一样逐个点开 changelog前两个——Autoruns 13.98、Sigcheck 2.8——属于“稳定迭代”的范畴看完就顺手划过去了。真正让我停下来的是 Sysmon 11.10它把 Mark of the WebMOTW正式收进了事件日志字段。对做应急响应和威胁狩猎的人来说这个消息的分量不亚于手里多了一类新的高价值取证指标。这篇速记先把三个工具的版本变化说清楚再把 Sysmon 11.10 新增的 MOTW 采集原理、字段语义和复现过程完整拆开最后给一套“Autoruns Sigcheck Sysmon”组合排查外部投放文件的实战思路。适合安全运营、终端取证、恶意文件分析的同学参考系统管理员如果关心自启动排查和文件校验也能从中挑到有用的部分。1. 这一轮版本更新到底动了什么1.1 Autoruns 13.98老牌启动项工具又补了哪些洞Autoruns 是我电脑里的常驻工具排查自启动、找持久化、看服务驱动基本都靠它。这次更新到 13.98表面上没有翻天覆地的变化但几个细节值得关注。第一对 Windows 10 最新版本当时是 2004 版的启动位置枚举做了兼容修正。这类修正通常不值得单独写文章但实际用起来很有感旧版本在部分新系统上会出现启动项漏报或读取失败尤其是把注册表项和计划任务交叉枚举时偶尔会读到半截数据。更新到 13.98 之后这类问题明显少了。第二Autoruns 对计划任务的解析一直在完善。你可能觉得计划任务不就是看文件夹吗实际上系统里存在大量隐蔽的计划任务注册位置攻击者也越来越爱用计划任务做持久化。新版本在这方面的枚举更完整一些被刻意隐藏的任务也能显形。我在排查内网机器时经常先打开 Autoruns 的“计划任务”页签按修改时间排序把最近三五天的任务拉到一起看效果比在任务计划程序里翻要好得多。第三VirusTotal 集成的交互更顺了。具体到 Autoruns它会把检测到的启动项哈希提交给 VirusTotal 做在线匹配。13.98 在结果展示上更直观命中与否一眼能看清。需要提醒的是Autoruns 默认提交的是文件哈希而不是整个文件隐私压力没那么大但如果你的网络环境不允许访问外网这个功能会自动失败别把它当成离线杀毒来用。实际使用中我一般会配合三个操作开启 “Hide Microsoft Entries” 隐藏微软签名项在 Options 里把 “Scan Options” 勾上 VirusTotal然后把结果另存为 CSV 归档。这样既能看到非微软启动项也能在排查后留下快照。别直接在 Autoruns 里“删除”启动项——它没有删除而是从注册表中移除对应值这种破坏性操作必须先导出备份再做。1.2 Sigcheck 2.8从单文件校验到批量提交的跨越Sigcheck 是我做“文件体检”时必用的命令行工具功能就两句话读 PE 文件的版本信息、验证数字签名顺带算哈希。2.8 这次更新最实用的点在于标准输入支持——它可以把一个文件清单通过管道喂给 VirusTotal 批量查询接口。在 2.8 之前想对一批文件做 VirusTotal 哈希匹配常见做法是循环调用或者借助外部脚本拼请求。现在可以直接这样用dir /s /b C:\Users\Public\*.exe | sigcheck64.exe -nobanner -v或者用 PowerShell 把文件名传入Get-ChildItem C:\Users\Public -Recurse -Include *.exe,*.dll | Select-Object -ExpandProperty FullName | sigcheck64.exe -nobanner -v新版 Sigcheck 拿到文件清单后会逐个计算哈希并向 VirusTotal 查询。这里的关键点在于查询结果是“文件名路径VirusTotal 报告链接厂商检测计数”的结构化文本一眼就能看出哪些文件被多个安全引擎标记。对应急场景来说批量验签、批量查哈希效率提升非常明显。另外Sigcheck 的-c参数配合-s递归目录可以输出 CSV 表格方便后续导入 Excel 或者在数据透视表里继续处理。我习惯把所有可疑目录跑一遍把结果存成带时间戳的 csv再和 Sysmon 日志里的哈希字段对齐。写到这里顺便说一句Sigcheck 的作用只是验证和查询它自己不会把恶意软件清除看到坏签名或高匹配率后下一步该是隔离文件、断网、留证。1.3 Sysmon 11.10MOTW 入场日志字段从此不同Sysmon 11.10 是这一轮更新的重头戏。它的核心变化是在文件创建事件里引入了 Mark of the Web 信息。事件 ID 11FileCreate现在有机会带出一个新字段ZoneIdentifier取值从 0 到 4。看到这个字段非 0基本可以断定你正在看的是一个“从外部区域进入系统”的文件。为什么这个字段重要因为在 Windows 的文件系统里“我从哪来”本来不是文件本身自带的问题。同一个路径下的一串字节可能是用户本地创建的也可能来自浏览器下载、邮件附件解压、U盘拷贝。传统上这些来源信息散落在不同地方取证时要拼很多线索才能还原。Sysmon 11.10 把其中一个最重要的来源信号——互联网标记——直接塞进了日志流让安全分析和恶意文件追踪多了个确定性很强的锚点。这里要泼一盆冷水Sysmon 11.10 不是“平白无故多一个字段”这么简单。事件 ID 11 需要你在 Sysmon 配置里显式启用否则默认什么文件创建记录都不会有。而且不是所有文件都会带 MOTW这个字段只有在文件真正被 Windows 打了互联网标记后才会出现。我把它的原理和判断逻辑放在下一节细讲。2. 把 Mark of the Web 讲透Windows 给“互联网文件”盖的章2.1 MOTW 到底存在哪里Zone.Identifier 备用数据流Mark of the Web 的中文常译成“互联网标记”它并不是文件内容里的一个字节而是挂在 NTFS 文件系统上的一个备用数据流Alternate Data Stream简称 ADS。大多数人知道 ADS 是因为它历史上常被用来隐藏恶意代码但从系统设计角度讲ADS 就是文件的“隐形口袋”专门存放不进入主数据流的元信息。当你用浏览器从互联网下载一个文件时下载器会在文件上自动生成一个名为 Zone.Identifier 的备用数据流里面是一个 INI 格式的文本块。用文本方式查看的话内容大致是这样[ZoneTransfer] ZoneId3 ReferrerUrlhttps://example.com/malware/doc.exe这段信息就是 MOTW。Windows 后续判断是否弹出 SmartScreen、是否以“受保护视图”打开 Office 文档、IE/Edge 是否按低权限处理文件都会先读这个 Zone.Identifier 数据流。对安全从业者而言它的价值在于MOTW 是 Windows 自己对“文件来源区域”的官方记录权威性比单靠文件名和路径推断来源高很多。查看 ADS 的手段不少。命令行下dir /r能看到备用数据流列表PowerShell 里可以用Get-Item -Stream *查看。我常用的快速检查命令是Get-Content -Path C:\Users\Public\test.exe -Stream Zone.Identifier如果文件没有 MOTW这一步会直接报“找不到路径”如果存在则会输出 ZoneId 和可能的 ReferrerUrl。需要注意的是NTFS 才完整支持 ADSFAT32、exFAT 或某些网络共享上这套机制会失效Sysmon 的 MOTW 采集同样依赖本地磁盘是 NTFS。2.2 区域 ID 到底代表什么MOTW 里的 ZoneId 是一个整数指向 Windows 的“安全区域”模型。这个模型继承了 Internet Explorer 时代的分区逻辑到今天依然是 Windows 判断文件信任等级的重要依据。对应关系如下ZoneId 值区域名称含义典型来源0本地计算机 (My Computer)完全可信不视为外部来源本地创建、本地复制1本地 Intranet (Local Intranet)内网范围中等信任内网共享、域内站点下载2受信任站点 (Trusted Sites)用户明确信任加入信任列表的站点3Internet (Internet)互联网范围低信任浏览器直接下载4受限站点 (Restricted Sites)明确限制接近不信任受限站点列表、特定邮件附件来源实际恶意文件分析中ZoneId3 最常见浏览器直接下载的文件都会落在这里。ZoneId4 通常出现在极可信/极不可信的边缘场景比较少见。ZoneId1 是内网下载才会看到但内网共享路径在不同 Windows 配置下不一定会打 MOTW具体行为取决于组策略和客户端配置。很多人会忽略一个细节MOTW 不是“永远存在”的。把文件从浏览器下载目录复制到另一个目录ADS 通常跟着走但如果文件经过压缩包再解压而解压工具本身不保留 ADS或者文件被传到 Linux/Mac 再转回来MOTW 很容易丢失。所以 MOTW 存在是一个强信号MOTW 缺失却不能直接证明文件就是本地生成的只能说明“没有证据指向外部来源”。2.3 为什么安全运营一直忽略了 MOTW做威胁狩猎的人嘴上常挂“文件从哪里来”这句话但真到了日志层面历史上能回答这个问题的字段并不多。EDR 能看到进程链、父进程、命令行能看到文件写入位置但这些都不能直接告诉我们“这个文件是不是用户从互联网下载的”。Sysmon 12 之前的版本也没法直接记录 MOTW。MOTW 一直存在也一直能用 PowerShell 或取证工具提取但问题在于它藏在 NTFS 的备用数据流里正常业务根本不看它SIEM 平台也无法从终端日志里自动拿到这个值。想基于 MOTW 做全网排查只能逐个端点跑脚本采集 ADS既慢又容易漏不适用于日常监控。Sysmon 11.10 的真正价值就是把 MOTW 从“需要专门取证才能看到的现场痕迹”变成了“常规日志里的结构化字段”。只要终端装了 Sysmon 11.10、开启了文件创建事件采集任何一个带互联网标记的文件落盘瞬间安全团队就能在 SIEM 里直接筛选ZoneIdentifier3。这是从“被动取证”到“主动狩猎”的一步大跨越。3. 动手实践自己搭环境复现 Sysmon 11.10 的 MOTW 捕获3.1 环境准备与 Sysmon 安装复现 MOTW 捕获不需要复杂环境一台装了 Windows 10 的虚拟机就够了。我用的是一台全新的 Windows 10 2004 虚拟机建议在快照状态下操作省得 Sysmon 配置不对时反复折腾系统。先到 Sysinternals 官网下载 Sysmon 压缩包解压后确认里面有 Sysmon64.exe 和对应的配置文件模板。安装需要管理员权限普通权限会被拒绝。在管理员 PowerShell 里执行.\Sysmon64.exe -accepteula -i sysmon-config.xml-accepteula接受许可协议-i指定安装并加载配置。如果不想加载任何配置只执行.\Sysmon64.exe -accepteula也可以装上但默认事件规则可能不会采集文件创建所以有一个配置是必须的。装完之后可以确认服务状态Get-Service Sysmon64 Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational看到服务处于 Running、日志存在于“应用程序和服务日志”下就说明安装成功。Sysmon 的模式是“驱动采集事件写入系统事件日志”它不依赖前端 UI也没有图形界面日常验证全靠事件日志。如果之后想改配置用-c更新比如.\Sysmon64.exe -c sysmon-config.xml这个命令在生产环境也很常用不需要重装服务就能热更新规则。3.2 一份可用的 Sysmon 配置XMLSysmon 从 11.10 开始对配置里的 schemaversion 要求比较严版本不匹配会直接拒绝加载。下面这份配置里我写了 4.30实际操作时如果你发现加载报错先看报错提示里的正确版本号改掉再加载。Sysmon schemaversion4.30 EventFiltering RuleGroup namecapture-file-create groupRelationor FileCreate onmatchinclude/ FileCreateStreamHash onmatchinclude/ /RuleGroup /EventFiltering /Sysmon这段配置的核心是打开了两类事件FileCreate对应事件 ID 11记录文件创建FileCreateStreamHash对应事件 ID 15记录备用数据流的哈希。两个都设成onmatchinclude加空条件意思是“所有此类事件都记录”。实际生产里你肯定不会这么放养要按目录、扩展名、进程路径圈定范围但实验环境下先求全。配置的语义要理解清楚Sysmon 的include和exclude是过滤两个方向。include是“只记录匹配的”exclude是“记录除了匹配之外的”。如果同一条规则里既有 include 又有 excludeexclude 优先。这次实验把空 include 写成全量采集就是为了确保 MOTW 字段能出现在事件里。3.3 制造一个带 MOTW 的文件并查看日志安装好 Sysmon 后下一步是制造一个带 MOTW 的文件。最自然的方式是用浏览器下载一个文件但虚拟机里反复访问外网下载比较麻烦我推荐两种方式一种是用 Windows 10 自带的 curl 直接下载curl 会按浏览器规则给文件打 MOTW另一种是手工注入 Zone.Identifier 数据流适合模拟场景时用。先用 curl 方式curl.exe -L -o C:\Users\Public\testfile.exe https://example.com/sample.exe只要远程服务器正常返回文件curl 就会在写入文件时把 ZoneId3 附上。如果测试环境没外网改用 PowerShell 手工模拟Set-Content -Path C:\Users\Public\testfile.exe -Stream Zone.Identifier -Value ([ZoneTransfer],ZoneId3)这两条命令得到的文件从内容上看可能完全不同但 ADS 里的 MOTW 是等价的两者都能让 Windows 安全功能把它当互联网文件对待。文件落盘之后Sysmon 的 Event ID 11 应该已经记录了这次创建。我们直接在事件日志里翻Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id11} -MaxEvents 5 | ForEach-Object { [xml]$xml $_.ToXml() $data $xml.Event.EventData.Data $props {} foreach ($d in $data) { $props[$d.Name] $d.#text } [pscustomobject]{ Time $_.TimeCreated Image $props.Image TargetFilename $props.TargetFilename User $props.User ZoneIdentifier $props.ZoneIdentifier } } | Format-Table -AutoSize如果一切正常输出里会多出一列 ZoneIdentifier显示为 3。这是 11.10 最显眼的升级结果以前需要额外去查 ADS 才能拿到的来源标记现在直接出现在主事件日志里。验证完之后用Get-Content -Stream Zone.Identifier回头确认一下 ADS 内容两边对照Get-Content -Path C:\Users\Public\testfile.exe -Stream Zone.IdentifierCommand 输出会显示 ZoneTransfer 和 ZoneId3。事件日志与 ADS 字段互相印证这套实验就算闭环了。3.4 用 PowerShell / 事件查看器快速验证如果不想写脚本事件查看器也能快速定位展开“应用程序和服务日志 - Microsoft - Windows - Sysmon - Operational”在右侧筛选当前日志事件 ID 填 11找到最近一条和你的测试文件对应的记录切到“详细信息”选项卡看 XML。事件 XML 里ZoneIdentifier 字段通常长这样EventData Data NameUtcTime2020-06-18 10:33:22.518/Data Data NameTargetFilenameC:\Users\Public\testfile.exe/Data Data NameZoneIdentifier3/Data /EventData事件查看器默认显示的日志是单行文本MOTW 字段不一定在最显眼的地方但 XML 视图一定不会漏。实战中我习惯直接把 XML 复制出来喂给脚本批量解析字段。到这里Sysmon 11.10 的 MOTW 捕获机制已经跑通了。下一节把 Autoruns、Sigcheck、Sysmon 三者串联起来做一次模拟排查看看这套组合拳如何应对一个真实的“外部投放文件”场景。4. 组合拳Autoruns Sigcheck Sysmon 排查“互联网投放文件”4.1 场景一条来自终端的告警假设某天内网一台 HR 办公终端发出告警某个进程正在连接多个外部 IP行为特征与已知下载器相似。终端用户反馈自己只是在邮箱里收到一封“工资调整通知”的邮件点开附件后没看到任何文档内容。这个场景在真实应急里太常见了。接到告警的瞬间标准化流程就应该是先搞清楚文件怎么来的、做了什么、留了什么。三个工具各有分工Sysmon 回答“文件来源和落盘过程”Sigcheck 回答“文件可信度和外部识别情况”Autoruns 回答“系统里有没有被种下持久化”。顺序上我永远先看 Sysmon 日志再看 Sigcheck最后上 Autoruns。4.2 第一步用 Sysmon 日志还原文件来源登录到问题终端打开管理员 PowerShell按时间定位Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id11; StartTime2020-06-18 09:00:00} | Where-Object { $_.Message -match Users.*Downloads|Users.*Temp|Users.*AppData }这段命令把当天上午所有文件创建事件翻出来筛选用户目录下的下载或临时目录。重点看两条线索一是TargetFilename指向的位置二是事件里有没有ZoneIdentifier。只要看到ZoneIdentifier3这条文件创建事件就基本锁定了“文件来自互联网区域”。下一步看进程链配合 Event ID 1进程创建把前因后果串起来可能是浏览器进程创建了下载文件也可能是 Office 宏进程释放了 payload。Sysmon 11.10 的 Image 字段、ParentImage 字段、CommandLine 字段都会在这里拔刀相助。把这几条日志按时间排序一条“谁下载、谁释放、谁执行”的链条就浮出来了。4.3 第二步用 Sigcheck 验证签名和查 VirusTotal文件来源锁定之后把可疑文件复制到干净的分析目录先用 Sigcheck 看签名sigcheck64.exe -nobanner -accepteula C:\Users\Public\testfile.exe输出会告诉你 PE 文件的签名状态、发布者名称、是否有篡改。如果签名是有效的、来自知名厂商那大概率不是从互联网误下的恶意文件如果签名缺失、签名无效或证书异常恶意概率骤增。这一步在应急里能过滤掉很多误报。签名有问题的文件再批量丢给 VirusTotal 查哈希sigcheck64.exe -nobanner -v C:\Users\Public\testfile.exeSigcheck 2.8 会先算哈希再向 VirusTotal 提交查询结果会显示检测引擎数量和具体报告链接。如果检测计数高尤其是排名靠前的引擎都命名同一个家族那这个文件基本可以定性了。注意 Sigcheck 查的是哈希不是上传整个文件所以对没公开过的样本检测不到不代表样本干净只能说“不在公开知识库里”。4.4 第三步用 Autoruns 检查持久化来源和属性都清晰了还差最后一步系统里有没有留下自启动痕迹。打开 Autoruns选择“Options - Hide Microsoft Entries”隐藏微软签名项后整个启动项列表会瘦身很多。再按“Last Modified”时间排序把最近几小时新增的项目列出来看。重点检查高价值位置HKLM\Software\Microsoft\Windows\CurrentVersion\Run、启动文件夹、计划任务、服务、驱动和 WMI 事件订阅。攻击者为了代码能在重启后再跑起来通常会选其中一个或多个位置插入。Autoruns 13.98 对计划任务页签和服务的枚举比较完整耐心翻一遍基本都能发现异常项。如果发现有可疑启动项右键选择“Jump”直接定位到注册表或文件路径然后导出当前 Autoruns 快照存档。取证阶段别急着清理先把快照、原始注册表导出、Sysmon 日志全部归档再离线处理恶意项。处置时优先“禁用”而非“删除”给后续分析留后路。5. 落地过程中常见的坑与解决思路5.1 Sysmon 日志中看不到 ZoneIdentifier实验和实战里最常见的困惑就是“文件明明从网上下载了怎么事件里没有 ZoneIdentifier”。先按这几个方向排查第一Sysmon 版本是不是 11.10 及以上老版本根本没有这个字段第二配置文件是否启用了 Event ID 11很多人的 config 只开了 ProcessCreate文件创建事件根本没采集第三文件落盘位置是不是 NTFSFAT32/exFAT 存不下 ADS自然采集不到。另一个隐蔽原因是下载方式。不同程序写入文件时的 MOTW 行为不一致早期版本的 PowerShellInvoke-WebRequest、第三方下载器、FTP 客户端都可能不写 Zone.Identifier。MOTW 缺失不能说明文件是本地创建只能说明来源标记不存在需要注意这个灰色地带。验证方法也很简单在有问题的主机上手动下载一个文件然后用Get-Content -Stream Zone.Identifier检查 ADS 是否存在。如果 ADS 存在但 Sysmon 没记录问题就在配置或版本如果 ADS 本身就没有说明下载器没打标记不是 Sysmon 的锅。5.2 Sigcheck 批量 VT 查询遇到限速Sigcheck 2.8 的批量查询虽然爽但 VirusTotal 免费接口有请求配额。大批量跑目录的时候非常容易遇到VirusTotal rate limit exceeded之类的提示。我的经验是别把几千个文件一次性灌进去先按目录或文件类型拆批每批控制在几十个文件以内跑完一批停一会儿再跑下一批。另外查询结果不是即时的某些哈希在 VirusTotal 上可能没有缓存API 会返回“未查询到结果”。这种情况可以配合-vr参数打开对应报告页面人工复核或者稍后再查一次。还有一点很重要Sigcheck 的 VirusTotal 特性走的是外网接口如果环境不能出外网它只会空跑不报错。在隔离网段排查时建议先把-v类功能搁置专注本地签名验证和哈希计算归档后回到互联网环境再补查。5.3 Autoruns 的 VT 提交与误报处理Autoruns 集成的 VirusTotal 检查和 Sigcheck 类似也会碰到外网不通和请求限制。我见过不少同事因为 Autoruns 显示“匹配到恶意软件”就直接判定系统被种马结果一查才知道是 VirusTotal 对正常工具家族的低置信度标记。Autoruns 的结果要结合文件路径、签名状态、修改时间一起看不能一刀切。处理误报的方法是右击可疑条目选择“Check VirusTotal”看详细检测引擎列表。如果只有一两个非主流引擎报毒而微软和主流安全引擎全部“未检测”大概率是误报。反过来如果主流引擎报的家族名称一致就要认真对待。Autoruns 的另一个坑是它默认读取的是“当前用户 本机所有用户”的启动项但一些服务态进程和内核态驱动信息需要管理员权限才能完整显示。每次排查前确认你是在管理员权限的会话里启动 Autoruns否则漏项问题会直接影响结论。5.4 日志量、权限和工具执行注意Sysmon 全量开启 FileCreate 后日志量增长很快。一台正常办公机上用户装软件、编译程序、浏览器写缓存每分钟都可能产生大量 Event ID 11不加过滤的“include 全部”配置只适合实验不适合生产。生产环境建议按目录白名单和进程白名单做排除保留关键目录的采集即可。MOTW 虽然很有价值但它只是 Sysmon 众多字段之一。实战中别把所有赌注押在 ZoneIdentifier 上把它和 Event ID 1进程创建、Event ID 3网络连接、Event ID 22DNS 查询组合起来看判断链会更完整。比如恶意文件从网络下载、随后发起外联、又写了启动项这条链在 Sysmon 日志里其实是连贯的。工具执行层面Autoruns、Sigcheck、Sysmon 都需要管理员权限普通用户跑不出完整结果。Sysmon 安装后如果没有配置更新规则会一直保持初始状态记得定期复查配置文件。另外官方工具在运行时占资源很小但在老旧的机器上跑 Autoruns 全量扫描还是会卡几秒别急着反复点给它一个缓冲时间。写在最后这套更新里Autoruns 13.98 和 Sigcheck 2.8 属于“用起来更顺手的常规迭代”真正值得写进笔记的是 Sysmon 11.10 带来的 MOTW 字段。以前我面对“这个文件到底哪来的”这个问题只能靠浏览器历史、下载记录这些间接证据拼凑现在事件日志里一行 ZoneIdentifier3直接给了答案。实际排查中这一个小字段往往能把几小时的研判压缩到几分钟。如果你想把这个玩法继续扩展建议把 Sysmon 日志接入 SIEM 或日志平台单独建一条规则Event ID 11 且 ZoneIdentifier 非 0再叠加 Office 文档、脚本文件等敏感后缀。这条规则对钓鱼邮件附件和浏览器下载投毒场景的覆盖面相当可观。我就是从这次更新开始把 MOTW 筛选固定进了日常威胁狩猎的查询模板里至今还在用它。