Windows系统安全事件记录问题

Windows操作系统具有相当不错的安全事件日志记录系统。 在各种出版物和评论中已经为她写了很多好东西，但是本文将涉及其他内容。 在这里，我们讨论该系统中的问题和不足。 所考虑的一些问题将是非关键性的，只会使事件分析过程变得复杂，而其他问题将带来非常严重的安全威胁。

已确定的问题已在Windows 7 Maximum（俄语版），Windows 7 Professional（英语版），Windows 10 Pro（俄语版），Windows Server 2019 Datacenter（俄语版）上进行了测试。 所有操作系统均已完全更新。

问题1.审核参数管理系统失败

在Windows 7/10 / Server 2019上已确认该问题。

问题描述

使用Windows 7并使用默认设置进行安装。 我们不会输入域。 让我们看看安全事件审核设置。 为此，请打开“本地安全策略”管理单元（secpol.msc，或控制面板->管理工具->本地安全策略），然后查看基本审核设置（“安全设置->本地策略->审核策略”） ）



如您所见，审计未配置。 现在，让我们看一下高级审核策略（“安全设置->高级审核策略配置->系统审核策略-本地组策略对象”）。



此处也未配置审核。 如果是这样，那么理论上日志中应该没有任何安全事件。 我们检查。 打开安全日志（eventvwr.exe，或“控制面板->管理工具->查看事件”）。



问题：“如果根本没有配置审核，则事件从安全日志中何处来？”

解说

要了解这种现象的原因，您需要获得操作系统的“内幕”。 首先，我们将处理基本和高级审核政策。

在Windows Vista之前，只有一种审核策略，现在称为基本策略。 问题在于当时的审计管理粒度非常低。 因此，如果需要跟踪对文件的访问，则它们包括基本策略“审核对对象的访问”类别。 结果，除了文件操作之外，安全日志中还涌入了许多其他“噪音”事件。 这极大地复杂了日志和不安的用户的处理。

微软听到了这种“痛苦”，并决定提供帮助。 问题是Windows建立在向后兼容的概念上，而对现有审核管理机制进行更改可能会破坏这种兼容性。 因此，供应商采取了另一种方式。 他创建了一个新工具，并将其称为“高级审核策略”。

该工具的实质是从基本审核策略的类别中制定高级策略的类别，然后依次将其分为可分别打开和关闭的子类别。 现在，如果您需要跟踪高级审核策略中对文件的访问，则只需激活“文件系统”子类别，该子类别包含在“对象访问”类别中。 同时，与访问注册表或网络流量过滤有关的“噪音”事件将不包括在安全日志中。

基本审计策略和扩展审计的类别名称不一致，这在整个计划中造成了极大的混乱，乍一看，这些似乎是完全不同的事物，但事实并非如此。

这是审计管理的基本和高级类别名称的符合性表

重要的是要理解基本类别和高级类别本质上都控制着同一件事。 包含基本审核策略类别会导致包含相应的扩展审核策略类别，并因此包含所有子类别。 为避免意外的后果， Microsoft不建议同时使用基本和高级审核策略。

现在是时候确定审核设置的存储位置了。 首先，我们介绍一些概念：

1. 有效的审核策略 -存储在RAM中的信息，用于确定实现审核功能的操作系统模块的当前操作参数。
2. 保存的审核策略 -信息存储在注册表中的HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv中，用于在系统重启后确定有效的审核策略。

我们将考虑各种管理工具，并指示它们显示哪些审计参数以及设置哪些审计参数。 表格中的数据基于实验。

让我们用示例解释表。

例子1

如果运行auditpol以查看审核设置：
auditpol /get /category:* ，然后将显示已保存的审计设置，即存储在注册表中的HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv。

例子2

如果运行相同的实用程序，但已经设置了参数：
auditpol /set /category:* ，将更改有效的审核设置和保存的审核设置。

单独的注释要求在“本地安全策略”管理单元的“基本审核策略”中显示审核设置的顺序。 如果安装了相应扩展审核策略的所有子类别，则基本审核策略的类别将显示为已设置。 如果未安装其中至少一个，则该策略将显示为未安装。

例子3

auditpol /set /category:*使用auditpol /set /category:*命令将所有审核子类别设置为Audit Success Mode。 此外，如果转到“本地安全策略”管理单元的“基本审核策略”，则将在每个类别的对面安装成功审核。

例子4

现在，管理员已auditpol /clear命令并重置所有审核设置。 然后，他通过运行auditpol /set /subcategory:" "设置文件系统审核。 现在，如果您转到“本地安全策略”管理单元的“基本审核策略”，则所有类别都将被定义为“无审核”状态，因为没有完全定义扩展审核策略的单个类别。

现在，最后，我们可以回答新安装的操作系统中日志来自何处的问题。 事实是，安装后，在Windows中的审核是在保存的审核设置中配置和定义的。 您可以通过运行auditpol /get /category:*命令来验证这一点。



在“本地安全策略”管理单元的“基本审核策略”中，由于未在所有类别中都定义一个或多个子类别，因此不会显示此审核信息。 在“本地安全策略”管理单元的“高级审核策略”中，由于管理单元仅与％SystemRoot％\ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit \ audit.csv文件中存储的审核设置一起使用，因此不会显示此信息。

问题的实质是什么？

乍一看，这似乎根本不是问题，但不是。 所有工具以不同的方式显示审计参数的事实为恶意操纵策略以及结果审计结果创造了机会。

考虑可能的情况

让基于Windows 7的技术工作站在公司网络中工作。

该计算机不包含在域中，它执行自动将每日报告发送给监管机构的机器人的功能。 攻击者以一种或多种方式以管理员权限对其进行远程访问。 同时，攻击者的主要目标是间谍活动，其任务是保持系统中未被检测到的状态。 攻击者秘密地决定在安全日志中不应该使用代码为4719“审核策略更改”的事件来禁用文件访问审核，但是同时所有管理工具都说启用了审核。 为了完成任务，他们执行了以下操作：

1. 在受攻击的工作站上，他们授予自己对HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv注册表项的写权限，并将此项导出到名为“ + fs.reg”的文件中。
2. 我们将此文件导入另一台计算机上，重新启动，然后使用auditpol关闭文件系统的审计，然后将上述注册表项导出到“ -fs.reg”文件中。
3. 在受攻击的计算机上，文件“ -fs.reg”已导入注册表。
4. 我们制作了位于受攻击机器上的％SystemRoot％\ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv文件的备份副本，然后从其中删除了File System子类别。
5. 他们重新启动了受攻击的工作站，然后用先前保存的备份副本替换了文件％SystemRoot％\ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv，并且还导入了文件“ + fs.reg”

所有这些操作的结果是，安全日志中没有策略更改条目，所有工具都显示已启用审核，但实际上它不起作用。

问题2。删除文件，目录和注册表项的操作记录失败

在Windows 7/10 / Server 2019上已确认该问题。

问题描述

对于删除文件，目录或注册表项的一项操作，操作系统将生成一系列事件，代码为4663和4660 。 问题是，从事件的整体来看，这对夫妇之间的联系并不容易。 为此，所分析的事件必须具有以下参数：

事件1。代码4663“试图访问该对象。” 事件参数：
“ ObjectType” =文件。
“ ObjectName” =要删除的文件或目录的名称。
“ HandleId” =要删除的文件的句柄。
“ AcessMask” = 0x10000（此代码对应于DELETE操作。您可以在Microsoft网站上找到所有操作代码的解密）。



事件2。代码4660“对象已删除”。
事件参数：

“ HandleId” =“ HandleId事件1”
“ System \ EventRecordID” =“来自事件1的System \ EventRecordID” + 1。



除去注册表项（键）后，一切都一样，只是在代码为4663的第一个事件中，参数“ ObjectType” =键。

请注意，注册表中值的删除由另一个事件（代码4657 ）描述，不会引起此类问题。

在Windows 10和Server 2019中删除文件的功能

在Windows 10 / Server 2019中，有两种删除文件的方法。

1. 如果将文件删除到回收站，则事件序列4663和4660与以前一样。
2. 如果文件被永久删除（粘贴在回收站中），则发生单个事件，代码为4659 。

发生了一件奇怪的事。 如果要更早地确定删除的文件，则有必要监视事件4663和4660的总数，而现在Microsoft已经“满足用户”，现在需要监视三个事件，而不是两个事件。 还值得注意的是，删除目录的过程没有更改；它像以前一样由两个事件4663和4660组成。

问题的实质是什么？

问题是找出谁删除了文件或目录成为一项艰巨的任务。 代替平常在安全日志中搜索相应的事件，有必要分析事件的顺序，这很费力。 在habr上甚至有一篇文章： “对删除和访问文件进行审核，并使用Powershell在日志文件中记录事件 。 ”

问题编号3（严重）。 文件，目录和注册表项的重命名操作记录失败

在Windows 7/10 / Server 2019上已确认该问题。

问题描述

此问题有两个子问题：

1. 在系统重命名期间生成的事件中，新对象名称在任何地方都不会固定。
2. 重命名过程与删除非常相似。 只能通过以下事实来区分：具有代码4663和参数“ AcessMask” = 0x10000（DELETE）的第一个事件没有事件4660。

值得注意的是，关于注册表，此问题仅适用于密钥。 重命名注册表中的值是由一系列事件4657来描述的，并且不会引起此类投诉，但是，当然，如果只有一个事件会更方便。

问题的实质是什么？

除了搜索文件重命名操作的困难外，日记功能还不允许跟踪文件系统对象或注册表项的完整生命周期。 结果，在活动使用的文件服务器上确定已多次重命名的文件的历史记录变得极为困难。

问题编号4（严重）。 无法跟踪目录和注册表项的创建

在Windows 7/10 / Server 2019上已确认该问题。

问题描述

Windows不会跟踪文件系统目录和注册表项的创建。 这包含以下事实：操作系统不会生成包含创建的目录或注册表项的名称的事件，并且该事件的参数将表明这是创建操作。

从理论上讲，通过间接符号可以创建目录。 例如，如果它是通过“资源管理器”创建的，则在创建过程中，将为新目录的属性生成轮询事件。 问题是，如果通过mkdir命令创建目录，那么根本不会生成任何事件。 对于在注册表中创建键，都是一样的。

问题的实质是什么？

此问题使调查信息安全事件非常困难。 对于该信息未记录在日志中的事实，没有合理的解释。

问题编号5（严重）。 俄语版本的Windows中的审核设置错误

Windows 7/10 / Server 2019的俄语版本上确认了问题的存在。

问题描述

俄语版本的Windows中存在一个错误，导致安全审核管理系统无法正常工作。

病征

更改高级安全策略不会影响有效的审核设置，换句话说，不会应用该策略。 例如，管理员激活了“登录”子类别，重新启动了系统，运行了auditpol /get /category:*命令，并且该子类别保持auditpol /get /category:* 。 该问题与通过组策略管理的域计算机和使用通过“本地安全策略”管理单元配置的本地GPO管理的非域计算机有关。

原因

如果管理员激活了高级审核策略的“失败”子类别中的至少一个，就会出现问题。 这些失败的类别尤其包括：

1. 权利的使用->审核影响机密数据的权利的使用。 向导：{0cce9228-69ae-11d9-bed3-505054503030}。
2. 权利的使用->审核不影响机密数据的权利的使用。 向导：{0cce9229-69ae-11d9-bed3-505054503030}。
3. 访问对象->审核应用程序创建的事件。 向导：{0cce9222-69ae-11d9-bed3-505054503030}。

解决问题的建议

如果问题尚未发生，请不要激活指示的“失败”子类别。 如果这些子类别的事件非常必要，请使用auditpol实用程序激活它们或使用基本策略来管理审计。

如果发生问题，您必须：

1. 从域组策略目录中，删除文件\ Machine \ microsoft \ Windows nt \ Audit \ audit.csv
2. 从所有存在审核问题的计算机上，删除以下文件：％SystemRoot％\ security \ audit \ audit.csv，％SystemRoot％\ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

问题的实质是什么？

此问题的存在减少了可以通过高级审核策略定期监视的安全事件的数量，并且还带来了威胁，以断开，阻止和破坏公司网络中审核系统的管理。

问题编号6（严重）。 该死的“ New text document.txt ...以及New bitmap.bmp”

该问题已在Windows 7上得到确认。Windows 10 / Server 2019中缺少该问题。

问题描述

这是一个偶然发现的非常奇怪的问题。 问题的实质是操作系统存在漏洞，可让您绕过创建文件的审核。

准备部分：

1. 采取新安装的Windows 7。
2. 使用auditpol /clear命令重置所有审核设置。 该项目是可选的，仅用于方便分析杂志。
3. 我们通过运行auditpol /set /subcategory:" "设置文件系统审核。
4. 让我们创建C：\ TEST目录，并为“所有”帐户分配审核参数：“创建文件/写入数据”，“创建文件夹/写入数据”，“写入属性”，“写入其他属性”，“删除子文件夹和文件”，“删除”，“权限更改”，“所有权更改”，即与将数据写入文件系统有关的所有内容。

为了清楚起见，在每次实验之前，我们都会清除操作系统的安全日志。

实验1。
我们做：

从命令行执行命令： echo > "c:\test\ .txt"
我们观察到：

创建文件后，安全日志中将出现一个代码为4663的事件，其中包含在“ ObjectName”字段中创建的文件名，在“ AccessMask”字段中包含0x2的事件（“写数据或添加文件”）。



要执行以下实验，我们清除文件夹和事件日志。

实验2。
我们做：

通过资源管理器打开C：\ TEST文件夹，然后使用上下文菜单“创建->文本文档”（通过右键单击来调用）创建文件“ New Text Document.txt”。



我们观察到：

此操作未反映在事件日志中！ 此外，如果使用相同的上下文菜单创建“位图”，则不会有任何条目。



实验3。
我们做：

使用资源管理器，打开文件夹C：\ TEST，然后使用上下文菜单“创建-> RTF格式的文档”，通过右键单击调用，创建文件“ RTF.rtf格式的新文档”。

我们观察到：

与通过命令行创建文件的情况一样，日志中将出现一个代码为4663和相应内容的事件。

问题的实质是什么？

当然，创建文本文档或图片并不是特别有害。 但是，如果“资源管理器”能够绕过文件操作的日志记录，则恶意软件将能够做到这一点。

这个问题可能是所有考虑的最重要的问题，因为它严重破坏了文件操作审核结果的可信度。

结论

上面列出的问题并不详尽。 在此过程中，我们设法发现了许多相当小的缺陷，其中包括使用局部常量作为许多事件的参数值，这迫使我们针对操作系统的每种局部化编写分析脚本，将事件代码不合逻辑地划分为含义相近的操作，例如，删除注册表项是事件4663和4660的序列，删除注册表中的值是4657，嗯，甚至是小事情……

公平地说，我们注意到尽管存在所有缺点，但Windows中的安全事件日志记录系统还是有很多积极的方面。 解决此处列出的关键问题可以使政府重新获得更好的安全事件记录解决方案。

再次使WINDOWS安全事件记录！