deardaniel/secdata-raw huggingface dataset:
Elastic SIEM Detection Rules: audit detailed file share

# Audit Detailed File Share

## Setup

Some detection rules require monitoring file share access to detect unauthorized access attempts or modifications. Enabling this setting helps improve security visibility and ensures compliance by tracking access to shared files and folders.

**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 Detailed File Share` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Detailed File Share` 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 Detailed File Share (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:"File Share" /success:enable /failure:disable
```

## Event IDs

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

* **5145**: A network share object was checked to see whether client can be granted desired access.

## 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%225145%22+OR+%22network-share-object-access-checked%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid7 image loaded

# Sysmon Event ID 7: Image Loaded

## 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 7 (Image Loaded) events to detect malicious activity, such as the loading of malicious DLLs.

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 7 (Image Loaded). 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 image load events -->
        <ImageLoad onmatch="exclude"></ImageLoad>
    </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%22Image+loaded%22+OR+%22event.category%3Alibrary%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid17 18 pipe event

# Sysmon Event ID 17, 18: Pipe 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 named pipe events (Event IDs 17 and 18) to detect malicious activity, such as lateral movement techniques employed by tools like Cobalt Strike or Metasploit.

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 named pipe monitoring capabilities. This single configuration block enables Event ID 17 (Pipe Created) and Event ID 18 (Pipe Connected). 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 named pipe events (Covers IDs 17 and 18) -->
        <PipeEvent onmatch="exclude"></PipeEvent>
    </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%22event.code+%3D%3D+%5C%2217%5C%22%22+OR+%22event.code%3A%5C%2217%5C%22%22+OR+%22event.code%3A17%22+OR+%22event.code+%3D%3D+%5C%2218%5C%22%22+OR+%22event.code%3A%5C%2218%5C%22%22+OR+%22event.code%3A18%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid2 file creation time changed

# Sysmon Event ID 2: File Creation Time Changed

## 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 2 (File Creation Time Changed) events to detect timestomping activity, a technique often used by adversaries to hide their tracks.

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 2 (File Creation Time Changed). 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 time change events -->
        <FileCreateTime onmatch="exclude"></FileCreateTime>
    </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%22event.code+%3D%3D+%5C%222%5C%22%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit computer account management

# Audit Computer Account Management

## Setup

Some detection rules require monitoring computer account management events to track changes to computer accounts in the domain. Enabling this setting provides visibility into when computer accounts are created, changed, or deleted, which is crucial for detecting potential malicious activity like adding unauthorized computer accounts.

### Enable Audit Policy via Group Policy

To enable `Audit Computer Account Management` events across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Computer Account Management` 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 >
Account Management >
Audit Computer Account Management (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:"Computer Account Management" /success:enable /failure:enable
```

## Event IDs

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

* **4741**: A computer account was created.
* **4742**: A computer account was changed.
* **4743**: A computer account was deleted.

## 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%224741%22+OR+%22added-computer-account%22+OR+%224742%22+OR+%22changed-computer-account%22+OR+%224743%22+OR+%22deleted-computer-account%22%29+language%3ATOML+AND+NOT+%28%22%28for+example%2C+4741%29%22+OR+%22Review+the+event+ID+4741%22+OR+%22e.g.%2C+4741%22%29&type=code)
Elastic SIEM Detection Rules: audit authorization policy change

# Audit Authorization Policy Change

## Setup

Some detection rules require monitoring changes to authorization policies to detect unauthorized modifications or misconfigurations. Enabling this setting ensures visibility into changes affecting user rights and security policies, helping maintain compliance and security.

**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 Authorization Policy Change` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Authorization Policy Change` 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 >
Policy Change >
Audit Authorization 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:"Authorization Policy Change" /success:enable /failure:enable
```

## Event IDs

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

* **4703**: A user right was adjusted.
* **4704**: A user right was assigned.
* **4705**: A user right was removed.
* **4670**: Permissions on an object were changed.
* **4911**: Resource attributes of the object were changed.
* **4913**: Central Access Policy on the object 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%224703%22+OR+%22Token+Right+Adjusted+Events%22+OR+%224704%22+OR+%22user-right-assigned%22+OR+%224705%22+OR+%22user-right-removed%22+OR+%224670%22+OR+%22permissions-changed%22+OR+%224911%22+OR+%224913%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid8 createremotethread

# Sysmon Event ID 8: Create Remote Thread

## 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 use Sysmon Event ID 8 (Create Remote Thread) to detect process injection techniques. Attackers often use process injection to evade defenses, escalate privileges, or execute malicious code in the context of another process, such as for credential dumping.

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 8 (Create Remote Thread). 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 remote thread creation events -->
        <CreateRemoteThread onmatch="exclude"></CreateRemoteThread>
    </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%22event.code+%3D%3D+%5C%228%5C%22%22+OR+%22event.code%3A%5C%228%5C%22%22+OR++%22event.code%3A8%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid19 20 21 wmi event

# Sysmon Event ID 19, 20, 21: WMI 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 WMI events (Event IDs 19, 20, and 21) to detect malicious activity, such as attackers using WMI for persistence or lateral movement.

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 WMI monitoring capabilities. This single configuration block enables Event ID 19 (WmiEventFilter), Event ID 20 (WmiEventConsumer), and Event ID 21 (WmiEventConsumerToFilter). 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 WMI events (Covers IDs 19, 20, and 21) -->
        <WmiEvent onmatch="exclude"></WmiEvent>
    </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%22event.code+%3D%3D+%5C%2219%5C%22%22+OR+%22event.code%3A%5C%2219%5C%22%22+OR+%22event.code%3A19%22+OR+%22event.code+%3D%3D+%5C%2220%5C%22%22+OR+%22event.code%3A%5C%2220%5C%22%22+OR+%22event.code%3A20%22+OR+%22event.code+%3D%3D+%5C%2221%5C%22%22+OR+%22event.code%3A%5C%2221%5C%22%22+OR+%22event.code%3A21%22+OR+%22winlog.event_data.Consumer+%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid23 file delete

# Sysmon Event ID 23: File Delete

## 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 23 (File Delete) events to detect malicious activity, such as an attacker attempting to cover their tracks by deleting tools or logs.

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 23 (File Delete). 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 delete events -->
        <FileDelete onmatch="exclude"></FileDelete>
    </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%22event.type+%3D%3D+%5C%22deletion%5C%22%22%29&type=code)
Elastic SIEM Detection Rules: sysmon eventid10 process access

# Sysmon Event ID 10: Process Access

## 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 10 (Process Accessed) events to detect malicious activity, such as credential dumping from `lsass.exe`.

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 example demonstrates a more targeted approach for Event ID 10 by focusing specifically on attempts to access the `lsass.exe` process. Based on https://github.com/Neo23x0/sysmon-config/blob/1fdc5f837e06bcf95a42f0c8d49ea311fde628a3/sysmonconfig-export.xml#L517C4-L520C11

```xml
<Sysmon schemaversion="4.90">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
    <EventFiltering>
        <ProcessAccess onmatch="include">
            <Rule groupRelation="and">
		        <TargetImage condition="end with">\lsass.exe</TargetImage>
		        <GrantedAccess condition="contains any">0x40;0x1000;0x1010;0x1038;0x1410;0x1418;0x1438;0x143a;0x100000;0x1f0fff;0x1f1fff;0x1f2fff;0x1f3fff;0x1fffff</GrantedAccess> <!--0x1400 too noisy-->
	        </Rule>
        </ProcessAccess>
    </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%22event.code+%3D%3D+%5C%2210%5C%22%22+OR+%22winlog.event_data.TargetImage%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit directory service access

# Audit Directory Service Access

## Setup

Some detection rules require configuring audit policies to generate events when Active Directory objects are accessed. These audit policies apply exclusively to Domain Controllers, as other servers do not produce events related to Active Directory object modifications.

**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 Directory Service Access` on all Domain Controllers via Group Policy, administrators must enable the `Audit Directory Service Access` 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 >
DS Access >
Audit Directory Service Access (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:"Directory Service Access" /success:enable /failure:enable
```

## Event IDs

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

* **4661**: A handle to an object was requested.
* **4662**: An operation was performed on 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%224661%22+OR+%224662%22+OR+%22object-operation-performed%22%29++language%3ATOML&type=code)