Yamato-Security/sigma-to-hayabusa-converter
GitHub: Yamato-Security/sigma-to-hayabusa-converter
将上游 Sigma 规则的 logsource 字段去抽象化并转换为 Hayabusa 兼容格式，使其同时支持 Windows 内置日志和 Sysmon 日志的威胁检测。
Stars: 15 | Forks: 0
# Windows 事件日志 Sigma 规则策展
[**English**] | [\[日本語\]](README-Japanese.md)
[](https://www.python.org/)
# 目录
- [Windows 事件日志 Sigma 规则策展](#curation-of-sigma-rules-for-windows-event-logs)
- [目录](#table-of-contents)
- [关于本仓库](#about-this-repository)
- [TLDR (太长不看)](#tldr)
- [上游针对 Windows 事件日志的 Sigma 规则面临的挑战](#challenges-with-upstream-sigma-rules-for-windows-event-logs)
- [关于 `logsource` 字段](#about-the-logsource-field)
- [Service 字段](#service-fields)
- [单通道示例：](#single-channel-example)
- [多通道示例：](#multiple-channel-example)
- [当前 service 映射列表](#current-list-of-service-mappings)
- [Service 映射来源](#service-mapping-sources)
- [Category 字段](#category-fields)
- [Category 字段示例：](#category-field-example)
- [当前 category 映射列表](#current-list-of-category-mappings)
- [Category 字段面临的挑战](#category-field-challenges)
- [Category 映射来源](#category-mapping-sources)
- [抽象日志源的好处与挑战](#benefits-and-challenges-of-abstracting-the-log-source)
- [日志源抽象的好处：](#log-source-abstraction-benefits)
- [日志源抽象的挑战：](#log-source-abstraction-challenges)
- [转换示例](#conversion-example)
- [转换前](#before-conversion)
- [转换后](#after-conversion)
- [转换共性](#conversion-commonalities)
- [转换限制](#conversion-limitations)
- [Sysmon 与内置事件对比及规则转换](#sysmon-and-built-in-event-comparison-and-rule-conversion)
- [进程创建](#process-creation)
- [对比：](#comparison)
- [转换说明：](#conversion-notes)
- [其他说明：](#other-notes)
- [内置日志设置](#built-in-log-settings)
- [通过组策略启用](#enabling-with-group-policy)
- [在命令行中启用](#enabling-on-the-command-line)
- [网络连接](#network-connection)
- [对比：](#comparison-1)
- [转换说明：](#conversion-notes-1)
- [内置日志设置](#built-in-log-settings-1)
- [通过组策略启用](#enabling-with-group-policy-1)
- [在命令行中启用](#enabling-on-the-command-line-1)
- [Sigma 规则编写建议](#sigma-rule-writing-advice)
- [预转换的 Sigma 规则](#pre-converted-sigma-rules)
- [工具环境](#tool-environment)
- [工具使用](#tool-usage)
- [作者](#authors)
# 关于本仓库
本仓库包含 Yamato Security 如何策展上游 [Sigma](https://github.com/SigmaHQ/sigma) 规则以用于 Windows 事件日志的文档。我们通过将 `logsource` 字段去抽象化，并使用 `sigma-to-hayabusa-converter.py` 工具过滤掉任何被判定为不可用或难以使用的规则，将其转化为更实用的格式。
该工具主要用于创建托管在 [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules) 上的策展 Sigma 规则集，该规则集被 [Hayabusa](https://github.com/Yamato-Security/hayabusa) 和 [Velociraptor](https://github.com/Velocidex/velociraptor) 所使用。
我们希望这些信息对其他试图使用 Sigma 规则检测 Windows 事件日志中攻击的项目有所帮助。
# TLDR (太长不看)
* 对 `logsource` 字段进行去抽象化，并为内置规则以及基于 Sysmon 的原始规则创建新的 `.yml` 规则文件，使得 Sigma 规则能够更轻松地完全支持内置事件，同时也让分析师更容易阅读这些规则。
* 在编写针对 Windows 事件日志的 Sigma 规则时，重要的是要了解基于 Sysmon 的原始日志与兼容的内置日志之间的差异，最理想的情况是编写同时兼容两者的规则。
* 许多组织无法或不想在所有的 Windows 端点上安装和维护 Sysmon 代理，因为他们没有专门的资源来处理这件事，或者想避免 Sysmon 引起任何减速或崩溃的风险。因此，重要的是要启用尽可能多的内置事件日志，并使用能够在这些内置日志中检测攻击的工具。
# 上游针对 Windows 事件日志的 Sigma 规则面临的挑战
根据我们的经验，为 Windows 事件日志创建原生 Sigma 规则解析器的主要挑战在于支持 `logsource` 字段。
目前，这是 Hayabusa 原生尚未支持的少数功能之一，因为这仍然非常复杂且处于开发阶段。
目前，我们正通过将上游规则转换为更易于使用的格式来绕过这个问题，本文档将对此进行详细说明。
## 关于 `logsource` 字段
在针对 Windows 事件日志的 Sigma 规则中，`product` 字段被设置为 `windows`，随后是 `service` 字段或 `category` 字段。
`service` 字段示例：
```
logsource:
product: windows
service: application
```
`category` 字段示例：
```
logsource:
product: windows
category: process_creation
```
### Service 字段
`service` 字段相对容易处理，它告诉使用该 Sigma 规则的任何后端，基于 Windows XML 事件日志中的 `Channel` 字段去搜索单个通道或多个通道。
#### 单通道示例：
`service: application` 等同于向 Sigma 规则中添加 `Channel: Application` 的选择条件。
#### 多通道示例：
`service: applocker` 目前会生成数量最多的需要搜索的多个通道，因为 Applocker 会将信息保存在四个不同的日志中。为了正确地仅搜索 Applocker 日志，需要在 Sigma 规则逻辑中添加以下条件：
```
Channel:
- Microsoft-Windows-AppLocker/MSI and Script
- Microsoft-Windows-AppLocker/EXE and DLL
- Microsoft-Windows-AppLocker/Packaged app-Deployment
- Microsoft-Windows-AppLocker/Packaged app-Execution
```
#### 当前 service 映射列表
| Service | Channel |
|-----------------------------------------|-------------------------------------------------------------------------------------------------------|
| application | Application |
| application-experience | Microsoft-Windows-Application-Experience/Program-Telemetry, Microsoft-Windows-Application-Experience/Program-Compatibility-Assistant |
| applocker | Microsoft-Windows-AppLocker/MSI and Script, Microsoft-Windows-AppLocker/EXE and DLL, Microsoft-Windows-AppLocker/Packaged app-Deployment, Microsoft-Windows-AppLocker/Packaged app-Execution |
| appmodel-runtime | Microsoft-Windows-AppModel-Runtime/Admin |
| appxpackaging-om | Microsoft-Windows-AppxPackaging/Operational |
| bits-client | Microsoft-Windows-Bits-Client/Operational |
| capi2 | Microsoft-Windows-CAPI2/Operational |
| certificateservicesclient-lifecycle-system | Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational |
| codeintegrity-operational | Microsoft-Windows-CodeIntegrity/Operational |
| diagnosis-scripted | Microsoft-Windows-Diagnosis-Scripted/Operational |
| dhcp | Microsoft-Windows-DHCP-Server/Operational |
| dns-client | Microsoft-Windows-DNS Client Events/Operational |
| dns-server | DNS Server |
| dns-server-analytic | Microsoft-Windows-DNS-Server/Analytical |
| driver-framework | Microsoft-Windows-DriverFrameworks-UserMode/Operational |
| firewall-as | Microsoft-Windows-Windows Firewall With Advanced Security/Firewall |
| hyper-v-worker | Microsoft-Windows-Hyper-V-Worker |
| kernel-event-tracing | Microsoft-Windows-Kernel-EventTracing |
| kernel-shimengine | Microsoft-Windows-Kernel-ShimEngine/Operational, Microsoft-Windows-Kernel-ShimEngine/Diagnostic |
| ldap_debug | Microsoft-Windows-LDAP-Client/Debug |
| lsa-server | Microsoft-Windows-LSA/Operational |
| microsoft-servicebus-client | Microsoft-ServiceBus-Client |
| msexchange-management | MSExchange Management |
| ntfs | Microsoft-Windows-Ntfs/Operational |
| ntlm | Microsoft-Windows-NTLM/Operational |
| openssh | OpenSSH/Operational |
| powershell | Microsoft-Windows-PowerShell/Operational, PowerShellCore/Operational |
| powershell-classic | Windows PowerShell |
| printservice-admin | Microsoft-Windows-PrintService/Admin |
| printservice-operational | Microsoft-Windows-PrintService/Operational |
| security | Security |
| security-mitigations | Microsoft-Windows-Security-Mitigations* |
| shell-core | Microsoft-Windows-Shell-Core/Operational |
| smbclient-connectivity | Microsoft-Windows-SmbClient/Connectivity |
| smbclient-security | Microsoft-Windows-SmbClient/Security |
| system | System |
| sysmon | Microsoft-Windows-Sysmon/Operational |
| taskscheduler | Microsoft-Windows-TaskScheduler/Operational |
| terminalservices-localsessionmanager | Microsoft-Windows-TerminalServices-LocalSessionManager/Operational |
| vhdmp | Microsoft-Windows-VHDMP/Operational |
| wmi | Microsoft-Windows-WMI-Activity/Operational |
| windefend | Microsoft-Windows-Windows Defender/Operational |
#### Service 映射来源
我们创建了 service 到通道名称的 YAML 映射文件，并在此仓库中定期维护和托管它们。
它们基于 [https://github.com/SigmaHQ/sigma/blob/master/tests/thor.yml](https://github.com/SigmaHQ/sigma/blob/master/tests/thor.yml) 中的 service 映射信息，因为尽管这似乎不是一个供人们使用的官方通用配置文件，但它似乎是最新的。
### Category 字段
大多数 `category` 字段除了搜索特定的 `Channel` 外，还会添加一个条件来检查 `EventID` 字段中的特定事件 ID。
类别名称主要基于 [Sysmon](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) 事件，并附加了一些用于内置 PowerShell 日志和 Windows Defender 的类别。
#### Category 字段示例：
```
process_creation:
EventID: 1
Channel: Microsoft-Windows-Sysmon/Operational
```
#### 当前 category 映射列表
| Category | Service | EventIDs |
|------------------------------|---------------------|-------------------------------------------------|
| antivirus | windefend | 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1017, 1018, 1019, 1115, 1116 |
| clipboard_change | sysmon | 24 |
| create_remote_thread | sysmon | 8 |
| create_stream_hash | sysmon | 15 |
| dns_query | sysmon | 22 |
| driver_load | sysmon | 6 |
| file_block_executable | sysmon | 27 |
| file_block_shredding | sysmon | 28 |
| file_change | sysmon | 2 |
| file_creation | sysmon | 11 |
| file_delete | sysmon | 23, 26 |
| file_delete_detected | sysmon | 26 |
| file_executable_detected | sysmon | 29 |
| image_load | sysmon | 7 |
| **network_connection** | sysmon | 3 |
| **network_connection** | security | 5156 |
| pipe_created | sysmon | 17, 18 |
| process_access | sysmon | 10 |
| **process_creation** | sysmon | 1 |
| **process_creation** | security | 4688 |
| process_tampering | sysmon | 25 |
| process_termination | sysmon | 5 |
| ps_classic_provider_start | powershell-classic | 600 |
| ps_classic_start | powershell-classic | 400 |
| ps_module | powershell | 4103 |
| ps_script | powershell | 4104 |
| raw_access_thread | sysmon | 9 |
| **registry_add** | sysmon | 12 |
| **registry_add** | security | 4657 |
| registry_delete | sysmon | 12 |
| **registry_event** | sysmon | 12, 13, 14 |
| **registry_event** | security | 4657 |
| registry_rename | sysmon | 14 |
| **registry_set** | sysmon | 13 |
| **registry_set** | security | 4657 |
| sysmon_error | sysmon | 255 |
| sysmon_status | sysmon | 4 16 |
| wmi_event | sysmon | 19, 20, 21 |
#### Category 字段面临的挑战
您可能已经注意到，同一个 `category` 可以使用多个 service 和事件 ID（**※以粗体表示**）。
这意味着，如果规则使用的字段同样存在于内置事件日志中，就可以将一些为 `sysmon` 设计的 Sigma 规则应用于类似的内置 Windows `security` 事件日志。
在这种情况下，可能需要转换字段名称，有时还需要转换字段值，以匹配内置 `security` 事件日志的字段名称和值。
尽管对于某些类别来说，这可能只是重命名一些字段名称那么简单，但对于其他类别，这可能还需要对字段值进行各种转换。
我们在本文档后面详细介绍了如何进行这种转换以及 `sysmon` 日志和 `security` 日志之间的兼容性。
#### Category 映射来源
类别的 YAML 映射文件也托管在此仓库中，并且同样基于 [https://github.com/SigmaHQ/sigma/blob/master/tests/thor.yml](https://github.com/SigmaHQ/sigma/blob/master/tests/thor.yml) 中的信息。
# 抽象日志源的好处与挑战
由于抽象日志源并在后端为不同的 `Channel`、`EventID` 和字段创建映射，带来了一些好处和挑战。
## 日志源抽象的好处：
1. 在将 Sigma 规则转换为其他后端查询时，将 `Channel` 和 `EventID` 字段名称转换为适当的后端字段名称可能会更容易。
2. 可以将两个规则合并为一个规则。例如，进程创建事件可以记录在 `Sysmon 1` 和 `Security 4688` 中。与其编写两个查看不同通道、事件 ID 和字段但包含相同逻辑的规则，不如将字段标准化为 Sysmon 使用的字段，然后让后端转换器添加 `Channel` 和 `EventID` 字段，并在必要时转换其他字段信息。这使得规则的维护更加容易，因为需要维护的规则更少了。
3. 尽管非常罕见，但如果某个日志源开始在不同的 `Channel` 或 `EventID` 中记录其数据，则只需要更新映射逻辑，而不是更新所有的 Sigma 规则，这使得维护更加容易。
## 日志源抽象的挑战：
1. 如果基于 Sysmon 的原始 Sigma 规则使用了一个在内置日志中不存在的字段来过滤误报，会发生什么？您是应该优先考虑可能的检测而无论如何都创建该规则，还是为了优先减少误报而忽略它？理想情况下，需要创建两个具有不同 `severity`（严重性）、`status`（状态）和误报信息的规则，以便用户更好地处理它。
2. 这使得过滤规则变得更加困难，因为如果文件由于是内置日志的派生规则而不是原始 Sysmon 规则而尚未创建，您就不能仅仅基于 `.yml` 文件或规则文件路径中的 `Channel` 或 `EventID` 字段进行过滤。此外，由于规则 ID 是相同的，您无法根据规则 ID 进行过滤。
3. 当告警来自于由 Sysmon 日志派生的内置日志规则时，会使得确认告警变得更加困难。字段名称和值将不匹配，因此分析师需要理解并记住稍微复杂的转换过程。
4. 这使得创建后端逻辑变得更加复杂。
虽然除了在有足够重要的用例证明值得付出的情况下创建和维护新规则之外，我们对第一个问题无能为力，但为了解决问题 2-4，我们决定对 `logsource` 字段进行去抽象化，并为任何可以产生多个规则的规则创建两套规则。能够在内置日志中检测攻击的规则会输出到 `builtin` 目录，而用于 Sysmon 的规则会输出到 `sysmon` 目录。
# 转换示例
这里有一个简单的例子，可以帮助您更好地理解转换过程。
## 转换前
Sigma 规则：
```
logsource:
category: process_creation
product: windows
detection:
selection:
- Image|endswith: '.exe'
condition: selection
```
## 转换后
兼容 Hayabusa 的 Sysmon 日志规则：
```
logsource:
category: process_creation
product: windows
detection:
process_creation:
Channel: Microsoft-Windows-Sysmon/Operational
EventID: 1
selection:
- Image|endswith: '.exe'
condition: process_creation and selection
```
兼容 Hayabusa 的 Windows 内置日志规则：
```
logsource:
category: process_creation
product: windows
detection:
process_creation:
Channel: Security
EventID: 4688
selection:
- NewProcessName|endswith: '.exe'
condition: process_creation and selection
```
如您所见，创建了两个规则，一个用于 Sysmon 1 日志，另一个用于内置 Security 4688 日志。
添加了一个包含通道和事件 ID 信息的新 `process_creation` 条件，并将该条件添加到了 `condition` 字段中以要求满足此条件。
此外，原始的 `Image` 字段名称已更改为 `NewProcessName`。
# 转换共性
在详细解释我们如何转换特定类别之前，我们将介绍适用于所有规则的转换部分。
1. 任何在 `ignore-uuid-list.txt` 中包含 ID 的规则都将被忽略。目前我们只忽略那些因为包含 `mimikatz` 等关键字而在 Windows Defender 上引起误报的规则。
2. “占位符”规则会被忽略，因为它们无法按原样使用。这些规则放置在 Sigma 仓库[这里](https://github.com/SigmaHQ/sigma/tree/master/rules-placeholder/windows/)的 `rules-placeholder` 文件夹中。
3. 使用不兼容字段修饰符的规则。目前 Hayabusa 支持此处显示的大多数字段修饰符，因此将不会输出任何使用除此列表之外的修饰符的规则，以避免解析错误：
* all
* base64
* base64offset
* cased
* cidr
* contains
* endswith
* endswithfield
* equalsfield
* exists
* fieldref
* gt
* gte
* lt
* lte
* re
* startswith
* utf16
* utf16be
* utf16le
* wide
* windash
4. 存在语法错误的规则将不会被转换。
5. `deprecated`（已弃用）和 `unsupported`（不支持）规则中的标签会从 V1 格式更新为 V2 格式，V2 格式使用 `-` 而不是 `_`，以保持一切一致并更轻松地处理 Hayabusa 中的缩写。示例：`initial_access` 变为 `initial-access`。
6. 由于我们要向规则中添加 `Channel` 和 `EventID` 信息，我们通过使用原始 ID 的 MD5 哈希来创建新的 UUIDv4 ID，并在 `related` 字段中指定原始 ID，将 `type` 标记为 `derived`。对于可以转换为多个规则（`sysmon` 和 `builtin`）的规则，我们还需要为派生的 `builtin` 规则创建新的规则 ID。为此，我们计算 `sysmon` 规则 ID 的 MD5 哈希，并将其用于 UUIDv4 ID。这里有一个示例：
原始 Sigma 规则：
title: 7Zip Compressing Dump Files
id: 1ac14d38-3dfc-4635-92c7-e3fd1c5f5bfc
新 `sysmon` 规则：
title: 7Zip Compressing Dump Files
id: ec570e53-4c76-45a9-804d-dc3f355ff7a7
related:
- id: 1ac14d38-3dfc-4635-92c7-e3fd1c5f5bfc
type: derived
新 `builtin` 规则：
title: 7Zip Compressing Dump Files
id: 93586827-5f54-fc91-0b2f-338fd5365694
related:
- id: 1ac14d38-3dfc-4635-92c7-e3fd1c5f5bfc
type: derived
- id: ec570e53-4c76-45a9-804d-dc3f355ff7a7
type: derived
7. 检测内置 Windows 事件日志中内容的规则输出到 `builtin` 目录，而依赖 Sysmon 日志的规则输出到 `sysmon` 目录，其子目录与上游 Sigma 仓库中的目录相匹配。
# 转换限制
目前只有一个 [bug](https://github.com/Yamato-Security/sigma-to-hayabusa-converter/issues/2)，即 Sigma 规则中的注释行不会包含在输出的规则中，除非这些注释跟在某些源代码之后。
# Sysmon 与内置事件对比及规则转换
## 进程创建
* Category: `process_creation`
* Sysmon
* Channel: `Microsoft-Windows-Sysmon/Operational`
* Event ID: `1`
* 内置日志
* Channel: `Security`
* Event ID: `4688`
### 对比：
### 转换说明：
1. `User` 字段信息需要被分离为 `SubjectUserName` 和 `SubjectDomainName` 字段。
2. `LogonId` 字段名称更改为 `SubjectLogonId`，并且十六进制值中的任何字母都需要变为小写。
3. `ProcessId` 字段名称更改为 `NewProcessId`，并且其值需要转换为十六进制。
4. `Image` 字段名称更改为 `NewProcessName`。
5. `ParentProcessId` 字段名称更改为 `ProcessId`，并且其值需要转换为十六进制。
6. `ParentImage` 字段名称更改为 `ParentProcessName`。
7. `IntegrityLevel` 字段名称更改为 `MandatoryLabel`，并且需要进行以下值转换：
* `Low`: `S-1-16-4096`
* `Medium`: `S-1-16-8192`
* `High`: `S-1-16-12288`
* `System`: `S-1-16-16384`
8. 如果规则包含以下仅存在于 `Security 4688` 事件中的字段，则我们不会创建 `Sysmon 1` 规则：
* `SubjectUserSid`, `TokenElevationType`, `TargetUserSid`, `TargetUserName`, `TargetDomainName`, `TargetLogonId`
9. 如果规则包含以下仅存在于 `Sysmon 1` 事件中的字段，则我们不会创建 `Security 4688` 规则：
* `RuleName`, `UtcTime`, `ProcessGuid`, `FileVersion`, `Description`, `Product`, `Company`, `OriginalFileName`, `CurrentDirectory`, `LogonGuid`, `TerminalSessionId`, `Hashes`, `ParentProcessGuid`, `ParentCommandLine`, `ParentUser`
10. 对于第 8 点和第 9 点有一个例外，即即使使用了仅存在于一个日志事件中的字段，如果该字段处于 `OR` 条件中，您仍然应该创建该规则。例如，以下规则不应生成 `Security 4688` 规则，因为 `OriginalFileName` 字段是必需的。
selection_img:
Image|endswith: \addinutil.exe
OriginalFileName: AddInUtil.exe
但是，具有以下条件的规则应该创建 `Security 4688` 规则，因为 `OriginalFileName` 是可选的。
selection_img:
- Image|endswith: \addinutil.exe
- OriginalFileName: AddInUtil.exe
困难在于，您的解析器不仅要理解选择内部的逻辑，还要理解 `condition` 字段内部的逻辑。因此，例如以下规则**不应**创建 `Security 4688` 规则，因为它使用了 `AND` 逻辑。
selection_img:
Image|endswith: \addinutil.exe
selection_orig:
OriginalFileName: AddInUtil.exe
condition: selection_img and selection_orig
然而，以下规则**应该**创建 `Security 4688` 规则，因为它使用了 `OR` 逻辑。
selection_img:
Image|endswith: \addinutil.exe
selection_orig:
OriginalFileName: AddInUtil.exe
condition: selection_img or selection_orig
### 其他说明：
* `Security 4688` 中的 `SubjectUserSid` 字段显示的是 SID，然而，在呈现的事件日志 `Message` 中，它被转换为 `DOMAIN\User`。
* `Security 4688` 事件可能不会在 `CommandLine` 中包含命令行选项信息，这取决于具体的设置。
* `TokenElevationType` 在 `Message` 中按原样显示，不作呈现。
* `MandatoryLabel` 内部的 `S-1-16-4096` 等内容，在呈现的 `Message` 中会被转换为 `Mandatory Label\Low Mandatory Level` 等。
### 内置日志设置
非常遗憾的是，最重要的内置 `Security 4688` 进程创建事件日志默认并未启用。
您需要同时启用 `4688` 事件并开启命令行选项日志记录，以便使用大多数的 Sigma 规则。
#### 通过组策略启用
* `Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Detailed Tracking > Audit Process Creation`: `Enabled`
* `Administrative Templates > System > Audit Process Creation > Include command line in process creation events`: `Enabled`
#### 在命令行中启用
```
auditpol /set /subcategory:{0CCE922B-69AE-11D9-BED3-505054503030} /success:enable /failure:enable
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /f /t REG_DWORD /d 1
```
## 网络连接
* Category: `network_connection`
* Sysmon
* Channel: `Microsoft-Windows-Sysmon/Operational`
* Event ID: `3`
* 内置日志
* Channel: `Security`
* Event ID: `5156`
### 对比：
### 转换说明：
1. `ProcessId` 字段名称更改为 `ProcessID`。
2. `Image` 字段名称更改为 `Application`，并且 `C:\` 更改为 `\device\harddiskvolume?\`。（注意：由于我们不知道硬盘卷号，我们用单字符通配符 `?` 替换了它。）
3. `` 字段的值 `tcp` 更改为 `6`，`udp` 更改为 `17`。
4. `Initiated` 字段名称更改为 `Direction`，并且值 `true` 更改为 `%%14593`，`false` 更改为 `%%14592`。
5. `SourceIp` 字段名称更改为 `SourceAddress`。
6. `DestinationIp` 字段名称更改为 `DestAddress`。
7. `DestinationPort` 字段名称更改为 `DestPort`。
### 内置日志设置
内置的 `Security 5156` 网络连接日志默认并未启用。
这将会产生大量的日志，可能会覆盖 `Security` 事件中的其他重要日志，并且如果系统有大量的网络连接，可能会导致系统变慢。因此，请确保 `Security` 日志的最大文件大小设置得足够高，并确保经过测试确认对系统没有任何负面影响。
#### 通过组策略启用
* `Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Object Access -> Filtering Platform Connection`: `Success and Failture`
#### 在命令行中启用
```
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
```
或者，如果您使用的是非英语区域设置，请使用以下命令：
```
auditpol /set /subcategory:{0CCE922F-69AE-11D9-BED3-505054503030} /success:enable /failure:enable
```
# Sigma 规则编写建议
如果您使用了任何存在于 `sysmon` 日志但不存在于 `builtin` 日志中的字段，那么请确保将该字段设为可选的，以便该规则仍有可能用于 `builtin` 日志。例如：
```
selection_img:
- Image|endswith: \addinutil.exe
- OriginalFileName: AddInUtil.exe
```
此选择旨在查找进程 (`Image`) 名为 `addinutil.exe` 的情况。问题在于攻击者可以直接重命名文件名来绕过该规则。仅存在于 Sysmon 日志中的 `OriginalFileName` 字段是在编译时嵌入到二进制文件中的文件名。即使攻击者重命名了该文件，嵌入的名称也不会改变。因此，在使用 Sysmon 时，该规则可以检测到攻击者重命名文件的攻击行为，同时也可用于检测在使用标准内置日志时文件名未被更改的攻击行为。
# 预转换的 Sigma 规则
Sigma 规则按照本文档中描述的方式，通过对 `logsource` 字段进行去抽象化进行策展，并托管在 [hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules) 仓库的 `sigma` 文件夹下。
# 工具环境
如果您想在本地将 Sigma 规则转换为兼容 Hayabusa 的格式，您首先需要安装 [Poetry](https://python-poetry.org/)。
关于 Poetry 的安装，请参考以下链接的官方文档：
https://python-poetry.org/docs/#installation
# 工具使用
`sigma-to-hayabusa-converter.py` 是我们的主要工具，用于将 Sigma 规则的 `logsource` 字段转换为兼容 Hayabusa 的格式。
请执行以下任务来运行它。
1. `git clone https://github.com/SigmaHQ/sigma.git`
2. `git clone https://github.com/Yamato-Security/sigma-to-hayabusa-converter.git`
3. `cd sigma-to-hayabusa-converter`
4. `poetry install --no-root`
5. `poetry run python sigma-to-hayabusa-converter.py -r ../sigma -o ./converted_sigma_rules`
执行上述命令后，转换为兼容 Hayabusa 格式的规则将输出到 `./converted_sigma_rules` 目录中。
# 作者
本文档由 Zach Mathis (@yamatosecurity) 创建，并由 Fukusuke Takahashi (@fukusuket) 翻译成日语。
`sigma-to-hayabusa-converter.py` 工具的实现与维护由 Fukusuke Takahashi 完成。
依赖于现已弃用的 sigmac 工具的原始转换工具由 ItiB ([@itiB_S144](https://x.com/itib_s144)) 和 James Takai / hachiyone(@hach1yon) 实现。
标签：AMSI绕过, EDR, OISF, Python, Sigma规则, Sysmon, Windows事件日志, 威胁检测, 安全工程, 数据解析, 无后门, 日志管理, 目标导入, 脆弱性评估, 规则转换, 逆向工具