Sysinternals六月更新：Sysmon MOTW标记与应急响应实战

Sysinternals套件又发布了一轮更新Autoruns 13.98、Sigcheck 2.8、Sysmon 11.10。这三个名字在应急响应圈子里基本不用多介绍Autoruns负责挖系统里的开机自启与持久化Sigcheck负责验文件签名和哈希Sysmon则是在系统事件层面盯进程、文件、网络行为的“眼线”。这轮更新最值得留意的是Sysmon和Sigcheck都跟Mark of the WebMOTW文件互联网下载标记沾上了关系——用得好可以在样本溯源时快速判断恶意文件到底是从哪条路径进来的。这篇文章不是抄官方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] ZoneId3 ReferrerUrlhttps://xxx/malware.html HostUrlhttps://xxx/invoice.exeZoneId数字含义如下ZoneId区域含义0Local Machine本地计算机无标记1Local Intranet本地区域网2Trusted Sites受信任站点3Internet互联网最常见4Restricted 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 11FileCreate的字段布局大概是这样的结构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.IdentifierWindows资源管理器解压通常会继承Sigcheck的MOTW参数没有输出版本低于2.8或参数写法有差异升级最新版先跑sigcheck /?确认参数事件ID 1里没看到MOTW字段Sysmon版本过低或配置文件里把该字段过滤掉了升级到11.10以上检查配置规则中是否有针对Image的过滤某文件在下载目录里有MOTW但复制到桌面上就没了文件被复制到不支持ADS的卷或者被某些同步工具转移从源机器直接采集或者采集镜像时保留NTFS ADS5.2 我踩过的一些坑和现在的习惯做法第一个坑曾经把用户下载目录里的合法安装包全部报成“可疑文件”原因就是我拿“带MOTW”当成了恶意指标。后来改成“带MOTW 无有效商业签名”双重条件误报率立刻降下来。MOTW在取证上很有价值但它本质上是大量正常文件都会有的标记单独用它下结论一定会翻车。第二个坑Sysmon 11.10刚装好的时候我发现文件创建事件里有大量MOTWTrue的条目。一开始很兴奋后来才发现那只是用户正常下载软件安装包时产生的日志并不是攻击行为。从那以后我都习惯把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月更新的但一直到今天在我日常排查里依然在用。