在上一次ZeroNights会议上，在与监视系统的同事进行非正式交流的过程中，我们一眼就被问到了一个简单的问题-人们普遍认为Sysmon应该用于通过Windows OS全面监视端点，是吗？如果是这样，出于什么特定原因（您好Seryozha！）？我们无法在我们的知识包中找到明确的综合答案，也无法在Internet上进行相应的比较，因此，首先，我们自己，但并非最不重要的，因此将来，这样的资源仍将来自社区，我们决定探索这个主题。并比较Windows和Sysmon的面对面事件。俗话说：“ 1 ... 2 ... 3 ...战斗！”。
介绍
信息安全领域的任何专家都必须在特定框架内工作。例如，在有限的预算范围内，安全性（除了极少数的例外）不是组织在其核心业务中获利或执行其他职能的主要方式。因此，在组织拥有的资源有限的情况下，通常只将其中的一小部分分配给安全部门，以将这个方向保持在最小的足够水平上（根据某些要求）。即使拥有无限的资源，总会存在其他不允许将安全级别提高到绝对水平的限制。这些是众所周知的零或正常一天的漏洞（无休止的补丁管理），以及黑客和安全卫士不断的军备竞赛，以及IT基础架构发展的动力，还有更多。有鉴于此，比以往任何时候都更需要优先考虑保护手段和方法，包括在监测方面。在该领域中，根据基于我们上次写过的MITER ATT＆CK矩阵数据的统计数据，优先级如下：无条件的第一位被诸如端点之类的安全事件源占据。该来源导致可以基于记录在其上的事件进行识别的多种矩阵技术。端点最常见的操作系统仍然是Microsoft Windows。在大多数公司基础架构中准确收集其日志将以所有类型的成本与网络设备的覆盖率和恶意技术的覆盖率之比得出最佳结果。同一作者的统计数据证实了这一点。位置1-3、5、7、8、10和第4部分仅占据了这些所谓的基本事件。但是，就像著名的笑话一样，有一个警告。近年来，已被广泛接受，需要用Sysmon事件来补充Windows日志（如果不能替换的话）-他们说，从信息安全的角度来看，它们更完整，更好，更适合作为监视工具。另外，这种方法在某种程度上符合极简主义的概念。企业客户试图自己添加或自愿提供的每种软件产品，都会增加攻击范围，管理和更新成本以及故障点。而且通常-只是在实施监控系统之前的时间，而您的方法才获得批准。Sysmon由Microsoft专家开发，最近被该公司吸收，这在IT方面给予了一定程度的信任。此外，这些日志以.evtx日志的形式编写的，使您可以使用与常规Windows日志相同的工具和方法来收集和处理它们。尽管我们试图以最小的方式复制和压缩材料，但请立即保留该文章很大的保留。读者当然可以说，是指我们关于列宁的笑话：“但是他本可以大幅度削减……”。或者说“可以将出版物分为两部分或三部分以提高可读性”。但是在我们看来，尽管准备的材料很多，我们仍必须对商店中同事的问题提供完整的答案，并且搜索将更加方便。因此，为了不丢失任何内容，我们建议您完整阅读一篇文章，也许自己做笔记，然后再返回特定的事件组并对其进行详细研究。为方便起见，我们添加了一个目录：简介目录比较格式创建进程网络连接结束进程下载驱动程序访问进程创建文件注册表操作WMI配置DNS查询唯一的Sysmon事件过滤事件其他免费的基本事件提供程序常规输出比较格式
为何和进行了比较，这似乎很清楚。以及这是怎么做的，为什么呢？我们决定以表的形式对反映系统中特定活动的每组事件进行比较。例如，Sysmon中具有ID（事件ID，EID）12、13和14的事件（反映了注册表的活动）甚至被分开过滤，尽管它们说的是不同的原子动作。按照相同的逻辑，其余的分组完成了。这些小组仅包括类似事件。例如，Sysmon EID 6事件的类似物是Windows EID 6事件，同时，至少有219和7036 Windows事件有关加载驱动程序。但是它们是在失败的情况下出现的。那些。不会承受相同的语义负载，并且如果需要，可以根据我们决定收集的内容来补充Sysmon或Windows的事件。对于表中反映的事件组，事件中包含的信息性字段（我们用于监视目的）以字符串形式显示。对于每个这样的字段，将指示其名称。对于Windows，对于xml和杂志视图（谁会认为它们会匹配？）有2个选项是可能的。这样做是因为属于监视系统的字段的名称可能取决于收集方法。这些行还包含事件数据（以了解其格式）和注释（如果我们认为需要这样做）。两个源具有相同语义负载的字段合并为一行。对于一个源，在缺少具有类似语义负载的字段的情况下，在与之相对应的字段中指示短划线（“-”）。包含有关特定实体（例如，执行操作的主题）的信息的行被组合为一个语义组。对Windows Kernel 6.3（Windows 2012R2）和10.0（Windows 10、2016、2019）的版本进行了比较。没有考虑较早的版本，因为尽管它们仍然很广泛，但它们正在逐渐消失。如果不同内核版本的事件没有不同，则将这些列合并为一个以减少重复。由于速率是全日制的，因此从中心到边缘按以下顺序排列各列：数据，字段名称，注释。这使得比较更加直观。为了根据列所引用的来源对列进行视觉分隔，使用了颜色。Sysmon EID独有的（因为在这种情况下，它是一个补充工具，因此，记录OS日志已包含在OS的基本功能中）在单独的部分中给出。表格的部分显示了必须进行的GPO设置，才能在组事件日志中进行记录，如下所示：可能的审计选项的数量通常很大。对于Sysmon，不显示此类设置，因为 所有这些都包含在一个配置文件中。流程创建
矛盾的是，他们决定从头开始。然后它们也不是原始的，而是按顺序排列的-增加了EID Sysmon。在Windows中记录事件数据的方法如下：•计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-详细跟踪-审核过程创建-成功启用事件本身的记录；•计算机配置-策略-管理模板-系统-审核流程创建-在流程创建事件中包含命令行-将已启动流程的命令行添加到事件中，这通常使区分合法启动和非法启动成为可能。下表列出了上述格式的比较。在下文中，所有表格均由图片表示，并且可以单击。因为首先，我们没有找到一种很好的方法来将表传输到Markdown或HTML，同时又根据Excel中的现有版本保留列宽或连字符。其次，除了注释外，它们的内容对于索引编制不是很有价值。表中更有价值的是本文讨论的字段的组成以及使用这些事件源时必须使用的数据格式。按顺序考虑它，而不是逐行考虑-每个人都会为自己做这样的详细分析。在本节及以下部分中，我们将仅介绍第一次遇到的信息。立即从这种行为的示例开始。不管来源是Sysmon还是Windows，无论何时出现日志，每个日志中都会出现“系统”部分的字段。它们包括一般信息：- 事件提供者的名称。
- EID
- 记录事件的时间。
- 我们从中获得此活动的杂志的名称。
- 发生事件的主机。
分析人员通常不使用提供者的名称和连接后的日志。但是，它们使您可以了解在何处写入日志以及谁在写入日志，这在收集过程尚未开始时很重要。时间，主机和EID是执行主要事件过滤的主要信标。此外，在我要特别指出的字段中-用户会话以及子进程和父进程的GUID仅存在于Sysmon日志中。对于同一个存钱罐，出于奇怪，Windows事件中的进程ID（新的和父的）以十六进制编写，尽管在同一任务管理器中以十进制表示。俗话说，调试愉快（“-要改进？-Github”）...在Windows事件中启动进程时，命令行具有不同的格式，具体取决于启动它的实用程序。但是在Sysmon中，作者希望并且可以-格式不依赖于其他输入。我不会判断原因，但是SIEM内容的创建者不会为此而感谢Microsoft，这是肯定的。Sysmon的主要区别特征以及包含此字段的其他事件，我将称其为可执行文件的哈希。在Sysmon配置中选择了哈希格式。同样，从其他有趣的Sysmon奖励中-规则名称字段。实际上，这是一个标记，可以方便地标记配置文件中的某些过滤器，然后在分析事件时使用它。例如，我们可以说流程X的开始是指策略Y或技术Z.从分析师的角度以及从内容开发人员SIEM或Sysmon的角度来看，此方法都很有趣-它使我们能够了解决定收集此事件的原因。结论
Sysmon在修复此类事件方面要好得多：- GUID , , , , ID ( ). , , . . ID , , SIEM, . GUID, — .
- — — , , . — Sysmon , SIEM ( ). - — , . , SIEM . , , IBM QRadar. , - . , , — Windows , , .
- Rule Name .
- 其余唯一字段（在Windows事件中，在Sysmon事件中）的适用性（视情况而定）发挥了作用，正如它们用英语说的那样。因此，决定具体日志的选择或总体上将它们组合起来，也需要视情况而定。
网络连接
在Windows上记录以下事件：计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-审核筛选平台连接您为什么决定专注于Windows筛选平台（WFP）而不是Windows防火墙的事件？答案很简单。根据我们的实践，反病毒形式的终结点已经在主机上了。尽管它们不是为了监视系统的基本事件而设计的（这就是为什么它们不适合我们的目的），但是，在现代现实中，它们始终包括主机防火墙。因此，为避免重复，通常只需取消Windows防火墙。因此，没有人写信给上校... WFP，尽管它可以过滤流量，但我们仅将其用于监视。因此，没有重复。该表显示，如果我们尝试依赖Windows事件，则必须通过事件丰富来恢复用户超声波和交互主机的FQDN。虽然，如果您考虑一下，对我们来说更重要的是知道哪个进程建立了连接，而不是哪个用户。例如，恶意软件进入其C＆C中心。无论如何，我们都希望了解记事本并不会进入互联网本身（即基于事件中可用的信息），从而确定是谁启动了该过程或引发了事件。而且，使用FQDN更为简单-所有现代系统都将CMDB组件作为基本功能或其他功能。如果没有，那么绝对值得储备第三方解决方案。通常，了解您的基础结构是信息安全的基础。因此，可以通过充实或通过资产卡来获取信息，从而可以将其关联使用。最主要的是，如果可能的话，不要忘记连接DHCP日志，以便信息是最新的。所有其他唯一字段的重要性都不太高，例如：- 著名港口。我们不会依赖于此字段-例如，当ssh隧道通过端口80而不是HTTP时，有检测流量异常的工具并不是白费。
- 交通方向。了解主机ID（IP或FQDN）和连接的源\目的地后，就可以轻松计算出方向。
结论
在这种情况下，Sysmon会获胜，但不那么重要-GUID，FQDN，用户提供了使用SIEM或第三方解决方案完全有可能实现的便利。尽管如此，付出很小的努力并不等于零。流程完成
通常，如上所述，该事件不是很经常使用，但是...如果需要的话，那么在Windows方面显然是有好处的。我们仅添加如何启用日志记录，并直接得出结论。计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-详细跟踪-审核过程终止-成功结论
在这种情况下，通过以下方式可以实现本机OS日志记录的优势：- 显示完成该过程的用户。
- 退出代码的存在，可以谈论过程的正常完成以及错误。
驱动下载
与其他事件不同，此Windows事件默认情况下处于启用状态，并进入系统日志。这些事件中没有很多信息字段。再一次，立即得出结论。结论
在该组中，Sysmon事件为分析人员提供了更多有用的信息。例如，根据Windows事件，甚至不清楚使用哪个驱动程序文件。因此，在这组Windows中有明确的局外人。流程访问
我们不会将这组事件归类为基本事件，而是稍微高级一点。从安全的角度来看，该事件可能引起极大的兴趣。恶意程序可以通过多种方式使您的合法小“更好”。当然，不是为了利他主义，而是为了恶意的行为。正在考虑的事件只会帮助我们发现实现这种创造力的许多选择。在计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-审核内核对象-成功中启用了这些日志Windows有两个优点。首先，源进程正在从中工作的用户的映射。如上所述，优势通常可以忽略不计。其次，HandleID和访问权限。如果对访问权限的兴趣很明确，则HandleID仅对搜索相关事件有用。通过带有OS对象的进程（相同的进程（它们的线程），文件等）来组织用户交互是必要的。因此，其他事件可以显示结果如何以及向谁发布，以及何时取消了所需的访问权限。首次涉及对象和句柄的主题，以及记录与它们有关的操作时，注意两点很重要。首先，要记录上述其他步骤，重要的是要启用审计策略的其他设置，尤其是“计算机配置-策略-Windows设置-安全设置-高级审计策略配置-审计策略-对象访问-审计句柄操作-成功”。值得记住的是，这些事件的数量可能非常大。句柄是在收到请求后发出的，分别反映了所要求的权利。但是，为什么我们不能直接通过对对象访问的审核来期望发生相同数量的事件呢？这是因为，第二，必须在计划控制的对象上启用SACL。实际上，这是一个与DACL访问权限列表相似的列表，该列表确定使用其令牌创建的主题或对象在尝试访问该对象时是成功还是失败。但是SACL几乎以相同的形式确定与对象进行交互的权限，而不是确定在请求和行使某些权限时是否会生成安全事件。这些事件将包括尚未请求但实际使用的访问权限。结果，我们得到一个过滤器，该过滤器允许您仅记录对我们至关重要的对象的访问，并且仅记录对我们重要的那些访问类型。但是作为回报，我们必须将SACL直接附加到每个这样的对象，或者表明该SACL是从父对象继承的。当然，这可以通过各种方法来自动化。但是，维护此类自动化工具的配置不太可能很方便。与简单的Sysmon列表不同，Sysmon列表也可以包含通配符，尽管它们很特殊。我们将在单独的部分中讨论Sysmon中的过滤。幸运的是，对于类型为对象的对象，默认情况下内核版本6.3及更高版本已经存在SACL进程。如果有人可以指定一种方式来接收此SACL（本文的建议）我们未能实现），我们将很高兴听到/讨论。在Sysmon方面，除了已经讨论过的GUID和规则名称外，还有其他一些有趣的字段。首先，目标进程的PID。它将允许您监视受感染对象的后续活动，因为一个可执行文件中可能有多个实例。其次，CallTrace字段捕获目标中事件源的操作。仔细一看，就会意识到“手足无措”。另一方面，如此详细的分析已经是法医的命运。拥有专门的法证的人很可能不在构建监控系统的道路之初。结论
在该组中，事件在相当多的字段中有所不同。但是，如果在Windows事件中此信息最有可能提供初始分析的便利，则Sysmon会捕获难以以其他任何方式获取的独特数据。因此，Sysmon仍然具有优势。档案建立
Windows中包括以下类别：计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-审核文件系统-成功从表中可以看出，该组的所有优缺点都与上面已经描述的类似。包括SACL的优缺点（针对所有（每个人）用户的文件和文件夹，包括属性-安全性-高级-审核-添加-每个人-成功-写入（对于文件）或修改（对于目录））。您还可以通过在“计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-全局对象访问审核-文件系统”中定义文件来全局设置SACL。但是事件的数量（尤其是带有临时文件的事件）将与操作量成比例地增加。我不会说这是一种有效的方法，只有一小部分操作才有可能。我想指出从这里开始的测井奇数。对于此组来说，通过Powershell创建文件（例如New-Item C：\ FORTEST \ test.t）时，Windows事件不是固定的。同时，在Sysmon日志中可以完美地显示相同的操作。结论
最好使用Sysmon记录此事件组。注册表操作
到目前为止，就小组而言，我们仅包括一个事件。这种趋势将在这里改变。这些事件的日志记录配置如下：计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-审核注册表-成功。所有（每个人）用户的SACL定义如下：regedit.exe-注册表分支-权限-高级-审核-每个人-成功-高级权限-完全控制或设置值，创建子项，创建链接，删除，写入DAC。您还可以通过在计算机配置-策略-Windows设置-安全设置-高级审核策略配置-审核策略-对象访问-全局对象访问审核-注册表中定义全局文件来在文件上设置SACL。该方法的缺点类似于相同的文件操作。立即关注限制。对于Sysmon，具有值或键引发事件（重命名值除外）的所有操作（创建，修改，删除）。对于Windows：- 所有带有增值事件的操作。
- 创建密钥不会引发事件。
- 重命名键仅引发Access事件；不显示新的键名；事件中指定的请求权限与操作没有直观的明确对应。因此，重命名操作只能通过异常方法确定-没有具有此HandleID的删除事件4660。
- 卸下钥匙会引发事件4663，然后引发4660。
除了前面几节中讨论的字段之外，重要的是要注意Windows事件包含键和值的名称和值的新旧数据，这在调查期间可以帮助了解攻击者的动机。尤其是如果初始值不是标准值或典型值，并且配置（包括被调查机器的注册表数据）不会存储在主机外部的任何位置。结论
如我们所见，Windows日志记录有更严格的限制。为了修正某些事实，尽管最简单，但还是需要“关联”。但是，它能够提供大量真正有用的信息。对于这组事件，很难优先考虑其中一位参与者。WMI配置
我们传递到倒数第二组事件。这些是WMI事件。攻击者可以创建一个过滤器（过滤器），该过滤器接收有关系统状态更改（在我们的示例中为服务状态更改）的任何事件。并根据从此过滤器收到的事件执行某些操作，从而创建使用者。在我们的例子中，这是日志文件中的一个条目。接下来，他必须将过滤器输出连接到使用者输入，在过滤器和使用者之间创建绑定。它将证明系统可以在给定条件下工作。常用于持久性策略。正是按照所描述的顺序记录了事件19-21 Sysmon。重要的是要了解，创建过滤器或使用者本身并不构成威胁，但是当然可以构成攻击的一部分。此外，对于恶意活动，可以使用现有的筛选器，使用者或两者。这里就像是一把刀，或者更接近资源的主题，是带有加密的Messenger。问题不在工具中，而在工具中。让我们仔细看看桌子。首先应注意的重要一点-仅在创建或随后修改捆绑包（包括过滤器和使用者）的情况下，才在指定的日志中生成事件5861。一方面，如果不仅在其中创建了一堆，就可以更轻松地跟踪所谓的恶意活动（无需在两个或三个事件之间建立关联）。另一方面，如果恰好在过滤器或使用者的框架内并提前创建过滤器或使用者，则我们会错过该活动的开始时间。这很关键吗？视情况而定。如果我们开始放松事件的序列，并发现两年前创建了一个非典型的，据认为是恶意的过滤器或消费者，那么我们会立即意识到，攻击者已经在我们家里呆了两年多。而且必须至少在这种深度上寻找攻击的痕迹。这种情况多久发生一次？这是主要问题。但是，如果对现有包的过滤器或使用者进行了更改，我们将在单个事件中看到整个图片。而Sysmon将仅反映所做的那些更改（该对象）。除其他差异外：在Sysmon事件中，数据以更结构化的形式和更方便的格式反映。例如，代替非典型格式的SID，将立即显示用户的登录名。但是数据要少一些。也许这对您的情况至关重要。我们以限制为结论。首先，尽管该日记自Windows 2012（内核6.2）以来就一直存在，但即使对于内核6.3（2012R2），我们也无法获得这些事件，本文对此进行了研究。也许这是由于没有任何补丁。其次，根据笔者这在文章中，计时器事件的筛选器不是Sysmon固定的。可能不说一句话，但要检查一下。此外，Sysmon的版本较旧。但是这里有一个重要的先例-过滤器和WMI使用者类型不多。通过这样的研究，再加上细节，可以另作文章。只需测试目标类型以确切了解它们将要注册的内容。结论
在这种情况下，我们更愿意使用Windows事件。从方便的角度来看：更多的数据，不需要初级关联。因此，从目标设定的角度来看-它固定了机制的创建（基于新的，修改的或现有的部分），而不是其单个部分的创建。DNS查询
因此，我们继续进行最后的比较，但距离本文的结论还很遥远。这种类型和相应的事件集不仅是我们文章中的外观，而且还通过将Sysmon添加到工具箱中来实现。在过去的几年中，将DNS用于其他目的（例如，从C＆C接收命令或通过此渠道窃取信息）的话题已变得很流行。最有可能不是它本身-我们会将有关使用ICMP和DNS通道的故事称为零。那时，熟悉的学生精通玩具流量，以便通过唯一允许的渠道（您好，Zhenya，通博科！）。这样就可以以某种方式打发无聊的时间或快速掌握他们的实验室。这几乎不是他们的想法。但是不久之前，在此泄漏通道中添加了诸如DoH之类的概念，这使在网络级别检测可疑DNS流量变得复杂。也许这只是一种营销策略-出售一个新的，也被人们遗忘的旧的。或在可检测到的恶意活动中此类渠道的广泛出现。我们没有深入研究这个准备收集谷物的问题-一位读者突然决定在评论中放一点智慧。因此，更接近重点。打开事件查看器-应用程序和服务日志-微软-Windows-DNS客户端事件-操作-上下文菜单-启用日志。都已经讨论过。关于主题的信息，我们注意在Sysmon事件中执行请求的可执行文件映像的显式指示。如果我们谈论对象-Windows日志中有更多信息。但是有几个重要的“ buts”。首先，信息分布在多个事件上，带来了所有后果。其次，信息以不直观的方式呈现。要了解大多数知识，就需要了解软件包字段如何形成的知识，以及将这些数据转换回便于分析师做出决定的事实的能力。我们可以说，实际上，分析师并没有白白获得薪水，为什么不坐下来弄清楚它。恩，那就对了。但是让我提醒您，我们正在谈论的是一个没有狭窄专家的小型团队，在此之前，信息安全任务是没有止境的。如果SIEM分析的每个事件都落在他身上，那么几年之内他就不会追上他们。结论
对于这个群体，获胜者很难确定。Sysmon提供了简单的版本，您可以从中轻松榨取大量有用的信息。Windows提供了一个高级选项。仍然需要“缝制”，处理内容并问自己是否应该引入NTA？独特的Sysmon事件
我们将以下归因于Sysmon的独特事件：- EID 4、16。尽管可以通过Windows日志进行跟踪，但它们仅告诉我们有关Sysmon本身的事件。因此，在没有它的情况下，它们是没有意义的。
- EID 2-EID 4663可以被认为是一个类似物，但是即使考虑到其中提供的访问权限列表，该事件也不如EID2那样精细，并且不会随其他Windows事件而丰富到这种状态。
- EID 7-9, 17 — . ETW. , , .
- EID 15 — , ETW. , — .
- EID 18 — (named pipes) . , -, . -, , . ETW.
在源端有三个过滤事件的选项。第一个仅适用于Windows事件，并且仅用于监视对象的访问和操作。使用SACL实施。这种方法的缺点之一是粒度设置的复杂性（例如，您不能仅监视扩展名为.exe的现有文件或创建的文件）。优点之一是能够限制为其记录了对象操作的用户列表。第二个可用于Windows事件和Sysmon事件：使用Xpath，同时考虑到强大的Microsoft施加的限制。由于该方法可用于两个来源，因此其描述不在本文讨论范围之内。第三个是Sysmon配置。有很多选择：- 通配符仿真-包含（任何|全部），排除（任何|全部），以，结尾。使用包含|排除所有内容可让您模拟“ C：\ Windows \ *。Exe”之类的表达式。
- 完全匹配-是，不是图像。
- 算术-小于，大于。
应该注意的是，这种过滤并非对所有字段都可用。例如，您不能将标准软件的哈希列入白名单，即我们不感兴趣的流程的创建。以我们的经验为例-合法进程git.exe每天在开发人员的主机上创建数以万计的启动事件。也许，特别是在这种情况下，他的行为可能会变得更加严格，从而减少事件的发生。但是按映像名称排除可执行文件不是一个好主意。好吧，也许只有启用了自卫的防病毒软件。Sysmon还只能通过组合来自不同领域的条件来进行复杂的过滤。您只能为每个由AND关系组合的EID创建一组规则，而只有一个具有OR关系的规则。因此，不能再写（A和B）或（C和D）形式的条件。根据过滤后的流，此事实可能不会带来任何明显的优势，但也会带来明显的结果。其他免费的基本活动提供商
在本节中，首先，我想谈谈ETW（Windows事件跟踪）机制。 Windows和Sysmon内置日志均使用此机制记录事件。实际上，对于系统中的每个动作，我们都可以得到一个事件。查看此类事件潜在数量的最简单方法是启用“事件查看器-视图-显示分析和调试日志”选项。为了使事件不会立即填满系统，每个日志在其上下文菜单中分别被激活。您看这种良善，不由自主地问自己一个问题-为什么我们需要拥有如此众多事件的Sysmon？事实是，首先，这些日志最初旨在调试，而不是出于安全目的。因此，不提供它们的集中收集。特别是，在任何地方都找不到在其上创建主机的FQDN。当然，这个问题可以由第三方实用程序解决，从小到大，从脚本到成熟的日志记录服务。但是您需要记住，这是大型企业中的附加软件，因此是一项单独的任务。让我提醒您，在介绍中，我们从极简主义原则着手进行了安装软件的其他活动。其次，这些日志报告了每次打喷嚏的详细信息，以至于它们也必须一点一点地选择信息。日记帐分录确实是原子性的，需要事先进行关联或充实，以使分析人员高效地工作。毕竟，使用这些事件调试其创作的程序员都知道一切应该如何工作。而且，尤其是广泛使用的安全防护人员，在更高的抽象层次上进行思考。是的，此外，它还会搜索未知的非法活动。对问题的这种陈述导致将执行预处理的附加软件模块。这将再次使我们的概念复杂化。尽管我们使用Windows进行日志记录还很遥远，但我们不会忘记提及WMI。该工具基本上捕获状态更改，而不显示其源。作为一个例外的示例，加载dll：显示dll模块本身以及正在加载它的进程。但是出于安全目的，此事件还需要进行扩充，因为这是耗尽其信息的地方。通常，无鱼和癌症是鱼。但是该工具只能作为额外工具使用。osquery是另一个流行的选项，但本文未涉及。。我们之所以不在此考虑此解决方案的两个主要原因是，与其他选项（包括完整的数据库）相比，产品更新的频率较低（在安全性和功能性方面都减少了）以及对系统资源的使用增加了。据推测，该解决方案非常适合为其开发的服务器。但是对于工作站，可能具有过时的硬件-几乎没有。最近，出现了更多的工具，其使用范围不如所考虑的那样广泛。这些包括Velociraptor和SilkETW。他们不发明自行车，也可以使用Windows标准-ETW。考虑到已经引用的材料量，决定将这些工具分成单独的出版物（有时间和精力，也有需求感）。一般结论
在比较过程中，发现具有类似物的Sysmon事件通常在功能特征方面优于Windows事件。某些Sysmon事件根本没有其他选择。但是，请不要忘记，首先，必须根据您的任务选择解决方案。如果您只是构建一个监视系统，并且计划在第一年实施Gartner遗赠的检测七到十个事件的方法，那么您应该有足够的Windows事件。也许一年多了。其次，Windows事件日志记录系统也在不断更新，在撰写本文期间，出现了Windows EID（例如4798和4799），也有可能对字段集进行了补充。因此，这种比较虽然是最完整的，但根据我们掌握的信息，并不是一成不变的。第三，Sysmon仍然是一个外部工具，存在许多风险。例如，在某些情况下，个别EID的日志记录被终止而没有说明原因。在这种情况下，其他事件的记录照常进行。更加著名的同事声称，该问题与10.41版中的内存泄漏有关。但是版本10.42中已完全或部分解决了此问题（对于Sysmon的变更日志，一切都没有那么详细），没有解决我们在这个方向上的问题。只有卸载安装组件才有帮助。一切安全，祝您有美好的一天！感谢帖木儿Zinint为准备出版物提供帮助。UPD1：事实证明，维护正常的更改日志或在主要描述中添加新功能确实非常困难，因此我们发现（谢谢，Dim叔叔。ud），一辆带有nishtyaks的卡车在我们的街道上已经移交了9个月 ...摘要：在Sysmon中，您可以（A和B）或（C和D）做……