deardaniel/secdata-raw huggingface dataset:
Elastic SIEM Detection Rules: sysmon eventid12 13 14 registry event

# Sysmon Event ID 12, 13, 14: Registry Events

## Setup

**Caution:** Collecting Sysmon events without a tailored configuration for your environment will cause high data volume. These setup instructions would need significant tuning in order to be production-ready. For more specific configurations, we recommend you to explore the following resources:
 - https://github.com/trustedsec/SysmonCommunityGuide
 - https://github.com/olafhartong/sysmon-modular
 - https://github.com/Neo23x0/sysmon-config

Some detection rules require the use of Sysmon registry events (Event IDs 12, 13, and 14) to detect malicious activity, such as attackers establishing persistence via Registry Run keys, disabling security services, or tampering with system configurations.

To collect these logs, use the [Windows Integration](https://www.elastic.co/docs/current/integrations/windows) and select the `Sysmon Operational` channel on the integration setup page.

## Configuration Example

The following snippet demonstrates the minimal configuration required to enable Sysmon's registry monitoring capabilities. This single configuration block enables Event ID 12 (Registry Object Create and Delete), Event ID 13 (Registry Value Set), and Event ID 14 (Registry Object Renamed). While this will turn on the event logging, it lacks the necessary filtering for a production environment and will generate significant noise. It should be used as a reference and integrated into a more robust configuration, such as those provided in the resources above.

```xml
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
    <EventFiltering>
        <!-- Log all registry events (Covers IDs 12, 13, and 14) -->
        <RegistryEvent onmatch="exclude"></RegistryEvent>
    </EventFiltering>
</Sysmon>
```

## Related Rules

Use the following GitHub search to identify rules that use the events generated by this configuration:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Data+Source%3A+Sysmon%22+AND+%28%22registry+where%22+OR+%22event.category%3Aregistry%22+OR+%22registry.data.strings%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit process creation and command line

# Audit Process Creation And Command Line

## Setup

If leveraging process creation events from the Windows Security log for detections, enabling command line auditing for Windows Event ID 4688 (Process Creation) is required. When enabled, Windows records the full command line of newly created processes in the Security event log.

### Enable Audit Policy via Group Policy

To enable the record of command line in process creation events across a group of servers using Active Directory Group Policies, administrators must enable the `Include command line in process creation events` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Administrative Templates >
System >
Audit Process Creation >
Include command line in process creation events (Enable)
```

Additionally, confirm that the Audit Process Creation policy is enabled:

```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Configuration >
Detailed Tracking >
Audit Process Creation (Success)
```

### Enable Locally

To enable process creation and command line auditing on non-domain-joined servers, follow these steps with Administrative privileges:

1. Enable Process Creation Audit

Run the following command to enable auditing for process creation:
```
auditpol.exe /set /subcategory:"Process Creation" /success:enable /failure:enable
```

2. Enable Command Line Logging

Modify the registry to include command-line details in process creation logs:
```
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f  
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4688**: A new process has been created.
* **4696**: A primary token was assigned to process.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224688%22+OR+%22created-process%22+OR+%224696%22+OR+%22process+where%22+OR+%22event.category%3Aprocess%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit filtering platform packet drop

# Audit Filtering Platform Packet Drop

## Setup

Some detection rules require monitoring Filtering Platform Packet Drop events to detect when network packets are being dropped by the Windows Filtering Platform (WFP). Enabling this setting provides visibility into network traffic that is being blocked, which can be an indicator of malicious activity or network reconnaissance.

**Caution:** Enabling this audit policy can generate a high volume of events. Evaluate the audit policy in a group of servers to measure volume and filter unwanted events before deploying in the entire domain.

### Enable Audit Policy via Group Policy

To enable `Audit Filtering Platform Packet Drop` events across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Filtering Platform Packet Drop` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration > 
Policies > 
Windows Settings > 
Security Settings > 
Advanced Audit Policies Configuration > 
Audit Policies > 
Object Access >
Audit Filtering Platform Packet Drop (Success,Failure)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **5152**: The Windows Filtering Platform blocked a packet.
* **5153**: A more restrictive Windows Filtering Platform filter has blocked a packet.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%225152%22+OR+%22windows-firewall-packet-drop%22+OR+%225153%22%29+language%3ATOML+AND+NOT+%28%22%28for+example%2C+5152%29%22+OR+%22Review+the+event+ID+5152%22+OR+%22e.g.%2C+5152%22%29&type=code)
Elastic SIEM Detection Rules: audit other object access events

# Audit Other Object Access Events

## Setup

Some detection rules require monitoring other object access events to detect unauthorized actions or system modifications. Enabling this setting allows you to monitor operations with scheduled tasks, COM+ objects and indirect object access requests.

### Enable Audit Policy via Group Policy

To enable `Audit Other Object Access Events` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Other Object Access Events` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Windows Settings >
Security Settings >
Advanced Audit Policy Configuration >
Audit Policies >
Object Access >
Audit Other Object Access Events (Success,Failure)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Other Object Access Events" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4671**: An application attempted to access a blocked ordinal through the TBS.
* **4691**: Indirect access to an object was requested.
* **4698**: A scheduled task was created.
* **4699**: A scheduled task was deleted.
* **4700**: A scheduled task was enabled.
* **4701**: A scheduled task was disabled.
* **4702**: A scheduled task was updated.
* **5148**: The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded.
* **5149**: The DoS attack has subsided and normal processing is being resumed.
* **5888**: An object in the COM+ Catalog was modified.
* **5889**: An object was deleted from the COM+ Catalog.
* **5890**: An object was added to the COM+ Catalog.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224671%22+OR+%224691%22+OR+%22indirect-object-access-requested%22+OR+%224698%22+OR+%22scheduled-task-created%22+OR+%224699%22+OR+%22scheduled-task-deleted%22+OR+%224700%22+OR+%22scheduled-task-enabled%22+OR+%224701%22+OR+%22scheduled-task-disabled%22+OR+%224702%22+OR+%22scheduled-task-updated%22+OR+%225148%22+OR+%225149%22+OR+%225888%22+OR+%225889%22+OR+%225890%22%29++language%3ATOML+AND+NOT+%28%22-4691-%22+OR+%2214691%22+OR+%22035889c4%22%29&type=code)
Elastic SIEM Detection Rules: sysmon eventid22 dns query

# Sysmon Event ID 22: DNS Query

## Setup

**Caution:** Collecting Sysmon events without a tailored configuration for your environment will cause high data volume. These setup instructions would need significant tuning in order to be production-ready. For more specific configurations, we recommend you to explore the following resources:
 - https://github.com/trustedsec/SysmonCommunityGuide
 - https://github.com/olafhartong/sysmon-modular
 - https://github.com/Neo23x0/sysmon-config

Some detection rules require the use of Sysmon Event ID 22 (DNS Query) events to detect malicious activity, such as command and control (C2) communications, DNS tunneling, or connections to malicious domains.

To collect these logs, use the [Windows Integration](https://www.elastic.co/docs/current/integrations/windows) and select the `Sysmon Operational` channel on the integration setup page.

## Configuration Example

The following snippet demonstrates the minimal configuration required to enable Event ID 22 (DNS Query). While this will turn on the event logging, it lacks the necessary filtering for a production environment and will generate significant noise. It should be used as a reference and integrated into a more robust configuration, such as those provided in the resources above.

```xml
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
    <EventFiltering>
        <!-- Log all DNS query events -->
        <DnsQuery onmatch="exclude"></DnsQuery>
    </EventFiltering>
</Sysmon>
```

## Related Rules

Use the following GitHub search to identify rules that use the events generated by this configuration:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Data+Source%3A+Sysmon%22+AND+%28%22dns.question.name%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid3 network connection

# Sysmon Event ID 3: Network Connection

## Setup

**Caution:** Collecting Sysmon events without a tailored configuration for your environment will cause high data volume. These setup instructions would need significant tuning in order to be production-ready. For more specific configurations, we recommend you to explore the following resources:
 - https://github.com/trustedsec/SysmonCommunityGuide
 - https://github.com/olafhartong/sysmon-modular
 - https://github.com/Neo23x0/sysmon-config

Some detection rules support the use of Sysmon Event ID 3 (Network Connection) events to detect malicious network activity, such as connections to command and control (C2) servers or data exfiltration.

To collect these logs, use the [Windows Integration](https://www.elastic.co/docs/current/integrations/windows) and select the `Sysmon Operational` channel on the integration setup page.

## Configuration Example

The following snippet demonstrates the minimal configuration required to enable Event ID 3 (Network Connection). While this will turn on the event logging, it lacks the necessary filtering for a production environment and will generate significant noise. It should be used as a reference and integrated into a more robust configuration, such as those provided in the resources above.

```xml
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
    <EventFiltering>
        <!-- Log all network connection events -->
        <NetworkConnect onmatch="exclude"></NetworkConnect>
    </EventFiltering>
</Sysmon>
```

## Related Rules

Use the following GitHub search to identify rules that use the events generated by this configuration:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Data+Source%3A+Sysmon%22+AND+%28%22network+where%22+OR+%22event.category%3Anetwork%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit policy change

# Audit Policy Change

## Setup

Some detection rules require tracking changes to audit policies to detect unauthorized modifications or misconfigurations. Enabling this setting ensures visibility into audit policy changes, helping to maintain compliance and security.

### Enable Audit Policy via Group Policy

To enable `Audit Audit Policy Change` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Audit Policy Change` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Windows Settings >
Security Settings >
Advanced Security Audit Policy Settings >
Audit Policies >
Policy Change >
Audit Audit Policy Change (Success,Failure)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4715**: The audit policy (SACL) on an object was changed.
* **4719**: System audit policy was changed.
* **4817**: Auditing settings on object were changed.
* **4902**: The Per-user audit policy table was created.
* **4904**: An attempt was made to register a security event source.
* **4905**: An attempt was made to unregister a security event source.
* **4906**: The CrashOnAuditFail value has changed.
* **4907**: Auditing settings on object were changed.
* **4908**: Special Groups Logon table modified.
* **4912**: Per User Audit Policy was changed.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224715%22+OR+%22object-audit-policy-changed%22+OR+%224719%22+OR+%22changed-audit-config%22+OR+%224817%22+OR+%22object-audit-changed%22+OR+%224902%22+OR+%22user-audit-policy-created%22+OR+%224904%22+OR+%22security-event-source-added%22+OR+%224905%22+OR+%22security-event-source-removed%22+OR+%224906%22+OR+%22crash-on-audit-changed%22+OR+%224907%22+OR+%22audit-setting-changed%22+OR+%224908%22+OR+%22special-group-table-changed%22+OR+%224912%22+OR+%22per-user-audit-policy-changed%22%29++language%3ATOML+AND+NOT+%28%22-4715-%22+OR+%224715d20eb204%22+OR+%22-4907-%22+OR+%22D[PII_REDACTED]7%22%29&type=code)
Elastic SIEM Detection Rules: audit handle manipulation

# Audit Handle Manipulation

## Setup

Some detection rules require monitoring handle manipulation to detect unauthorized access attempts or suspicious interactions with system objects. Enabling this setting helps improve security visibility by tracking when handles to objects (such as files, registry keys, or processes) are opened or modified.

**Caution:** Enabling this audit policy can generate a high volume of events. Evaluate the audit policy in a group of servers to measure volume and filter unwanted events before deploying in the entire domain.

### Enable Audit Policy via Group Policy

To enable `Audit Handle Manipulation` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Handle Manipulation` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Windows Settings >
Security Settings >
Advanced Audit Policy Configuration >
Audit Policies >
Object Access >
Audit Handle Manipulation (Success,Failure)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Handle Manipulation" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4658**: The handle to an object was closed.
* **4690**: An attempt was made to duplicate a handle to an object.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224658%22+OR+%22handle-closed-object%22+OR+%224690%22+OR+%22duplicate-handle-attempt%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit logon

# Audit Logon

## Setup

Some detection rules require monitoring logon events to track user authentication attempts, detect unauthorized access, and investigate security incidents. Enabling this setting provides visibility into successful and failed logon attempts, helping strengthen security and compliance.

### Enable Audit Policy via Group Policy

To enable `Audit logon` events across a group of servers using Active Directory Group Policies, administrators must enable the `Audit logon` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Policies Configuration >
Audit Policies >
Logon/Logoff >
Audit Logon (Success,Failure)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Logon" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4624**: An account was successfully logged on.
* **4625**: An account failed to log on.
* **4648**: A logon was attempted using explicit credentials.
* **4675**: SIDs were filtered.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224624%22+OR+%22logged-in%22+OR+%224625%22+OR+%22logon-failed%22+OR+%224648%22+OR+%22logged-in-explicit%22+OR+%224675%22+OR+%22sids-filtered%22%29++language%3ATOML+AND+NOT+%28%22%28for+example%2C+4624%29%22+OR+%22Review+the+event+ID+4624%22+OR+%22e.g.%2C+4624%22+OR+%22Correlate+security+events+4662+and+4624%22%29&type=code)
Elastic SIEM Detection Rules: sysmon eventid11 file create

# Sysmon Event ID 11: File Create

## Setup

**Caution:** Collecting Sysmon events without a tailored configuration for your environment will cause high data volume. These setup instructions would need significant tuning in order to be production-ready. For more specific configurations, we recommend you to explore the following resources:
 - https://github.com/trustedsec/SysmonCommunityGuide
 - https://github.com/olafhartong/sysmon-modular
 - https://github.com/Neo23x0/sysmon-config

Some detection rules support the use of Sysmon Event ID 11 (File Create) events to detect malicious activity, such as tool transfer and second-stage payload dropping.

To collect these logs, use the [Windows Integration](https://www.elastic.co/docs/current/integrations/windows) and select the `Sysmon Operational` channel on the integration setup page.

## Configuration Example

The following snippet demonstrates the minimal configuration required to enable Event ID 11 (File Create). While this will turn on the event logging, it lacks the necessary filtering for a production environment and will generate significant noise. It should be used as a reference and integrated into a more robust configuration, such as those provided in the resources above.

```xml
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
    <EventFiltering>
        <!-- Log all file creation events -->
        <FileCreate onmatch="exclude"></FileCreate>
    </EventFiltering>
</Sysmon>
```

## Related Rules

Use the following GitHub search to identify rules that use the events generated by this configuration:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Data+Source%3A+Sysmon%22+AND+%28%22file+where%22+OR+%22event.category%3Afile%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit security system extension

# Audit Security System Extension

## Setup

Some detection rules require monitoring security system extensions to detect unauthorized modifications, such as the installation of new system services, drivers, or security-related components. Enabling this setting helps ensure visibility into critical system changes that could impact security and system integrity.

### Enable Audit Policy via Group Policy

To enable `Audit Security System Extension` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Security System Extension` policy. Follow these steps to configure the audit policy via Advanced Audit Policy Configuration:

```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Policies Configuration >
Audit Policies >
System >
Audit Security System Extension (Success)
```

### Enable Locally using auditpol

To enable this policy on a local machine, run the following command in an elevated command prompt:

```
auditpol.exe /set /subcategory:"Security System Extension" /success:enable /failure:enable
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated:

* **4610**: An authentication package has been loaded by the Local Security Authority.
* **4611**: A trusted logon process has been registered with the Local Security Authority.
* **4614**: A notification package has been loaded by the Security Account Manager.
* **4622**: A security package has been loaded by the Local Security Authority.
* **4697**: A service was installed in the system.

## Related Rules

Use the following GitHub search to identify rules that use the events listed:

[Elastic Detection Rules Github Repo Search](https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+%22Windows+Security+Event+Logs%22+AND+%28%224610%22+OR+%22authentication-package-loaded%22+OR+%224611%22+OR+%22trusted-logon-process-registered%22+OR+%224614%22+OR+%22notification-package-loaded%22+OR+%224622%22+OR+%22security-package-loaded%22+OR+%224697%22+OR+%22service-installed%22%29++language%3ATOML&type=code)