deardaniel/secdata-raw huggingface dataset:
Elastic SIEM Detection Rules: audit filtering platform connection

# Audit Filtering Platform Connection

## Setup

Some detection rules require monitoring network connections managed by the Windows Filtering Platform (WFP) to detect unauthorized or suspicious network activity.

**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 Connection` across a group of servers using Active Directory Group Policies, administrators must enable the `Audit Filtering Platform Connection` 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 >
Object Access >
Audit Filtering Platform Connection (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 Connection" /success:enable /failure:enable
```

## Event IDs

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

* **5031**: The Windows Firewall Service blocked an application from accepting incoming connections on the network.
* **5150**: The Windows Filtering Platform blocked a packet.
* **5151**: A more restrictive Windows Filtering Platform filter has blocked a packet.
* **5154**: The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections.
* **5155**: The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections.
* **5156**: The Windows Filtering Platform has permitted a connection.
* **5157**: The Windows Filtering Platform has blocked a connection.
* **5158**: The Windows Filtering Platform has permitted a bind to a local port.
* **5159**: The Windows Filtering Platform has blocked a bind to a local port.

## 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%225031%22+OR+%225150%22+OR+%225151%22+OR+%225154%22+OR+%225155%22+OR+%225156%22+OR+%22windows-firewall-connection%22+OR+%225157%22+OR+%22windows-firewall-packet-block%22+OR+%225158%22+OR+%22windows-firewall-bind-local-port%22+OR+%225159%22%29+language%3ATOML+AND+NOT+%28%224605157a5b80%22+OR+%225151a804f31b%22%29&type=code)
Elastic SIEM Detection Rules: audit powershell scriptblock

# Audit Powershell Scriptblock

## Setup

Some detection rules require enabling PowerShell Script Block Logging to record the content of processed script blocks in the Windows Event Log.

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

### Enable Audit Policy via Group Policy

To enable PowerShell Script Block logging across a group of servers using Active Directory Group Policies, administrators must enable the `Turn on PowerShell Script Block Logging` policy. Follow these steps to implement the logging policy:

```
Computer Configuration >
Administrative Templates >
Windows PowerShell >
Turn on PowerShell Script Block Logging (Enable)
```

### Enable Audit Policy via Registry

To configure the audit on servers that aren't domain joined, the EnableScriptBlockLogging registry key must be set to 1. Here is an example modification command:

```
reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
```

## Event IDs

When this audit policy is enabled, the following event IDs may be generated in the `Microsoft-Windows-PowerShell/Operational` log:

* **4104**: Script block execution.

## 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+%22PowerShell+Logs%22+AND+%28%224104%22+OR+%22powershell.file.script_block_text%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: sysmon eventid1 process creation

# Sysmon Event ID 1: Process Creation

## 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 1 (Process Creation) events to detect malicious and suspicious process execution activity.

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 1 (Process Creation). 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 process creation events -->
        <ProcessCreate onmatch="exclude"></ProcessCreate>
    </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%22process+where%22+OR+%22event.category%3Aprocess%22+OR+%22process.command_line%22%29++language%3ATOML+AND+NOT+%28%22event.code+%3D%3D+%5C%2210%5C%22%22%29&type=code)
Elastic SIEM Detection Rules: audit special logon

# Audit Special Logon

## Setup

Some detection rules require monitoring special logon events to track privileged account usage. Special logon events indicate that an account with elevated privileges (such as administrators or service accounts) has logged in, helping detect unauthorized access or privilege escalation attempts.

### Enable Audit Policy via Group Policy

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

## Event IDs

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

* **4672**: Special privileges assigned to new logon.
* **4964**: Special groups have been assigned to a new logon.

## 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%224672%22+OR+%22logged-in-special%22+OR+%224964%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit sensitive privilege use

# Audit Sensitive Privilege Use

## Setup

Some detection rules require monitoring the use of sensitive privileges to detect privilege escalation attempts or unauthorized actions. Enabling this setting provides visibility into when sensitive privileges are used, helping to strengthen security and compliance.

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

## Event IDs

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

* **4673**: A privileged service was called.
* **4674**: An operation was attempted on a privileged object.
* **4985**: The state of a transaction has 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%224673%22+OR+%22privileged-service-called%22+OR+%224674%22+OR+%22privileged-operation%22+OR+%224985%22+OR+%22state-of-transaction-has-changed%22%29++language%3ATOML+AND+NOT+%22%25%2514674%22&type=code)
Elastic SIEM Detection Rules: audit user account management

# Audit User Account Management

## Setup

Some detection rules require monitoring user account management activities to detect unauthorized account creations, modifications, or deletions. Enabling this setting ensures visibility into critical account changes, helping maintain security and compliance by tracking administrative actions related to user accounts.

### Enable Audit Policy via Group Policy

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

## Event IDs

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

* **4720**: A user account was created.
* **4722**: A user account was enabled.
* **4723**: An attempt was made to change an account's password.
* **4724**: An attempt was made to reset an account's password.
* **4725**: A user account was disabled.
* **4726**: A user account was deleted.
* **4738**: A user account was changed.
* **4740**: A user account was locked out.
* **4765**: SID History was added to an account.
* **4766**: An attempt to add SID History to an account failed.
* **4767**: A user account was unlocked.
* **4780**: The ACL was set on accounts which are members of administrators groups.
* **4781**: The name of an account was changed.
* **4794**: An attempt was made to set the Directory Services Restore Mode administrator password.
* **4798**: A user's local group membership was enumerated.
* **5376**: Credential Manager credentials were backed up.
* **5377**: Credential Manager credentials were restored from a backup.

## 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%224720%22+OR+%22added-user-account%22+OR+%224722%22+OR+%22enabled-user-account%22+OR+%224723%22+OR+%22changed-password%22+OR+%224724%22+OR+%22reset-password%22+OR+%224725%22+OR+%22disabled-user-account%22+OR+%224726%22+OR+%22deleted-user-account%22+OR+%224738%22+OR+%22modified-user-account%22+OR+%224740%22+OR+%22locked-out-user-account%22+OR+%224765%22+OR+%224766%22+OR+%224767%22+OR+%22unlocked-user-account%22+OR+%224780%22+OR+%224781%22+OR+%22renamed-user-account%22+OR+%224794%22+OR+%224798%22+OR+%22group-membership-enumerated%22+OR+%225376%22+OR+%225377%22%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: audit token right adjusted events

# Audit Token Right Adjusted Events

## Setup

Some detection rules require monitoring token right adjustments to detect privilege changes in user sessions. Token right adjustments occur when a user's security token is modified to grant or revoke privileges, which can indicate privilege escalation attempts or administrative activity. Enabling this setting enhances visibility into security-sensitive changes affecting user privileges.

**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 `Token Right Adjusted Events` across a group of servers using Active Directory Group Policies, administrators must enable the `Token Right Adjusted Events` 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 >
Detailed Tracking >
Token Right Adjusted Events (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:"Token Right Adjusted Events" /success:enable /failure:enable
```

## Event IDs

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

* **4703**: A user right was adjusted.

## 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%29++language%3ATOML&type=code)
Elastic SIEM Detection Rules: README

# LLM Threat Hunting Queries

Welcome to the `LLM` subfolder within the `hunting` directory of the `detection-rules` repository. This specialized section is dedicated to threat hunting queries designed for Large Language Model (LLM) applications, targeting the unique security challenges these systems face.

## Emphasis on OWASP Top 10 for LLMs

Our queries are developed with a keen awareness of the [OWASP Top 10 risks for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/). This crucial resource outlines the predominant security risks for LLMs, guiding our efforts in crafting queries that proactively address these vulnerabilities and ensure comprehensive threat mitigation.

## Emphasis on MITRE ATLAS

The [ATLAS Matrix](https://atlas.mitre.org/matrices/ATLAS/) covers the progression of tactics used in attacks with ML techniques belonging to different tactics.

- Reconnaissance
- Resource Development
- Initial Access
- ML Model Access
- Execution
- Persistence
- Privilege Escalation
- Defense Evasion
- Credential Access
- Discovery
- Collection
- ML Attack Staging
- Exfiltration
- Impact

## Scope of Threats and Protections

The queries in this folder are tailored to monitor and protect against a broad spectrum of threats to LLMs:

- **Sensitive Content Refusal**: Monitors LLM interactions to ensure compliance with ethical standards, particularly in refusing to process sensitive topics.
- **Denial of Service (DoS) and Resource Exhaustion**: Aims to prevent disruptions in LLM operations by detecting patterns indicative of DoS attacks or resource exhaustion scenarios.
- **Latency Anomalies**: Tracks processing delays that could signal underlying performance issues or security threats, maintaining operational efficiency and safeguarding against potential attacks like DDoS.

### Benefits of These Queries

These queries assist organizations in:
- Detecting and mitigating misuse or attacks that threaten data integrity or disrupt services.
- Ensuring that LLMs adhere strictly to operational and ethical boundaries through continuous monitoring.
- Maintaining high performance and reliability of LLMs by preemptively identifying and resolving factors that cause inefficiencies.

For more details, read our blog on [LLM Detections](https://www.elastic.co/security-labs/elastic-advances-llm-security).
Elastic SIEM Detection Rules: aws bedrock sensitive content refusal detection

# AWS Bedrock LLM Sensitive Content Refusals

---

## Metadata

- **Author:** Elastic
- **Description:** This analytic flags multiple instances of LLM refusals to respond to sensitive prompts, helping to maintain ethical guidelines and compliance standards.
- **UUID:** `11e33a8f-805b-4394-bee0-08ae8d78b025`
- **Integration:** [aws_bedrock.invocation](https://docs.elastic.co/integrations/aws_bedrock)
- **Language:** `[ES|QL]`
- **Source File:** [AWS Bedrock LLM Sensitive Content Refusals](../queries/aws_bedrock_sensitive_content_refusal_detection.toml)

## Query

```sql
from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.completion LIKE "*I cannot provide any information about*"
     AND gen_ai.completion LIKE "*end_turn*"
   )
 | STATS user_request_count = count() BY gen_ai.user.id
 | WHERE user_request_count >= 3
```

## Notes

- Examine flagged interactions for patterns or anomalies in user requests that may indicate malicious intent or probing of model boundaries.
- Regularly review and update the phrases that trigger refusals to adapt to new ethical guidelines and compliance requirements.
- Ensure that data logs contain enough detail to provide context around the refusal, which will aid in subsequent investigations by security teams.

## MITRE ATT&CK Techniques

- [AML.T0051](https://atlas.mitre.org/techniques/AML.T0051)

## References

- https://www.elastic.co/security-labs/elastic-advances-llm-security
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: aws bedrock latency anomalies detection

# AWS Bedrock LLM Latency Anomalies

---

## Metadata

- **Author:** Elastic
- **Description:** This analytic helps identify delays in LLM responses that are outside expected performance parameters, possibly due to malicious disruptions like DDoS attacks or from operational inefficiencies.

- **UUID:** `991b55c3-6327-4af6-8e0c-5d[PII_REDACTED]`
- **Integration:** [aws_bedrock.invocation](https://docs.elastic.co/integrations/aws_bedrock)
- **Language:** `[ES|QL]`
- **Source File:** [AWS Bedrock LLM Latency Anomalies](../queries/aws_bedrock_latency_anomalies_detection.toml)

## Query

```sql
from logs-aws_bedrock.invocation-*
  | WHERE @timestamp > NOW() - 1 DAY
  | EVAL response_delay_seconds = gen_ai.performance.start_response_time / 1000
  | WHERE response_delay_seconds > 5
  | STATS max_response_delay = max(response_delay_seconds),
          request_count = count() BY gen_ai.user.id
  | WHERE request_count > 3
  | SORT max_response_delay DESC
```

## Notes

- Review the incidents flagged by this analytic to understand the context and potential sources of latency. This can include network configurations, resource allocation, or external network pressures.
- Effective logging and monitoring setup are essential to capture relevant latency metrics accurately. Ensure system clocks and time syncing are properly configured to avoid false positives.
- Gather comprehensive logs that detail the request and response timestamps, user IDs, and session details for thorough investigation and evidence collection in case of security incidents.

## MITRE ATT&CK Techniques

- [AML.T0029](https://atlas.mitre.org/techniques/AML.T0029)

## References

- https://www.elastic.co/security-labs/elastic-advances-llm-security
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: aws bedrock dos resource exhaustion detection

# AWS Bedrock LLM Denial-of-Service or Resource Exhaustion

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies unusual spikes in token usage that may indicate malicious attempts to disrupt services. High token usage can strain system resources and degrade performance, aligning with tactics observed in DoS attacks.

- **UUID:** `00023411-192e-4472-90aa-da7562bc3f2a`
- **Integration:** [aws_bedrock.invocation](https://docs.elastic.co/integrations/aws_bedrock)
- **Language:** `[ES|QL]`
- **Source File:** [AWS Bedrock LLM Denial-of-Service or Resource Exhaustion](../queries/aws_bedrock_dos_resource_exhaustion_detection.toml)

## Query

```sql
from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.usage.prompt_tokens > 8000 OR
     gen_ai.usage.completion_tokens > 8000 or
     gen_ai.performance.request_size > 8000
   )
 | STATS max_prompt_tokens = max(gen_ai.usage.prompt_tokens),
         max_request_tokens = max(gen_ai.performance.request_size),
         max_completion_tokens = max(gen_ai.usage.completion_tokens),
         request_count = count() BY cloud.account.id
 | WHERE request_count > 1
 | SORT max_prompt_tokens, max_request_tokens, max_completion_tokens DESC
```

## Notes

- Consider reviewing the context of high token requests to differentiate between legitimate heavy usage and potential abuse. Monitor the source of requests and patterns over time for better assessment.
- Ensure logging and monitoring are correctly configured to capture detailed metrics on token usage. This will facilitate accurate detection and allow for a quick response to potential threats.
- Collect evidence from logs that detail the timestamp, user ID, session information, and token counts for incidents flagged by this analytic. This information will be crucial for forensic analysis in the event of a security incident.

## MITRE ATT&CK Techniques

- [AML.T0034](https://atlas.mitre.org/techniques/AML.T0034)

## References

- https://www.elastic.co/security-labs/elastic-advances-llm-security
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

## License

- `Elastic License v2`