平时做安全排查或者应急响应的时候最头疼的一件事就是Windows自带的日志体系太“粗糙”了。你想看某个进程到底执行了什么命令、有没有外联、加载了哪个DLL系统自带的Security日志里大多只有登录和账户操作这类信息进程创建、网络连接、文件落地这些关键动作默认情况下要么没记录要么记录得残缺不全。这时候我基本都会直接上Sysmon——微软Sysinternals套件里的系统监控利器也是如今威胁狩猎、入侵取证和红蓝对抗里绕不开的主力工具。Sysmon全称System Monitor是一个Windows系统服务和内核驱动装上之后会默默坐在后台把进程创建、网络连接、文件读写、注册表变更、驱动加载、DNS解析这些高价值行为按事件ID写进Windows事件日志里。相比自己写脚本轮询、或者用WMI硬怼Sysmon的采集粒度更细、性能开销极低、而且完全官方免费。特别适合安全运维、蓝队分析、以及刚刚开始接触主机检测和响应EDR/HIDS的人去使用。这篇文章我会从部署安装、配置规则、事件ID解读、实战排查到常见坑全部过一遍尽量让你看完就能直接在自己机器上跑起来。1. 为什么是SysmonWindows自带日志缺了什么很多刚接触主机侧检测的人会问同一个问题Windows本身不是有事件日志吗什么审计策略、PowerShell日志、网络审计都能开为什么非要再装一个Sysmon这个疑问非常合理但实际对比一次就知道差距了。系统自带的Security日志主要负责的是“谁登录了”“谁改了权限”“谁创建了用户”这类账户和策略层面的审计。而Process Creation事件通常对应安全ID 4688虽然能记录进程启动但默认情况下很多关键字段是缺的进程命令行参数经常不录父进程的完整信息也有缺失更别提进程哈希、加载的DLL列表、网络连接的五元组这些细节。换句话说安全日志能告诉你有一个程序启动了但很难告诉你它启动时干了什么、是怎么被拉起来的、后续又连去了哪里。Sysmon从一开始就是按照“行为记录”的思路来设计的。它在内核层通过驱动挂接系统回调把操作系统的关键行为点全链路记录下来而且记录得非常结构化。举个例子同样是进程创建Sysmon的事件ID 1会一次性给你这些字段进程GUID、完整命令行、可执行文件路径、文件哈希默认SHA256也可以配置IMPHASH、MD5、当前工作目录、父进程信息、登录会话、用户账户等。这意味着你可以直接还原出“谁在什么时间用哪个账户、在哪个目录下、通过什么父进程、启动了一条什么命令行”的完整上下文。还有一个容易被忽略的点自带日志的策略一旦打开要么是全量记录导致性能下降和日志爆炸要么是设了阈值导致关键动作漏记很难在“采什么”和“不采什么”之间做精细化控制。Sysmon的过滤规则更灵活。你可以自己定义一个XML配置文件决定哪些进程的网络连接要记、哪些补丁进程的镜像加载要忽略相当于把采集粒度做成“按需定制”。我见过不少团队把Sysmon当作轻量EDR来用用配置文件做行为白名单和黑名单再采集到SIEM平台里做关联分析。虽然它不是全能的但作为主机侧的第一道数据采集层覆盖面已经相当能打了。2. 3分钟快速部署Sysmon的下载、安装与配置加载部署Sysmon的步骤非常简单本质就三步下载工具、准备配置、执行安装命令。难点不在安装本身而在后面的配置规则怎么写以及怎么让它和你的监控策略匹配。先讲安装环境要求需要Windows 7及以上系统建议用64位操作系统服务运行需要管理员权限。Windows Server系列同样支持生产环境里我一般在Server 2016/2019/2022上都部署过性能影响在可接受范围内。2.1 安装前准备拿到工具和初始配置下载渠道直接用微软Sysinternals的官方页面或者Windows Sysinternals套件即可工具名称叫Sysmon压缩包里包含sysmon.exe32位和sysmon64.exe64位两个二进制文件解压之后放在一个固定目录比如C:\Tools\Sysmon。因为Sysmon本身是官方签名的驱动大部分环境下安装都不会被Windows Defender拦截但如果你在严格策略的服务器上碰到阻止需要先在系统设置里临时放行或者做例外处理。配置文件我建议不要自己从零写而是基于经过大量生产环境验证的开源配置模板修改。最常用的是Sysmon-Modular项目的sysmonconfig.xml或者SwiftOnSecurity维护的配置。这些模板把常见误报做了过滤你拿到后根据业务环境调优比正对着一堆XML标签从头研究要高效得多。2.2 安装命令与参数解读安装的核心命令只有一行假设你的配置文件名是sysmonconfig.xmlsysmon64.exe -accepteula -i sysmonconfig.xml几个参数一个一个说清楚。-accepteula的意思是接受Sysmon的最终用户许可协议第一次运行时必须带否则工具直接退出。-i表示安装驱动和服务并加载后面的配置文件如果你不加配置文件直接运行Sysmon会使用一套隐式的默认配置这种配置会把进程创建和网络连接之类核心事件全部记录但过于粗糙不建议生产环境这么干。此外还有几个有用的参数-c更新当前运行的配置适合规则调整后做热更新不需要重启服务。比如你改完了XML直接执行sysmon64.exe -c 新配置.xml就会立即生效。-n显式记录网络连接这个参数在旧版本里偶尔会配合-c一起用新版配置文件中通过过滤规则也能控制不需要每次都带。-u卸载Sysmon服务和驱动。卸载后历史日志仍在事件日志里留存不会丢。-s打印当前配置文件中的默认过滤规则摘要不执行安装方便你确认配置是否被正确解析。-?查看全部参数清单。安装完成后你可以在服务管理器里看到名为Sysmon的服务对应的驱动名是SysmonDrv。我习惯装完之后先跑一条快速验证命令确认事件日志已经能正常产生Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational -MaxEvents 5 | Format-List如果这条命令能返回几条Event ID相关的事件说明安装成功并且日志管道已经通了。这里有一个比较容易踩的坑安装命令必须以管理员身份运行如果PowerShell或CMD没有提权会直接报“Access is denied”不是工具本身的问题。2.3 查看事件日志与常用查询方式Sysmon的事件不落在Security日志里而是单独放在“应用程序和服务日志 - Microsoft - Windows - Sysmon - Operational”这个通道。你可以用事件查看器直接点开看也推荐用PowerShell做定向查询。比如查询最近的DNS查询事件Event ID 22Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id22} -MaxEvents 50 | Select-Object TimeCreated, Message | Format-List生产环境里事件量通常比较大强烈建议在采集端直接接Windows事件转发WEF或者用自带的事件采集代理统一汇总到SIEM。把原始事件留在机器本地既容易丢也不利于跨主机关联分析。这个我在后面常见问题里会再展开说。3. 事件ID才是核心关键事件类型逐一拆解Sysmon最需要花功夫理解的就是事件ID体系。从7到29一共二十多个事件类型但真正日常高频使用和关注的其实就那几个。下面这张表是我根据排查经验整理的高频事件ID速查表建议直接收藏事件ID事件名称代表含义使用场景1进程创建ProcessCreate执行了某个程序记录命令行、进程哈希、父进程3网络连接NetworkConnect进程发起或接受TCP/UDP连接5进程终止ProcessTerminate进程退出6驱动加载DriverLoad加载了内核驱动7镜像加载ImageLoad进程加载了DLL模块8远程线程创建CreateRemoteThread进程在另一个进程中创建线程10进程访问ProcessAccess进程打开了另一个进程句柄11文件创建FileCreate创建了文件12/13/14注册表操作RegistryEvent键/值/键名变更15文件哈希变更FileCreateStreamHash备用数据流ADS相关17/18管道创建/连接PipeEvent创建/连接命名管道22DNS查询DnsQuery进程发起DNS解析23文件删除FileDelete删除文件25进程更改ProcessTampering进程映像被修改26日志清空FileDeleteDetectedSysmon日志被清空3.1 进程创建与网络连接的组合分析事件ID 1和事件ID 3是最常用的一对组合几乎所有实战排查都绕不开。事件ID 1的核心价值在于完整的父子进程链。你可以根据ParentProcessId和ParentImage字段还原出一个进程是被谁拉起来的。举个例子正常情况下powershell.exe的父进程应该是explorer.exe用户手动打开或者svchost.exe计划任务触发但如果它的父进程是word.exe或者w3wp.exe那基本可以断定是宏执行或者WebShell调用了PowerShell这类异常父子关系一眼就能看出问题。事件ID 3记录网络连接时会输出源IP、源端口、目标IP、目标端口、协议等字段并且会关联到发起连接的进程和进程GUID。这样你就可以把进程创建事件和网络连接事件通过ProcessGuid关联起来还原出一条“某个进程被启动-访问了某个外网地址”的攻击链路。这种关联分析能力正是原生安全日志做不到的。需要注意事件ID 3只记录建立成功的连接对于被防火墙拦截的连接Sysmon并不关心因为连接没建立。另外UDP无连接但它也能记录UDP收发动作只是没有“连接状态”这个概念。实际排查外联C2的时候我通常会把所有外网IP的连接记录拉出来然后按目标IP聚合再交叉对比威胁情报效率很高。3.2 注入类、凭证访问和持久化事件的识别思路如果攻击者已经开始做横向移动或者内网渗透光看进程创建和网络连接已经不够需要把眼光放到事件ID 8、10、12/13、17/18这些更底层的行为上。事件ID 8CreateRemoteThread是注入类攻击的典型特征。正常软件基本不会频繁在其他进程里创建远程线程一旦看到svchost.exe或者explorer.exe里出现来源异常的远程线程创建记录需要立刻警觉。事件ID 10ProcessAccess最常见的恶意场景是攻击者通过mimikatz这类工具打开lsass.exe进程句柄去读取凭证。实战里我会在配置里对lsass.exe单独做一条监控规则只要检测到非系统进程访问它就直接告警。事件ID 12/13注册表变更则多用于发现持久化后门。最常见的比如写入HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run、RunOnce、Image File Execution OptionsIFEO、计划任务注册表等路径。配合事件ID 1的进程创建基本可以识别出“写入注册表项之后紧接着启动了一个可执行文件”这种典型的自动启动攻击链。命名管道事件17/18平时容易被忽略但在横向移动和某些C2木马比如Silver、SMB Beacon的管道通信里非常关键。如果一台主机上出现了异常命名管道创建或连接行为且涉及到常见的\\.\pipe\msagent_*这类管道名就应该结合进程链做一次完整的溯源排查。3.3 新版Sysmon新增事件DNS和文件操作的实战意义Sysmon从某个版本开始加入了DNS查询事件Event ID 22这对于检测恶意域名解析非常关键。以前你需要额外部署DNS日志采集现在直接在Sysmon层面就能拿到每个进程发起的DNS查询记录。很多恶意软件运行后会先解析它的C2域名DNS查询时间往往早于网络连接建立时间。把这个事件和网络连接事件按进程GUID关联起来就能非常清楚地看到“某个进程解析了某个域名-随后连到了对应IP”的完整链条。不过需要注意的是Event ID 22只在Windows的DNS客户端服务开启时才会记录如果你在极简化的服务器镜像里把DNS Client服务手工禁用掉了这个事件就会静默丢失。另外事件ID 11文件创建、23文件删除在勒索软件和WebShell场景里非常直观。勒索软件通常会在短时间内批量创建或修改大量文件Sysmon可以记录到每个文件写入动作并且事件ID 11还能记录文件内容的部分哈希方便后续做样本比对。遇到攻击者清日志的情况事件ID 26会明确告诉你日志文件被删除或覆盖了这本身就是最直接的高危告警。4. 实战案例用Sysmon还原一次可疑进程链理论讲再多不如完整跑一个排查案例。假设内网某台Windows服务器受到了攻击怀疑你要用Sysmon日志还原出攻击者的操作路径。整个过程我会按真实排查思路来走。4.1 第一步从异常进程创建定位入口先拉取最近一个小时内的事件ID 1按时间倒序重点过滤命令行带powershell、cmd、wscript、mshta、rundll32、regsvr32这类高危终端的记录Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id1; StartTime(Get-Date).AddHours(-1)} | Where-Object { $_.Message -match powershell|cmd|wscript|mshta|rundll32|regsvr32 } | Select-Object TimeCreated, Message | Format-List假设返回结果里有这样一条C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -enc SQBFAFgAKABOAGUAdwAtAEkAdABlAG0A...看到这个-enc参数基本可以直接定性为编码执行恶意载荷。再看父进程字段发现它的父进程是C:\Users\public\documents\svchost.exe而正常的svchost.exe应该运行在System或者NetworkService会话下且路径在C:\Windows\System32这就等于拿到了下一步的线索公共目录下藏着伪造的可执行文件。4.2 第二步用网络连接事件确认外联行为锁定可疑进程之后下一步是查这个进程对应的网络连接。Sysmon事件里的ProcessGuid字段就是把所有事件串起来的主键先记下可疑进程启动事件里给的ProcessGuid然后用它去过滤事件ID 3Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id3} | Where-Object { $_.Message -match YOUR-PROCESS-GUID } | Select-Object TimeCreated, Message | Format-List结果如果显示该进程向外网某个IP的443端口发起了连接再配合事件ID 22的DNS查询记录大概率能看到它先查了一个随机子域名的域名这就基本符合C2通信特征。到这里入口进程、父进程、落地路径、外联地址、DNS域名整条链路已经完整闭环了。4.3 第三步回溯持久化和痕迹清理行为继续往前后推看看这个可疑进程运行之后有没有写入注册表启动项或者创建计划任务。直接查同一时间窗口内的事件ID 12/13按注册表路径过滤Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id12,13; StartTime(Get-Date).AddHours(-3)} | Where-Object { $_.Message -match CurrentVersion\\Run|Schedule|Winlogon } | Select-Object TimeCreated, Message | Format-List实战里经常会发现攻击者在Run键下面写入一个指向公共目录伪svchost的启动项这就是典型的持久化驻留。更进一步如果还看到事件ID 23文件删除或事件ID 26日志清空记录那基本可以确定是攻击收尾阶段的痕迹清理动作。这几条日志拼在一起就是一份完整的攻击时间线比任何截图都更有说服力。5. 配置文件的进阶写法与规则优化Sysmon的配置文件是控制“采什么不采什么”的关键也是安装完之后最值得花功夫打磨的部分。配置文件本质是一个XML最外层是Sysmon标签包含一个schemaversion属性内部是EventFiltering标签里面按事件类型定义过滤规则。每个事件类型又通过onmatch属性来区分包含或排除模式。5.1 理解include/exclude的规则逻辑Sysmon每个事件类型下的过滤规则有两种模式onmatchinclude和onmatchexclude。这个逻辑很多人第一次接触会绕晕我用最简单的说法解释include模式下规则里写的是“只要匹配到这些条件就记录”exclude模式下规则里写的是“匹配到这些条件就不记录”。两种模式都能叠加多个规则同时存在时Sysmon会先做include过滤再做exclude过滤。如果你希望只记录特定进程的网络连接先声明一个include规则只包含指定进程名的连接事件这样其他进程的网络事件全部被丢弃。然后由于很多正常软件也会创建网络连接如果你想再排除掉其中一部分就在include规则之后追加一个exclude规则。实际生产环境里为了降低日志量大部分团队的模式都是“默认全量记录对已知可信进程做exclude排除”这样做的好处是漏报率低过滤逻辑简单。比如下面这段配置表示排除explorer.exe的进程创建记录和svchost.exe的网络连接记录Sysmon schemaversion4.90 EventFiltering ProcessCreate onmatchexclude Image conditionisC:\Windows\explorer.exe/Image /ProcessCreate NetworkConnect onmatchexclude Image conditionisC:\Windows\System32\svchost.exe/Image /NetworkConnect /EventFiltering /Sysmon注意条件值conditionis表示精确匹配除了它还有is any、contains、begin with、end with、image等。最常用的过滤条件就是Image进程映像路径、CommandLine命令行、ParentImage父进程路径和DestinationIp目标IP。如果一条规则里写了多个字段多个字段之间是“与”的关系也就是说必须全部满足才算命中。5.2 参数hash怎么配SHA256、IMPHASH与文件识别Sysmon计算文件哈希时默认是SHA256但你可以通过配置或启动参数增加其他哈希算法比如-h MD5,SHA256,IMPHASH。IMPHASH是一个非常实用的字段它不计文件内容全文而是对文件导入函数表做哈希只要两个样本使用同一套导入函数IMPHASH就相同。这用来做恶意样本的变种聚类效果很好。配置层面没有开放哈希算法的参数哈希算法只能通过启动参数指定。如果你已经用默认配置安装完了想追加IMPHASH可以先修改配置后用sysmon64.exe -c 新配置.xml重新加载同时用sysmon64.exe -h MD5,SHA256,IMPHASH更新哈希算法。这里有个经验生产环境的哈希算法不建议配太多每多一种哈希CPU和内存开销都会增加尤其是在文件写入频繁的主机上。我的习惯是默认SHA256再补一个IMPHASH就够用。5.3 如何平衡日志量与检测覆盖度很多新手一上来就把所有事件类型全量打开结果一天下来日志文件膨胀到几个GB真正要查的时候反而无从下手。实际上Sysmon的过滤原则应该和攻防场景对应起来进程创建、网络连接、DNS查询、进程访问、远程线程这些高危行为尽量保留文件创建和注册表变更则要根据业务情况选择性记录否则系统更新和软件装包事件会刷屏。以我常用的基线为例进程创建保留全部网络连接排除已知系统进程的本地回环流量DNS查询排除可信DNS服务器和已知内部域名后缀镜像加载和远程线程仅记录排除列表之外的进程注册表变更只记录关键持久化路径和敏感键值。大概这个思路写下来普通办公终端单日日志量可以压到200-500MB服务器会更低同时攻击链的关键行为一个都不会漏。如果连这点量都觉得大那就得配合日志采集端的过滤或者SIEM侧再收敛而不是在Sysmon源头把事件关掉——因为单机日志一旦关闭采集端无法恢复事后溯源就会缺数据。为了压缩体积牺牲了关键行为记录是最不划算的取舍。6. 常见问题排查与避坑实录用到Sysmon一段时间总会踩到各种奇怪的坑。下面这些是我实际遇到或者在客户环境里帮忙排查过的典型问题列成一张速查表碰到类似情况可以直接对号入座。问题现象可能原因处理方式安装后事件日志里没有Sysmon通道安装未成功或服务未启动用管理员身份重新执行sysmon64.exe -i检查服务列表中Sysmon状态事件日志有但事件量极少配置文件exclude规则过严检查配置文件的onmatch逻辑暂时移除exclude规则测试PowerShell查询结果为空当前账户无读取事件权限或事件已被归档用管理员身份重新执行PowerShell检查事件日志大小设置日志大量丢事件事件日志通道大小不够触发自动覆盖在事件查看器中调大Sysmon日志上限建议至少1GB以上机器卡顿CPU占用高全量事件过多哈希算法导致负载升高优化过滤规则减少exclude误配精简哈希类型驱动加载失败提示签名问题系统策略阻止未签名驱动确认使用的是官方签名驱动检查Windows Defender隔离记录修改配置后不生效只改了XML没有执行-c加载执行sysmon64.exe -c 新配置.xml热更新配置采集端收不到DNS事件DNS Client服务被禁用或规则未开启启用DNS Client服务在配置中增加DnsQuery规则6.1 安装相关的坑签名、权限与驱动冲突Sysmon虽然驱动是微软签名但碰到一些极端精简的Windows镜像或者强化过的服务器安装过程还是可能出问题。最常见的是Windows Defender实时防护把sysmon64.exe和驱动文件当作可疑文件处理建议安装之前先在Defender里加一个排除目录。另外某些安全软件自带的驱动级防护会和Sysmon的内核回调产生冲突表现就是安装时报错或者装上后蓝屏。我在几台装有某知名EDR的主机上遇到过类似情况最终的处理方式是先把EDR的驱动层卸载或暂停装完Sysmon再装回两者交错工作才稳定。还有一个小细节32位系统要用sysmon.exe64位系统优先用sysmon64.exe。如果混用驱动架构不匹配服务能装上但无法正常工作日志通道也起不来。尤其是很多老工具或自动化脚本里写死了sysmon.exe在64位系统上跑完没有任何提示但实际啥也没记录排查半天才发现是架构问题。6.2 日志轮转与磁盘空间规划Sysmon日志默认落在Microsoft-Windows-Sysmon/Operational通道事件查看器里可以单独设置这个通道的最大日志大小。Windows默认大小一般是1MB对于Sysmon来说完全不够。一个业务稍忙的主机一天的事件量可能就有几十万条1MB的日志几小时就被覆盖掉。建议这个通道的大小直接拉高至少1GB条件允许可以给2GB。磁盘紧张的主机优先保进程创建和网络连接其他事件类型在配置源头就降噪。设置日志上限的操作路径是事件查看器 - Windows日志/应用程序和服务日志 - Microsoft - Windows - Sysmon - Operational - 属性 - 日志最大大小。如果希望通过脚本批量调整所有主机的日志大小可以对应修改注册表键HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Sysmon/Operational下的MaxSize值再重启Event Log服务不建议频繁重启会影响日志采集连续性。6.3 采集与集中管理的落地经验单机查看Sysmon日志只是入门玩法。真正到生产环境几十台、几百台主机都装了Sysmon不可能每台都手工点事件查看器。最主流的方式是用Windows事件转发WEF把Sysmon事件集中转发到一台日志采集服务器上或者用商业SIEM/日志平台的Agent直接拉取。开源的方案里Elastic的Winlogbeat可以非常方便地采集Sysmon日志并直接送进Elasticsearch配合Elastic的检测规则模板等于自己搭了一套轻量EDR。有一点需要特别提醒采集过程中最大坑是时间同步。Sysmon事件里带的是主机本地时间如果主机之间时间偏差大跨主机做攻击链还原时时间线会错乱。所以采集前一定要确认所有主机的NTP时间同步是正常的这一点比大多数人想象的更重要。另外Sysmon本身不具备告警和响应能力它只负责记录。你必须在它之上挂一层监控策略才能发挥价值。比如在SIEM里写规则“检测到Event ID 1且CommandLine包含powershell -enc”命中就触发告警或者“Event ID 3直连威胁情报命中的外网IP”输出高危事件。没有这层关联分析和告警Sysmon只是一个高级版日志工具安全价值会大打折扣。7. 部署后的调优心得写到最后分享几个在实际运维中比较实用的习惯或者说是踩过坑之后换来的教训。第一个是关于配置文件改动的习惯。每次调整配置前先把当前配置导出一份做备份命令是sysmon64.exe -c导出当前运行配置或者直接备份XML文件。一旦新配置导致关键事件丢失你可以秒级回滚到上一个版本。千万不要在人数较多的生产环境里直接改配置并热加载万一过滤规则写错丢的可是最要命的攻击行为记录。第二个是关于哈希和日志量的平衡。我在一个客户环境里发现他们的Sysmon日志量异常大排查后发现问题不在规则而是配置了MD5、SHA256、IMPHASH三种哈希并且每张表都全量采集。文件创建频繁的Web服务器日志量直接翻了三倍。后来把哈希收敛成SHA256IMPHASH同时把文件创建事件里的日志路径加了排除量一下就降下来了检测覆盖也没受影响。第三个是关于误报的处理思路。Sysmon本身会产生海量“看起来像恶意”的行为尤其是系统更新、办公软件自动升级、杀软自身行为这些。这些正常行为如果一条一条加到exclude里规则会越来越臃肿。更合理的办法是先收集一周的基线流量了解主机的正常行为模型再针对高频并且无害的行为做排除而不是一开始就追求“零误报”。Sysmon不是装完就能一劳永逸的工具它更像一把趁手的瑞士军刀——平时不起眼真正需要排查和溯源的关键时刻它能把你从黑盒状态里捞出来用一条条清晰的事件记录告诉你机器上到底发生了什么。根据我个人经验日常比较推荐的组合是内核层用Sysmon做行为采集、应用层用PowerShell日志和进程命令行审计做补充、上层再挂一套SIEM做规则告警和事后回溯。这套组合能覆盖大部分主机侧的监控诉求而且成本几乎为零。如果哪天你需要快速定位一台机器是不是被入侵了装好Sysmon、写好一份合适的配置、让它老老实实跑上几天再看日志答案往往就藏在那些被记录下来的事件里。