照着这份笔记补『容量估算』短板：从 QPS 公式到存储带宽手算
2026/10/10 12:04:08
Sysinternals套件又发布了一轮更新：Autoruns 13.98、Sigcheck 2.8、Sysmon 11.10。这三个名字在应急响应圈子里基本不用多介绍，Autoruns负责挖系统里的开机自启与持久化，Sigcheck负责验文件签名和哈希，Sysmon则是在系统事件层面盯进程、文件、网络行为的“眼线”。这轮更新最值得留意的，是Sysmon和Sigcheck都跟Mark of the Web（MOTW，文件互联网下载标记）沾上了关系——用得好，可以在样本溯源时快速判断恶意文件到底是从哪条路径进来的。
这篇文章不是抄官方changelog，而是从实际排查的角度把这轮更新的关键点过一遍。如果你平时做应急响应、威胁狩猎、样本分析，或者只管着一批Windows终端，这轮更新的玩法可以给你的日志监控和取证流程加一层线索。
1. 2020年6月更新全景：Autoruns、Sigcheck、Sysmon三剑客
1.1 这轮更新为什么值得单独记一笔
2020年6月，微软把Sysinternals套件里的几款常用工具集中刷新了一遍。这类工具通常不会搞大版本革命，但每次小版本都可能修复新版Windows下的兼容问题，或者增加对新威胁场景的支持。这次的核心关键词就是Mark of the Web——也就是Windows给“从网上下载的文件”打的隐性标记。
过去我们查文件来源，要么翻浏览器历史，要么看文件属性里的来源地址，要么干脆去终端上现场捞文件。现在MOTW被System 11.10和Sigcheck 2.8带进了结构化日志和命令行输出，等于把一个原本藏在NTFS流里、平时没人管的标记，变成了可查询、可告警、可串联攻击链的字段。
先说结论：这轮更新适合三类人——日常管Windows终端的安全运维、做应急响应时需要在现场快速定位问题的分析师、以及喜欢折腾日志监控和威胁狩猎的爱好者。版本号看着小，实际价值不小。
1.2 三个工具的分工与配合
把三个工具放在一张表里看，定位就很清晰了：
| 工具 | 核心作用 | 最常用场景 | 本次更新关注点 |
|---|---|---|---|
| Autoruns | 启动项、服务、计划任务等持久化点枚举 | 排查可疑自启动、分析恶意软件持久化 | 兼容性打磨，隐藏微软签名项后的排查体验更顺 |
| Sigcheck | 文件版本、签名、哈希、标记检查 | 批量核查可疑文件、应急响应现场快速取证 | 加入MOTW识别能力 |
| Sysmon | 内核级事件记录，覆盖进程、文件、网络、驱动等 | 威胁狩猎、攻击链还原、终端日志采集 | 在文件创建等事件中输出MOTW信息 |
三个工具配合起来是一条完整的逻辑链：Sysmon先发现一个带MOTW标记的文件落地，Autoruns再看它有没有写自启动，Sigcheck批量验证同批文件是不是都来自网络下载。这套组合相当于从“事件日志、文件系统、启动项”三个维度把一台主机盘明白，比单独看任意一个工具都高效。
2. Autoruns 13.98上手速记：3分钟揪出启动项里的可疑项
2.1 13.98这版更新了个啥
Autoruns本身已经非常成熟，13.98这版没有大刀阔斧的新功能，主要动作集中在兼容性和稳定性上。实测下来最直观的感受是：在较新的Windows 10版本上，隐藏微软签名项之后界面清爽了很多，分类也更符合实际排查路径。
为什么这种“小打小闹”也要升级？因为Autoruns的核心价值在于它枚举启动项的覆盖面。新系统、新软件会在注册表和文件系统里增加新的启动位置，老版本的Autoruns可能压根看不到这些位置。如果你还在用一年前的版本，很可能在排查时漏掉重要线索。
升级之后，日常排查的体验没有明显变化——这是好事。这类工具最怕的就是升级后行为大变，导致你原有的判断经验全部失效。13.98属于那种“你几乎感觉不到它变了，但它就是更稳了”的版本。
2.2 3分钟排查可疑自启动的标准姿势
我每次拿到一台需要排查的机器，Autoruns的操作流程基本固定，按这套顺序走基本不会漏：
- 右键以管理员身份运行Autoruns，第一次运行会弹许可协议，接受后工具会自动枚举所有启动点。
- 打开Options菜单，勾选“Hide Microsoft Entries”。这一步把大量签名正常的微软自带项隐藏掉，列表立刻清爽。
- 眼睛重点扫描这几个分类：Run、RunOnce、启动文件夹、计划任务、服务、驱动程序。恶意软件最喜欢在这些地方写持久化。
- 看到可疑项，右键选“Jump to...”，直接定位到对应的注册表位置或文件路径，确认是不是恶意。
- 拿不准就右键“Search Online”，用文件名、路径或哈希去搜威胁情报。
这里有个关键提醒：隐藏微软签名项并不是万无一失。恶意软件越来越会伪装，有些直接伪造或冒用合法签名，有些把DLL注入白名单进程，有些在计划任务里写得非常隐蔽。我遇到过不止一次，真正的恶意项就藏在看起来正常的Microsoft条目旁边，靠隐藏微软项是筛不出来的。
所以更实用的技巧是看组合特征：没有有效数字签名、路径在C:\Users\用户名\AppData\Temp或Roaming下、文件名带着一串随机字符——这三条命中两条，基本就可以高度怀疑了。
2.3 远程机器上的Autoruns排查
现场排查是一回事，更多时候是几十台机器同时出问题，不可能一台台登录过去点界面。这时候可以把Autoruns临时拷到目标机器上跑一次，输出结果文件拿回来分析。
我习惯的做法是用PsExec远程执行，结合Sysinternals自家的工具链。命令行参数记不准没关系，先跑Autoruns.exe /?看帮助，核心思路就两个：加/accepteula参数让它静默接受许可协议不弹窗，然后让输出结果重定向到文本或CSV文件。
拿到输出文件后，拿来跟已知干净的机器做diff对比，差异项就是重点排查对象。这个“基线对比”的做法，比在一堆启动项里翻来翻去高效得多。尤其是批量排查的时候，diff一次能筛掉90%的噪音。
3. Sigcheck 2.8实战技巧：签名核查与MOTW批量过滤
3.1 2.8版本的变化
Sigcheck是一个不起眼但非常能打的小工具。它的核心能力就三件事：看文件版本信息、验证数字签名、计算文件哈希。2.8版本这轮更新，除了对证书吊销状态检查做了增强，更重要的是加入了MOTW识别能力。
这意味着什么？以前你想知道一个文件是不是从网上下载的，得右键看属性、点开“解除锁定”的那个区域，或者用命令行手动读Zone.Identifier。一台两台还好，批量核查几百个文件的时候根本看不过来。Sigcheck 2.8把这一步变成了纯命令行操作，可以直接把MOTW状态输出到结果里，配合哈希和签名信息一起判断。
3.2 应急响应中的批量签名核查
真实的应急响应场景里，经常遇到一个目录堆了几百个exe和dll，需要快速分辨哪些值得重点分析。这时候我通常会跑两个命令。
第一个命令是筛出未签名或签名不受信任的文件：
sigcheck.exe -s -u C:\Shared\Files-s是递归扫描子目录，-u是只显示未签名或签名校验失败的文件。这一条跑完，输出里剩下的基本就是需要人工看的对象。
第二个命令是把哈希全部算出来，方便后续做情报对比：
sigcheck.exe -h -s C:\Shared\Files > C:\samples\hashes.txt拿到哈希列表之后，可以扔进VirusTotal或者本地信誉库做批量查询。注意，签名验证失败不代表文件一定恶意，可能是证书过期、签名被破坏，或者只是开发者没签名。经验是：把“无签名”和“有恶意行为日志”两件事叠加起来判断，准确率才够高。
3.3 用MOTW快速筛选下载目录里的可疑文件
Sigcheck 2.8给我最大的惊喜，就是可以批量看文件的MOTW状态。比如你想知道某个用户下载目录里哪些文件是从浏览器下载的，一条递归扫描就能搞定：
sigcheck.exe -m -s C:\Users\victim\Downloads具体参数名在个别版本可能有差异，跑之前先sigcheck /?确认一下，但功能本质就是：扫描指定目录，把带MOTW标记的文件单独标出来。
实战中这个功能的价值不在于“找出所有带MOTW的文件”，而在于做交叉筛选。一个用户下载目录里90%的文件都会带MOTW标记，如果直接把“带MOTW”当告警条件，能被正常下载的安装包淹没。更聪明的做法是：先用MOTW把网络下载文件筛出来，再叠加“无有效商业签名”和“可执行文件/脚本”这两个条件，剩下的才是真正值得人工看的对象。
这里有个我在现场踩过的坑：MOTW是NTFS的替代数据流（ADS），把它复制到FAT32的U盘或者某些网盘同步文件夹，标记就会丢失。所以如果你拿到的是一份从U盘拷贝的文件，它没有MOTW不等于它本来没有，这点在写调查报告的时候必须写清楚，不然容易被误判。
4. Sysmon 11.10亮点：Mark of the Web取证，从下载到执行完整还原
4.1 MOTW到底是什么，为什么它能当证据
Mark of the Web，中文常叫“网页标记”。当浏览器下载一个文件时，Windows会在NTFS文件系统的替代数据流里自动写入一个Zone.Identifier，这就是MOTW。它记录了文件来源的“安全区域”。
在cmd里可以直接读这个标记：
type "C:\Users\victim\Downloads\invoice.exe:Zone.Identifier"正常输出长这样：
[ZoneTransfer] ZoneId=3 ReferrerUrl=https://xxx/malware.html HostUrl=https://xxx/invoice.exeZoneId数字含义如下：
| ZoneId | 区域 | 含义 |
|---|---|---|
| 0 | Local Machine | 本地计算机，无标记 |
| 1 | Local Intranet | 本地区域网 |
| 2 | Trusted Sites | 受信任站点 |
| 3 | Internet | 互联网，最常见 |
| 4 | Restricted Sites | 受限站点 |
取证意义上的关键信息有两个：文件是不是来自互联网，以及HostUrl指向哪里。后者可以直接定位到具体下载地址，是溯源的一手线索。
但有个细节很容易被忽略：不是所有下载方式都会写MOTW。主流浏览器（Edge、Chrome、Firefox、IE）都会写，但用PowerShell的Invoke-WebRequest、curl.exe、wget这类命令行工具下载的文件不一定写。所以MOTW存在不代表一定恶意，不存在也不代表不是网络下载——它更多的是一条“弱信号”，需要跟网络连接日志、DNS日志叠加起来看。
4.2 Sysmon 11.10怎么把MOTW变成日志
Sysmon 11.10这版的核心变化，是允许把MOTW信息记录到事件日志里。我在测试环境下梳理过一个事件ID 11（FileCreate）的字段布局，大概是这样的结构：
Event ID: 11 (FileCreate) UtcTime: 2020-06-15 08:12:33.101 TargetFilename: C:\Users\victim\Downloads\invoice.exe MarkOfTheWeb: True Image: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe不同版本字段名称可能略有差异，但核心意思是明确的：当文件创建事件发生时，Sysmon会把这个文件是否带MOTW一并写进日志。进程创建事件（事件ID 1）里，如果进程映像文件本身带MOTW，也会被记录下来。
这件事的价值怎么强调都不过分。过去你要判断一个文件是不是网络下载，得先找到文件，再手工去看ADS。现在Sysmon在事件发生的那一刻就把这个信息固化下来了，你可以直接在日志里查、在SIEM里筛、设告警规则去匹配。等于把“事后考古”变成了“事中留痕”。
对没有部署Sysmon的环境，兜底办法仍然有用——直接去现场读Zone.Identifier，或者用工具提取文件ADS。但有了Sysmon 11.10，这些都不是唯一手段了。
4.3 从下载到执行：用MOTW还原完整攻击链
理论讲再多，不如看一个完整的调查案例。
某天下午，SIEM发来告警：一台内网Windows主机上，rundll32.exe尝试建立外连。这是一个非常典型的可疑动作。我打开Sysmon事件日志，按时间倒序找到对应的进程创建事件，看到的命令行是：
rundll32.exe C:\Users\victim\AppData\Local\Temp\elder.dll,Init再看该事件的字段，进程映像rundll32.exe本身不带MOTW，但接下来关键的证据出现了：事件日志显示，这个elder.dll在被创建时，事件ID 11里的MOTW字段为True，说明它落地时是带“互联网下载”标记的。
顺着这条线索往下翻，发现创建这个dll的进程是Edge浏览器。于是我去下载目录找了原始文件，读取它的Zone.Identifier，拿到了HostUrl。再回看Sysmon的网络连接事件，发现同一时间段内，主机确实向HostUrl对应的域名发起过HTTPS连接。到这里，完整的攻击链已经闭合：
- 用户访问了某个页面，浏览器下载了一个带MOTW的dll文件。
- 文件落地到
%TEMP%，Sysmon文件创建事件记录了MOTW标记。 - 某个恶意进程或脚本调用了
rundll32.exe执行这个dll。 - dll发起外连，触发告警。
整个过程不需要原始样本就能把“源头URL、落地时间、执行进程”全部串起来。这就是MOTW日志最核心的取证价值——它把网络下载和本地执行两个原本割裂的环节连在了一起。
实际调查中还见过一个变体：恶意压缩包本身带MOTW，用户解压后，新版Windows会把MOTW继承给解压出来的文件。于是攻击者通过“发一个带毒的压缩包”就能让落地文件带着可追溯的标记，反而帮助我们更容易确认来源。这种场景下，Sysmon的MOTW记录能直接钉死“这份文件来自网络下载后解压”这一事实。
4.4 Sysmon配置建议：别让日志把SIEM淹了
Sysmon 11.10安装方式没变，管理员权限下执行：
sysmon64.exe -accepteula -i config.xmlconfig.xml是需要自己准备的配置规则文件。MOTW信息本身不需要额外开启什么开关，安装后默认就会跟着对应事件输出。但这里有一个很实际的坑：文件创建事件（ID 11）是Sysmon里量最大的事件之一，如果配置不当，日志量能把你的SIEM存储打满。
我的配置建议是：别全量记录所有文件创建，用过滤器把关注范围缩小到高价值路径。比如只对以下路径的文件创建事件做记录：%TEMP%、Downloads、C:\Users\Public、C:\ProgramData。这三个目录是恶意文件落地的高发区，其他地方的文件创建事件大概率是正常软件安装产生的噪音。
如果追求更精细的告警效果，可以给SIEM加一条规则：事件ID为11且MOTW字段为True且路径包含%TEMP%或Downloads时触发告警。这条规则在把误报压到极低的同时，能够精准捕获“浏览器下载→临时目录落地→准备执行”的高危链条。实际跑了一段时间后，误报率比“监控所有进程创建”低得多，命中率反而更高。
另外，升级Sysmon时先备份现有配置，再执行升级，免得规则文件被覆盖。日志建议单独建存储，设定保留天数，防止长期运行把系统盘写满。
5. 高频问题与避坑实录
5.1 MOTW场景下的常见问题速查表
我把这轮更新后实际遇到的问题整理了一张表，供大家参考：
| 现象 | 典型原因 | 处理建议 |
|---|---|---|
| 文件明显是下载来的，但Sysmon里MOTW字段为False | 下载工具不写ADS，比如PowerShell、wget、curl；或者文件经过了FAT卷中转 | 结合网络和DNS日志回看下载源，别依赖单个信号 |
| 解压后的文件没有MOTW | 压缩包本身没有标记，或者解压工具丢弃了ADS | 检查压缩包自身的Zone.Identifier；Windows资源管理器解压通常会继承 |
| Sigcheck的MOTW参数没有输出 | 版本低于2.8，或参数写法有差异 | 升级最新版，先跑sigcheck /?确认参数 |
| 事件ID 1里没看到MOTW字段 | Sysmon版本过低，或配置文件里把该字段过滤掉了 | 升级到11.10以上，检查配置规则中是否有针对Image的过滤 |
| 某文件在下载目录里有MOTW，但复制到桌面上就没了 | 文件被复制到不支持ADS的卷，或者被某些同步工具转移 | 从源机器直接采集，或者采集镜像时保留NTFS ADS |
5.2 我踩过的一些坑和现在的习惯做法
第一个坑：曾经把用户下载目录里的合法安装包全部报成“可疑文件”，原因就是我拿“带MOTW”当成了恶意指标。后来改成“带MOTW + 无有效商业签名”双重条件，误报率立刻降下来。MOTW在取证上很有价值，但它本质上是大量正常文件都会有的标记，单独用它下结论一定会翻车。
第二个坑：Sysmon 11.10刚装好的时候，我发现文件创建事件里有大量MOTW=True的条目。一开始很兴奋，后来才发现那只是用户正常下载软件安装包时产生的日志，并不是攻击行为。从那以后我都习惯把MOTW字段跟其他行为字段联动使用——比如同进程是否发起了外连、同时间段是否出现了计划任务变更——而不是单独条告警。
第三个习惯比较推荐：每次做主机镜像取证时，除了采集Sysmon日志，还会用工具把关键可疑文件的ADS单独提取出来保存。就算Sysmon没开，Zone.Identifier里往往还留着ReferrerUrl和HostUrl。万一Sysmon日志被清或者没部署，这条兜底路径可以救你一命。
结尾
老实说，Autoruns 13.98和Sigcheck 2.8更像是例行迭代，真正让我眼前一亮的是Sysmon 11.10的MOTW记录功能。它把一个原本藏在NTFS流里、平时没人管的标记，变成了可以查询、可以告警、可以串联攻击链的结构化字段。我现在做终端侧日志建设，判断一个文件是不是从网上下来的，第一反应就是去Sysmon里翻MOTW。
升级完这些工具别光顾着看版本号，把上面这几个场景落到自己的监控规则和取证流程里，才算真正用透了这轮更新。如果环境允许，建议先在测试机上跑一段时间，把MOTW字段和现有的网络日志、DNS日志对照着看几轮，慢慢形成自己的狩猎场景。这套玩法虽然是2020年6月更新的，但一直到今天，在我日常排查里依然在用。