Elastic rules: 25

[metadata]
creation_date = "2025/12/05"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2025/12/05"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
This rule detects anomalous patterns in React Server Components (RSC) Flight protocol data streams that may indicate
code injection or exploitation attempts. The Flight protocol is used by React and Next.js for server-client
communication, and should never contain Node.js code execution primitives like child_process, fs module calls, or eval
patterns. This building block rule casts a wider net to identify suspicious payloads that warrant further investigation.
"""
from = "now-119m"
index = ["logs-network_traffic.http*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Anomalous React Server Components Flight Data Patterns"
references = [
    "https://react.dev/reference/rsc/server-components",
    "https://github.com/facebook/react/blob/main/packages/react-server/src/ReactFlightServer.js",
    "https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182",
    "https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478/",
    "https://nextjs.org/docs/app/building-your-application/rendering/server-components",
    "https://tonyalicea.dev/blog/understanding-react-server-components/",
]
risk_score = 21
rule_id = "b9c8d7e6-5a4f-3c2b-1d0e-9f8a7b6c5d4e"
severity = "low"
tags = [
    "Domain: Network",
    "Domain: Application",
    "Domain: Web",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Execution",
    "Data Source: Network Packet Capture",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where http.request.method == "POST" and http.response.status_code != 200 and
(
    // Node.js child_process module
    (
        http.request.body.content like~ "*require('child_process')*" or
        http.request.body.content like~ "*require(\"child_process\")*" or
        http.request.body.content like~ "*child_process*" and http.request.body.content like~ "*.exec*"
    ) or
    // Node.js synchronous execution methods
    (
        http.request.body.content like~ "*.execSync(*" or
        http.request.body.content like~ "*.spawnSync(*" or
        http.request.body.content like~ "*.execFileSync(*"
    ) or
    // Node.js file system operations - suspicious in RSC context
    (
        http.request.body.content like~ "*require('fs')*" or
        http.request.body.content like~ "*require(\"fs\")*" or
        http.request.body.content like~ "*.readFileSync(*" or
        http.request.body.content like~ "*.writeFileSync(*" or
        http.request.body.content like~ "*.unlinkSync(*"
    ) or
    // Process and module access patterns used in exploitation
    (
        http.request.body.content like~ "*process.mainModule*" or
        http.request.body.content like~ "*process.binding*" or
        http.request.body.content like~ "*process.dlopen*"
    ) or
    // JavaScript code execution primitives
    (
        http.request.body.content like~ "*eval(*" and http.request.body.content like~ "*require*" or
        http.request.body.content like~ "*Function(*" and http.request.body.content like~ "*return*"
    ) or
    // Generic prototype pollution indicators
    (
        http.request.body.content like~ "*prototype*" and http.request.body.content like~ "*constructor*"
    )
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[metadata]
creation_date = "2026/07/16"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/16"

[rule]
author = ["Elastic"]
description = """
Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet
command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and
/stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates
lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade
handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution.
"""
false_positives = [
    """
    Legitimate use of the Kubelet run/exec/attach/portforward endpoints via nodes/proxy is rare. Administrative
    debugging tools that proxy exec through the API server may match; baseline and exclude verified operators.
    """,
]
from = "now-9m"
index = ["logs-azure.platformlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure AKS Kubelet Proxy to Command Execution Endpoint"
note = """## Triage and analysis

### Investigating Azure AKS Kubelet Proxy to Command Execution Endpoint

AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule keys on the Kubelet
endpoint in `azure.platformlogs.properties.log.requestURI`: `/proxy/run`, `/proxy/exec`, `/proxy/attach`,
`/proxy/portforward`, and `/proxy/cri` execute commands in a pod on the target node, whereas monitoring uses `/metrics`
and `/stats`. Any hit here is high-signal command execution regardless of the acting identity, including a stolen
monitoring service-account token.

### Possible investigation steps

- Confirm the endpoint and target in `azure.platformlogs.properties.log.requestURI` (the path encodes
  `/<endpoint>/<namespace>/<pod>/<container>`) and the acting identity in
  `azure.platformlogs.properties.log.user.username`.
- Evaluate `azure.platformlogs.properties.log.sourceIPs`. This is an array; for an externally operated attack the first
  element is the operator's real client IP and the trailing entry is the internal API-server/konnectivity hop
  (`172.31.x`). A first entry that is not the cluster's own egress is a strong signal.
- Determine what the target pod runs and what secrets or tokens it exposes, and whether the identity should reach the
  Kubelet at all.
- Correlate with prior recon (`/proxy/pods`, `/proxy/runningpods`) and follow-on RBAC changes, secret reads, or token
  requests from the same identity.

### False positive analysis

- Direct use of Kubelet exec endpoints via nodes/proxy is uncommon; validate any administrative debugging tool that
  proxies exec and exclude verified operators.

### Response and remediation

- Treat as active command execution on a node. Revoke the acting identity's tokens, isolate the affected node and pods,
  and rotate credentials reachable from them.
- Review the RBAC that granted `nodes/proxy` and remove it from workload identities that do not require it.
- Note that direct Kubelet access on port 10250 bypasses the API server and is not in kube-audit; a confirmed proxy exec
  may indicate broader Kubelet access.
- Collect kube-audit and identity artifacts per incident response procedures.
"""
references = [
    "https://horizon3.ai/attack-research/when-read-only-isnt-k8s-nodes-proxy-get-to-rce/",
    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/",
    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://github.com/inguardians/peirates",
    "https://grahamhelton.com/blog/nodes-proxy-rce"
]
risk_score = 73
rule_id = "4223a0c2-2a96-4742-b6ec-2ce9fa0019ba"
setup = "The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule."
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:"kube-audit" and
  azure.platformlogs.properties.log.objectRef.resource:"nodes" and
  azure.platformlogs.properties.log.objectRef.subresource:"proxy" and
  azure.platformlogs.properties.log.requestURI:(
    */proxy/run/* or */proxy/exec* or */proxy/attach* or
    */proxy/portforward* or */proxy/portForward* or */proxy/cri/*
  ) and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or "aksService" or "hcpService" or "readinessChecker"
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"


[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1210"
name = "Exploitation of Remote Services"
reference = "https://attack.mitre.org/techniques/T1210/"


[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.platformlogs.category",
    "azure.platformlogs.properties.log.verb",
    "azure.platformlogs.properties.log.user.username",
    "azure.platformlogs.properties.log.sourceIPs",
    "azure.platformlogs.properties.log.requestURI",
    "azure.platformlogs.properties.log.objectRef.name",
    "azure.platformlogs.properties.log.responseStatus.code",
]

[metadata]
creation_date = "2021/08/01"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Austin Songer"]
description = """
Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a
Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their
objective.
"""
false_positives = [
    """
    Azure Front Web Application Firewall (WAF) Policy deletions may be done by a system or network administrator. Verify
    whether the username, hostname, and/or resource name should be making changes in your environment. Azure Front Web
    Application Firewall (WAF) Policy deletions by unfamiliar users or hosts should be investigated. If known behavior
    is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure VNet Firewall Front Door WAF Policy Deleted"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Azure VNet Firewall Front Door WAF Policy Deleted

Azure Front Door WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts.

### Possible investigation steps

- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success.
- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs.
- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment.
- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources.
- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats.
- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion.

### False positive analysis

- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts.
- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers.
- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments.

### Response and remediation

- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration.
- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions.
- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls.
- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies.
- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring.
- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#networking",
]
risk_score = 21
rule_id = "09d028a5-dcde-409f-8ae0-557cef1b7082"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Use Case: Network Security Monitoring",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and event.outcome:(Success or success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.007"
name = "Disable or Modify Cloud Firewall"
reference = "https://attack.mitre.org/techniques/T1562/007/"



[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2024/03/26"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and
replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces
some security issues because of the default permission (Any authenticated users) to create DNS-named records. Attackers
can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target
systems that are requested from multiple systems. They can also create specific records to target specific services,
such as wpad, for spoofing attacks.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Creation of a DNS-Named Record"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Creation of a DNS-Named Record

Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.

### Possible investigation steps

- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.

### False positive analysis

- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
references = [
    "https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/",
    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing",
]
risk_score = 21
rule_id = "1e1b2e7e-b8f5-45e5-addc-66cc1224ffbc"
setup = """## Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-changes
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Active Directory",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
    not winlog.event_data.SubjectUserName : "*$"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"

[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[metadata]
bypass_bbr_timing = true
creation_date = "2025/05/18"
integration = ["azure"]
maturity = "production"
promotion = true
updated_date = "2025/12/10"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies Microsoft Entra ID Protection sign-in risk detections triggered by a range of risk events such as anonymized
IP addresses, password spray attacks, impossible travel, token anomalies, and more. These detections are often early
indicators of potential account compromise or malicious sign-in behavior. This is a promotion rule intended to surface
all Entra ID sign-in risk events for further investigation and correlation with other identity-related activity. This is
a building block rule that is used to collect all Microsoft Entra ID Protection sign-in or user risk detections. It is
not intended to be used as a standalone detection.
"""
from = "now-9m"
index = ["logs-azure.identity_protection-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Protection - Risk Detection"
references = [
    "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection",
]
risk_score = 47
rule_id = "da0d4bae-33ee-11f0-a59f-f661ea17fbcd"
setup = ""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Protection",
    "Data Source: Microsoft Entra ID Protection Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: "azure.identity_protection"
'''

[metadata]
creation_date = "2022/12/19"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/04"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,
issuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =
authenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == "Microsoft" AND signed == "1")
"""

[[transform.osquery]]
label = "Osquery - Retrieve All Unsigned Drivers with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,
issuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =
authenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == "0"
"""


[rule]
author = ["Elastic"]
description = """
Identifies the load of a driver with an original file name and signature values that were observed for the first time
during the last 30 days. This rule type can help baseline drivers installation within your environment.
"""
from = "now-9m"
index = ["logs-endpoint.events.library-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Seen Driver Loaded"
note = """## Triage and analysis

### Investigating First Time Seen Driver Loaded

A driver is a software component that allows the operating system to communicate with hardware devices. It works at a high privilege level, the kernel level, having high control over the system's security and stability.

Attackers may exploit known good but vulnerable drivers to execute code in their context because once an attacker can execute code in the kernel, security tools can no longer effectively protect the host. They can leverage these drivers to tamper, bypass and terminate security software, elevate privileges, create persistence mechanisms, and disable operating system protections and monitoring features. Attackers were seen in the wild conducting these actions before acting on their objectives, such as ransomware.

Read the complete research on "Stopping Vulnerable Driver Attacks" done by Elastic Security Labs [here](https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks).

This rule identifies the load of a driver with an original file name and signature values observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

#### Possible investigation steps

- Examine the driver loaded to identify potentially suspicious characteristics. The following actions can help you gain context:
  - Identify the path that the driver was loaded from. If using Elastic Defend, this information can be found in the `dll.path` field.
  - Examine the digital signature of the driver, and check if it's valid.
  - Examine the creation and modification timestamps of the file:
    - On Elastic Defend, those can be found in the `dll.Ext.relative_file_creation_time` and `"dll.Ext.relative_file_name_modify_time"` fields, with the values being seconds.
    - Search for file creation events sharing the same file name as the `dll.name` field and identify the process responsible for the operation.
      - Investigate any other abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
  - Use the driver SHA-256 (`dll.hash.sha256` field) hash value to search for the existence and reputation in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Use Osquery to investigate the drivers loaded into the system.
  - $osquery_0
  - $osquery_1
- Identify the driver's `Device Name` and `Service Name`.
- Check for alerts from the rules specified in the `Related Rules` section.

### False positive analysis

- Matches derived from these rules are not inherently malicious. The security team should investigate them to ensure they are legitimate and needed, then include them in an allowlist only if required. The security team should address any vulnerable driver installation as it can put the user and the domain at risk.

### Related Rules

- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa
- Code Signing Policy Modification Through Registry - da7733b1-fe08-487e-b536-0a04c6d8b0cd
- Code Signing Policy Modification Through Built-in tools - b43570de-a908-4f7f-8bdb-b2df6ffd8c80

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode)
- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed.
  - This can be done via PowerShell `Remove-Service` cmdlet.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Ensure that the Driver Signature Enforcement is enabled on the system.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend
"""

references = ["https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks"]
risk_score = 47
rule_id = "df0fd41e-5590-4965-ad5e-cd079ec22fa9"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.category:"driver" and host.os.type:windows and event.action:"load"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique.subtechnique]]
id = "T1543.003"
name = "Windows Service"
reference = "https://attack.mitre.org/techniques/T1543/003/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["dll.pe.original_file_name", "dll.code_signature.subject_name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-30d"

[metadata]
creation_date = "2024/07/15"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects a suspicious egress network connection attempt from a Git hook script. Git hooks are scripts that Git
executes before or after events such as: commit, push, and receive. An attacker can abuse these features to execute
arbitrary commands on the system, establish persistence or to initialize a network connection to a remote server and
exfiltrate data or download additional payloads.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "logs-endpoint.events.network*"]
language = "eql"
license = "Elastic License v2"
name = "Git Hook Egress Network Connection"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Git Hook Egress Network Connection

Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent egress connections to non-local IPs, flagging potential misuse.

### Possible investigation steps

- Review the process execution details to identify the specific Git hook script that triggered the alert. Check the process.args field for the exact script path within the .git/hooks directory.
- Investigate the parent process details to confirm the legitimacy of the Git operation. Verify the process.parent.name is "git" and assess whether the Git activity aligns with expected user or system behavior.
- Analyze the destination IP address involved in the network connection attempt. Use the destination.ip field to determine if the IP is known, trusted, or associated with any malicious activity.
- Check for any additional network connections from the same host around the time of the alert to identify potential patterns or additional suspicious activity.
- Correlate the alert with any recent changes in the repository or system that might explain the execution of the Git hook, such as recent commits or updates.
- Review user activity logs to determine if the Git operation was performed by an authorized user and if their actions align with their typical behavior.
- If suspicious activity is confirmed, isolate the affected system to prevent further unauthorized access or data exfiltration and initiate a deeper forensic analysis.

### False positive analysis

- Legitimate automated scripts or CI/CD pipelines may trigger Git hooks to perform network operations. Review the source and purpose of these scripts and consider excluding them if they are verified as non-threatening.
- Development environments often use Git hooks for tasks like fetching dependencies or updating remote services. Identify these common operations and create exceptions for known safe IP addresses or domains.
- Internal tools or services that rely on Git hooks for communication with other internal systems might be flagged. Ensure these tools are documented and whitelist their network activities if they are deemed secure.
- Frequent updates or deployments that involve Git hooks could lead to repeated alerts. Monitor the frequency and context of these alerts to determine if they are part of regular operations and adjust the rule to reduce noise.
- Consider the context of the network connection, such as the destination IP or domain. If the destination is a known and trusted entity, it may be appropriate to exclude it from triggering alerts.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized egress connections and potential data exfiltration.
- Terminate any suspicious processes identified as originating from Git hooks, particularly those executing shell scripts like bash, dash, or zsh.
- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
- Reset credentials and access tokens associated with the affected Git repository to prevent further unauthorized access.
- Restore any modified or deleted files from a known good backup to ensure system integrity.
- Implement network monitoring to detect and block any future unauthorized egress connections from Git hooks or similar scripts.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems or repositories."""
references = [
    "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "9822c5a1-1494-42de-b197-487197bb540c"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id with maxspan=3s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.parent.name == "git" and process.args like ".git/hooks/*" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   not (process.name like "python*" and process.command_line like "*pip*")
  ] by process.entity_id
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not (
     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
       "FF00::/8", "172.31.0.0/16"
     )
   )
  ] by process.parent.entity_id
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/29"

[rule]
author = ["Elastic"]
description = """
Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to
disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the
privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an
active investigation.
"""
false_positives = [
    """
    Google Workspace admin roles may be deleted by system administrators. Verify that the configuration change was
    expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Admin Role Deletion"
note = """## Triage and analysis

### Investigating Google Workspace Admin Role Deletion

Google Workspace allows administrators to create custom admin roles with granular privileges across services such as
Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated
privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations,
remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the
Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing
historical audit logs.

This rule identifies when a custom administrative role is deleted in the Google Admin console.

### Possible investigation steps

- Identify the initiating (actor) account that deleted the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps.
- Identify the role deleted by reviewing `google_workspace.admin.role.name`.
- Determine whether the deletion is expected and authorized:
  - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles.
  - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign.
- Confirm the role is deleted in the Google Admin console:
  - Navigate to Account > Admin roles.
  - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list.
- Search Kibana for principals previously assigned the role to determine blast radius:
  - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp.
  - Use the following KQL example, replacing `<ROLE_NAME>` with the value from `google_workspace.admin.role.name`:
    ```
    data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "<ROLE_NAME>"
    ```
  - Review `user.target.email` and `user.target.name` for user/group assignments.
  - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion.
- Search Kibana for privileges the deleted role contained:
  - Use the following KQL example to review any privileges that were granted to the role before deletion:
    ```
    data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "<ROLE_NAME>"
    ```
  - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals.
- Scope for related role activity by searching for the same `user.email` (actor) performing other IAM actions such as `DELETE_ROLE`, `ADD_PRIVILEGE`, `ASSIGN_ROLE`, or security policy changes within the last 48 hours.
- Evaluate whether the deletion coincides with other suspicious activity:
  - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments.

### False positive analysis

- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process.
- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations.
- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds.
- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles.
- For suspected compromise of the initiating admin account:
  - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence.
  - Validate recovery email/phone settings and account security posture.
- Review whether the deleted role contained security-relevant privileges (for example, audit log access or security settings management) that could impair detection or response if removed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/2406043?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 47
rule_id = "93e63c3e-4154-4fc6-9f86-b411e0987bbf"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Tactic: Impact",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:google_workspace.admin and event.action:DELETE_ROLE
'''

[rule.investigation_fields]
field_names = [
    "source.ip",
    "user.name",
    "user.email",
    "event.action",
    "google_workspace.admin.role.name",
]

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2026/05/05"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/05/05"

[rule]
author = ["Elastic"]
description = """
Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly
to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet
API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path,
an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and
PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node.
Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate
observability tooling.
"""
false_positives = [
    """
    Legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the
    excluded metrics prefix may match. Baseline approved operators and automation identities.
    """,
]
from = "now-9m"
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes API Server Proxying Request to Kubelet"
note = """## Triage and analysis

### Investigating Kubernetes API Server Proxying Request to Kubelet

Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from
where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/
maps directly to the Kubelet API path the attacker accessed.

### Possible investigation steps

- Check the proxied Kubelet path in requestURI to determine attacker intent:
  - /proxy/pods — pod spec enumeration including environment variable secrets
  - /proxy/exec or /proxy/run — command execution inside containers on that node
  - /proxy/configz — Kubelet configuration and authentication settings
  - /proxy/runningpods — active workload enumeration
  - /proxy/containerLogs — log harvesting for leaked credentials
- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings
- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this 
  indicates the attacker minted a token specifically for this access.
- Review whether the same principal accessed multiple nodes via proxy in a short window, which
  indicates systematic lateral movement across the cluster.

### False positive analysis

- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy.
  These endpoints are excluded by default. If additional monitoring paths generate noise, add
  them to the requestURI exclusion.
- Cluster administration tools that inspect node health via the proxy API can match. Correlate
  with change management windows and verify the source identity.

### Response and remediation

- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding
  is authorized. Remove unauthorized bindings.
- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised.
  Rotate affected credentials, API keys, and database passwords.
- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node,
  review running containers for unauthorized modifications, and check for persistence mechanisms.
- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be
  restricted to infrastructure automation only, never granted to application service accounts.
"""
references = [
    "https://kubernetes.io/docs/concepts/cluster-administration/proxies/",
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 47
rule_id = "332ecb5b-08b6-47e9-885b-3cee1de74bac"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
kubernetes.audit.objectRef.subresource:"proxy" and
kubernetes.audit.objectRef.resource:"nodes" and
not kubernetes.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and
not user.name:(
  system\:kube-controller-manager or
  system\:kube-scheduler or
  system\:serviceaccount\:kube-system\:* or
  system\:node\:* or
  eks\:* or aksService
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[rule]
description = """
Identifies attempt to access the Local Security Authority Subsystem Service (LSASS) to dump its memory using the Windows
API MiniDumpWritedump. Adversaries may attempt to access credential material stored in the process memory of LSASS.
"""
id = "bdf280ea-d4d7-4f8f-90fc-0f44edad6b87"
license = "Elastic License v2"
name = "LSASS Memory dump via MiniDumpWriteDump"
os_list = ["windows"]
version = "1.0.16"

query = '''
credential_access where
 Target.process.name : "lsass.exe" and
 _arraysearch(process.thread.Ext.call_stack, $entry, $entry.module_path : ("*dbgcore.dll*", "*comsvcs.dll*")) and 
 not (process.Ext.api.name : "OpenThread" and user.id == "S-1-5-18" and 
      process.executable : "?:\\Windows\\System32\\WerFault.exe" and process.thread.Ext.call_stack_contains_unbacked == false) and
 not (process.executable : ("C:\\Windows\\System32\\WerFaultSecure.exe", "C:\\Windows\\System32\\WerFault.exe") and
      process.Ext.api.parameters.desired_access_numeric == 2097151 and process.thread.Ext.call_stack_contains_unbacked == false)
'''

min_endpoint_version = "8.7.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[threat.technique.subtechnique]]
id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"



[threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[internal]
min_endpoint_version = "8.7.0"

[rule]
description = """
Detects the execution of the Nohup utility pointing to a suspicious or malicious executable path followed by pushing the
execution to the background using the "&". Threat actors will utilize the Nohup utility to execute their payloads in a
variety of ways but specifically within initial access installer scripts and shell profile persistence. This activity
should be considered highly abnormal or malicious.
"""
id = "3f18726c-4897-41dc-8426-15da95b8482f"
license = "Elastic License v2"
name = "Nohup Execution followed by Outbound Network Connection"
os_list = ["macos"]
reference = ["https://objective-see.org/blog/blog_0x71.html"]
version = "1.0.26"

query = '''
sequence by process.parent.entity_id with maxspan=30s
[process where event.type == "start" and 
  process.name == "nohup" and
  ((process.command_line like~ ("*/tmp/*",
                                "*/var/tmp/*",
                                "*/private/var/tmp/*",
                                "*/var/folders/*", 
                                "*/Users/Shared/*", 
                                "*/Library/*", 
                                "*/var/root/*", 
                                "*/usr/local/bin/*", 
                                "*/Applications/*")) or
   (process.args like~ "npm" and process.args like~ "install")) and
  process.parent.name like~ ("bash", "sh", "zsh", "tclsh*", "terminal", "python*", "osascript") and
  not process.Ext.effective_parent.executable == "/Applications/SteelSeries GG/SteelSeries GG.app/Contents/MacOS/SteelSeries GG" and
  not (process.parent.name in ("zsh", "bash", "sh") and process.parent.command_line : (
    "*/.claude/shell-snapshots/*",
    "*/.claude-personal/shell-snapshots/*",
    "*/.codex/shell_snapshots/*",
    "*/.cursor/shell-snapshots/*",
    "*__CURSOR_SANDBOX_ENV_RESTORE*")) and
  not process.command_line : (
    "*/tmp/claude/*",
    "*/private/tmp/claude/*",
    "*/private/tmp/claude-*/*",
    "*/Library/Application Support/Claude/local-agent-mode-sessions/*",
    "*/Library/Android/sdk/emulator/*")]
[network where event.type == "start" and
   not cidrmatch(destination.ip, 
       "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", "198.19.0.0/16", "192.18.0.0/15", 
       "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", 
       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", 
       "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24",
       "::1", "FE80::/10", "FF00::/8")]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.003"
name = "Hidden Window"
reference = "https://attack.mitre.org/techniques/T1564/003/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2026/07/30"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/07/30"

[rule]
author = ["Elastic"]
description = """
Identifies PostgreSQL "COPY" statements that invoke an operating-system command through the "PROGRAM" option. A
superuser or role with "pg_execute_server_program" can use this feature to execute arbitrary commands as the PostgreSQL
service account, a technique used after credential compromise and by cryptomining campaigns.
"""
false_positives = [
    """
    Database administrators and scheduled data-processing jobs may legitimately use COPY PROGRAM for import or export
    workflows. Confirm the command, client address, database role, maintenance context, and resulting process activity
    before escalating.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.pgsql-*"]
language = "eql"
license = "Elastic License v2"
name = "PostgreSQL COPY PROGRAM Command Execution"
note = """## Triage and analysis

### Investigating PostgreSQL COPY PROGRAM Command Execution

PostgreSQL supports `COPY ... FROM PROGRAM` and `COPY ... TO PROGRAM` for server-side process execution. Attackers who obtain a privileged database identity can use this feature to launch shells, download payloads, establish persistence, or deploy cryptominers from the PostgreSQL process context.

### Possible investigation steps

- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.pgsql.query`, and PostgreSQL error fields.
- Extract the command passed to `PROGRAM` and identify referenced shells, interpreters, downloaders, files, or network destinations.
- Confirm the database role and whether it has superuser or `pg_execute_server_program` privileges using PostgreSQL audit and server logs.
- Correlate the event with endpoint telemetry for `postgres` spawning `sh`, `bash`, `curl`, `wget`, `python`, `perl`, `nc`, miners, or other unusual child processes.
- Search earlier events from the client for authentication failures, role changes, extension creation, or database enumeration.

### False positive analysis

- Approved ETL, backup, and administrative automation can use COPY PROGRAM.
- Scope exceptions to a documented client, command family, and maintenance context; do not globally exclude the `PROGRAM` keyword.

### Response and remediation

- Terminate the database session and isolate the server if unauthorized process execution is confirmed.
- Preserve PostgreSQL, endpoint, and network evidence and remove malicious processes or persistence.
- Rotate affected credentials and revoke unnecessary superuser and `pg_execute_server_program` privileges.
"""
references = [
    "https://www.postgresql.org/docs/current/sql-copy.html",
    "https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/",
    "https://www.wiz.io/blog/postgresql-cryptomining",
    "https://attack.mitre.org/techniques/T1059/",
]
risk_score = 73
rule_id = "8ab64631-17ee-46b9-9800-9acacbeee1b3"
setup = """## Setup

This rule requires the Elastic Network Packet Capture integration with the PostgreSQL protocol analyzer enabled and
cleartext visibility into PostgreSQL query traffic. TLS-encrypted sessions, prepared statements, packet loss, and
asymmetric capture can hide or fragment query text. Use PostgreSQL audit logs and endpoint process telemetry to confirm
the database identity and command execution outcome.
"""
severity = "high"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where data_stream.dataset == "network_traffic.pgsql" and
    (
        network_traffic.pgsql.query like~ "*copy*from*program*" or
        network_traffic.pgsql.query like~ "*copy*to*program*"
    )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"


[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[rule]
description = """
This rule detects the execution of the mount command with both the filesystem type set to cgroup and additional mount
options specified. A high argument count (7 or more) combined with these flags may indicate attempts to abuse cgroup
mounting for container breakout, privilege escalation, or namespace manipulation. While mounting cgroups is legitimate
in containerized environments, this pattern—especially outside of expected contexts—can signal exploitation techniques
such as cgroup notify-on-release abuse or unprivileged namespace tricks.
"""
id = "fc90a1c9-554e-4934-af6a-df5f6e201e43"
license = "Elastic License v2"
name = "Potential Cgroup Privilege Escalation/Container Escape via Mount"
os_list = ["linux"]
reference = ["https://0xdf.gitlab.io/2021/05/17/digging-into-cgroups.html"]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "mount" and
process.args in ("-t", "--types") and process.args in ("-o", "--options") and process.args == "cgroup" and
process.args_count >= 7 and
not process.parent.executable in (
  "/opt/resource/in", "/opt/piavpn/bin/pia-daemon", "/opt/expressvpn/bin/expressvpn-daemon", "/usr/lib/systemd/systemd",
  "/usr/bin/cgroupfs-mount"
)
'''

min_endpoint_version = "7.15.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

[[threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"


[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = "Identifies potential execution of a commercial spyware."
id = "051179c9-67cf-4182-8e58-18df7114f476"
license = "Elastic License v2"
name = "Potential DANTE Spyware Execution"
os_list = ["windows"]
reference = ["https://securelist.com/forumtroll-apt-hacking-team-dante-spyware/117851/"]
version = "1.0.2"

query = '''
registry where event.action == "query" and registry.value == "ComputerName" and
 process.thread.Ext.call_stack_summary like "ntdll.dll*|kernelbase.dll|rpcrt4.dll|wevtapi.dll|*" and
 _arraysearch(process.thread.Ext.call_stack, $entry,
              $entry.callsite_trailing_bytes like ("488bd848894424384885c00f84bc0000008974244033c955e8*",
                                                   "4883c320483bdf????488b7dd8488b5dd0418bf6488b4de8483b4df0400f95c64885db????488bd7488bcb*"))
'''

min_endpoint_version = "8.10.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"


[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[threat]]
framework = "MITRE ATT&CK"

[threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2026/06/25"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/06/25"

[rule]
author = ["Elastic"]
description = """
Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses
observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC
addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Potential DHCP Starvation via High Client MAC Cardinality"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Potential DHCP Starvation via High Client MAC Cardinality

DHCP starvation floods a segment with DISCOVER messages that use many distinct client hardware addresses to consume
available leases. This rule keys on high DHCP DISCOVER volume paired with high `client_mac` cardinality seen by the
same network capture sensor, which is the wire-level starvation pattern and does not depend on host operating system.

### Possible investigation steps

- Review `Esql.count_distinct_client_macs` and sample values in `Esql.values_client_macs` to confirm the burst is not a
  single client retrying with one address.
- Identify the L2 segment or VLAN monitored by `Esql.observer` and check DHCP server logs for pool exhaustion, NAK spikes,
  or lease-denial events during the same window.
- Look for follow-on rogue DHCP OFFER/ACK activity on the segment, including the Multiple DHCP Servers Responding to the
  Same Transaction rule.
- Locate the transmitting host using switch CAM tables if Ethernet source addresses are available in raw capture exports.

### False positive analysis

- Large Wi-Fi reconnect or onboarding events can temporarily increase DISCOVER volume. Compare against historical
  baselines for the same `Esql.observer` and time of day before treating as malicious.
- Virtualization or VDI provisioning bursts may generate many distinct client MAC addresses during imaging. Exclude known
  provisioning VLANs or sensors when the workflow is confirmed.

### Response and remediation

- Enable or verify DHCP snooping and rate limits on the affected access switches.
- Block or isolate the source host if link-layer evidence confirms a single transmitter is generating the flood.
- Restore DHCP service capacity and monitor for rogue OFFER/ACK responses after the starvation attempt.
"""
references = [
    "https://attack.mitre.org/techniques/T1498/",
    "https://www.leviathansecurity.com/blog/tunnelvision",
    "https://wazuh.com/blog/monitoring-dhcp-starvation-attack-with-suricata-and-wazuh/",
]
risk_score = 47
rule_id = "b5f94e78-fb4d-4f4b-879e-e51ea667d09c"
setup = """## Setup

This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast
segment where clients acquire leases, either Packetbeat running on the segment or a SPAN/mirror feeding it.

Zeek and flow-only firewall sources are intentionally not supported: this rule requires per-DISCOVER DHCP transaction
fields and client hardware address values (`client_mac`) to measure high client MAC cardinality in a short time window.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Use Case: Threat Detection",
    "Use Case: Network Security Monitoring",
    "Tactic: Impact",
    "Data Source: Network Traffic",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-network_traffic.dhcpv4-*, packetbeat-*
| eval
    Esql.message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)),
    Esql.client_mac = COALESCE(network_traffic.dhcpv4.client_mac, dhcpv4.client_mac),
    Esql.observer_hostname = COALESCE(host.name, observer.hostname)
| where Esql.message_type == "discover" and Esql.client_mac is not null and Esql.observer_hostname is not null
| eval Esql.time_window = DATE_TRUNC(1 minute, @timestamp)
| stats
    Esql.dhcpv4_discover_count = COUNT(*),
    Esql.dhcpv4_client_mac_count_distinct = COUNT_DISTINCT(Esql.client_mac),
    Esql.dhcpv4_client_mac_values = MV_SLICE(VALUES(Esql.client_mac), 0, 10)
  by Esql.time_window, Esql.observer_hostname
| where Esql.dhcpv4_discover_count >= 75 and Esql.dhcpv4_client_mac_count_distinct >= 50
| keep Esql.observer_hostname, Esql.time_window, Esql.dhcpv4_discover_count, Esql.dhcpv4_client_mac_count_distinct, Esql.dhcpv4_client_mac_values
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1498"
name = "Network Denial of Service"
reference = "https://attack.mitre.org/techniques/T1498/"
[[rule.threat.technique.subtechnique]]
id = "T1498.001"
name = "Direct Network Flood"
reference = "https://attack.mitre.org/techniques/T1498/001/"



[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[metadata]
creation_date = "2026/01/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/09/04"

[rule]
author = ["Elastic"]
description = """
Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint 
for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 
channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*", "logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Etherhiding C2 via Blockchain Connection"
references = [
    "https://secureannex.com/blog/sleepyduck-malware/"
]
risk_score = 73
rule_id = "bba8c7d1-172b-435d-9034-02ed9289c628"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
type = "eql"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Potential Etherhiding C2 via Blockchain Connection

Etherhiding is an advanced command and control technique where threat actors store malicious configurations, commands, or payload URLs within blockchain transactions on platforms like Ethereum or Binance Smart Chain. This approach provides a highly resilient and censorship-resistant C2 infrastructure since blockchain data cannot be taken down or modified. This detection rule identifies script interpreters or suspicious processes connecting to blockchain API endpoints that may be retrieving attacker-controlled data from the blockchain.

### Possible investigation steps

- Review the process.name and process.executable fields to identify which application is making blockchain API requests and assess whether cryptocurrency or Web3 functionality is expected on this system.
- Examine the destination.domain and dns.question.name fields to identify the specific blockchain API endpoint being queried, such as Infura, Alchemy, or public RPC endpoints.
- Analyze the process.command_line and process.args to understand what code or script is executing and look for hardcoded contract addresses or wallet addresses that may be querying blockchain data.
- Investigate the process.parent.executable and parent process chain to determine how the blockchain-querying process was launched and identify the initial execution vector.
- Review network connection payloads if available to identify the specific blockchain queries being made and extract any contract addresses or transaction hashes being queried.
- Search threat intelligence sources for the identified contract addresses or wallet addresses to determine if they are associated with known malicious campaigns.
- Correlate with file modification events on the same host to identify if the blockchain data is being written to disk or used to configure malware.

### False positive analysis

- Cryptocurrency wallet applications and browser extensions legitimately access blockchain APIs to display balances and transaction history. Verify if the user has approved cryptocurrency applications.
- Web3 developers and blockchain application developers may use blockchain APIs during development and testing. Confirm with development teams if such activities are expected.
- Decentralized application (dApp) browsers and related tools access blockchain data as part of normal operations. Verify if these tools are sanctioned for business use.
- NFT marketplaces and related applications may query blockchain data for asset verification. Confirm if such applications are approved.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further C2 communication or payload retrieval.
- Terminate the suspicious process making blockchain API connections and prevent it from restarting.
- Extract and analyze the blockchain contract addresses or transaction data being queried to understand the malicious payload or configuration.
- Conduct a thorough malware analysis of the responsible application to identify its full capabilities and persistence mechanisms.
- Block the identified blockchain API endpoints at the network perimeter if they are not required for legitimate business purposes.
- Search for similar blockchain API connections across other endpoints to identify potential lateral movement or additional compromised systems.
- Escalate to the security operations team for comprehensive incident response if the activity confirms an active Etherhiding-based attack.
"""
query = '''
sequence by process.entity_id with maxspan=15s
  [network where host.os.type == "macos" and event.type == "start" and
    (process.name in ("bash", "sh", "zsh", "osascript", "node", "Cursor", "Cursor Helper (Plugin)", "Windsurf", "Windsurf Helper (Plugin)") or
    process.name like ("python*", "ruby*", "perl*", "tclsh*")) and
    destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.com",
                              "*.drpc.org", "polygon-rpc.com", "polygon-mainnet*", "*.polygon.technology",
                              "bsc-dataseed*", "*.bnbchain.org", "arb1.arbitrum.io", "mainnet.base.org",
                              "rpc.ankr.com", "*.infura.io", "*.alchemy.com", "*.quiknode.pro",
                              "*.publicnode.com", "*.chainstack.com")]
  [file where host.os.type == "macos" and event.action == "modification" and file.extension in ("js", "py", "sh")]
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1102"
name = "Web Service"
reference = "https://attack.mitre.org/techniques/T1102/"

[[rule.threat.technique.subtechnique]]
id = "T1102.001"
name = "Dead Drop Resolver"
reference = "https://attack.mitre.org/techniques/T1102/001/"

[[rule.threat.technique.subtechnique]]
id = "T1102.002"
name = "Bidirectional Communication"
reference = "https://attack.mitre.org/techniques/T1102/002/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.002"
name = "AppleScript"
reference = "https://attack.mitre.org/techniques/T1059/002/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[rule.threat.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"

[[rule.threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[rule]
description = """
Identifies an attempt to exploit a local privilege escalation via the unshare command. The unshare command allows a
process to create a new namespace and set the capabilities of the process. This can be used to escalate privileges to
root.
"""
id = "f483675e-1c8f-4ce4-80b3-34c646911385"
license = "Elastic License v2"
name = "Potential Local Privilege Escalation via Unshare"
os_list = ["linux"]
version = "1.0.1"

query = '''
sequence by process.parent.entity_id with maxspan=60s
  [process where event.action == "exec" and event.type == "start" and 
  process.name == "unshare" and process.args in ("-r", "-rm", "-m", "-U", "--user") and user.id != 0]
  [process where event.action == "uid_change" and event.type == "change" and user.id == 0 and process.parent.user.id != 0]
'''

min_endpoint_version = "8.2.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 1

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[internal]
min_endpoint_version = "8.2.0"

[metadata]
creation_date = "2024/01/08"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/07/17"

[rule]
author = ["Elastic"]
description = """
Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the
user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to
change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage
a misconfiguration for exploitation in order to escalate their privileges to root.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Privilege Escalation via CAP_SETUID/SETGID Capabilities"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Privilege Escalation via CAP_SETUID/SETGID Capabilities

In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.

### Possible investigation steps

- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious.
- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector.
- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise.
- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent.
- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack.
- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes.

### False positive analysis

- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list.
- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule.
- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns.
- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations.
- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs.
- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation.
- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation.
- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state.
- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats in the future.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
risk_score = 47
rule_id = "9b80cb26-9966-44b5-abbf-764fbdbc3586"
setup = """## Setup


This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and
   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and
   user.id != "0" and not (
     process.parent.executable : ("/tmp/newroot/*", "/opt/carbonblack*") or
     process.parent.executable in (
       "/opt/SolarWinds/Agent/bin/Plugins/JobEngine/SolarWinds.Agent.JobEngine.Plugin", "/usr/bin/vmware-toolbox-cmd",
       "/usr/bin/dbus-daemon", "/usr/bin/update-notifier", "/usr/share/language-tools/language-options",
       "/opt/SolarWinds/Agent/*", "/usr/local/sbin/lynis.sh", "/usr/libexec/sssd/sssd_be",
       "/opt/sophos-spl/plugins/edr/bin/osqueryd.5", "/apps/dynatrace/oneagent/install/agent/lib64/oneagentos",
       "/opt/SolarWinds/Agent/bin/Plugins/Discovery/SolarWinds.Agent.Discovery.Plugin",
        "/usr/sbin/pcoip-agent", "/usr/bin/cubic", "/usr/lib/cockpit/cockpit-ws",
       "/usr/lib/vmware/bin/vmware", "/usr/bin/vmware-fuseUI"
     ) or
     process.executable : ("/opt/dynatrace/*", "/tmp/newroot/*", "/opt/SolarWinds/Agent/*", "/snap/snapd/*/usr/lib/snapd/snap-confine") or
     process.executable in (
       "/bin/fgrep", "/usr/bin/sudo", "/usr/bin/pkexec", "/usr/lib/cockpit/cockpit-session", "/usr/sbin/suexec",
       "/usr/bin/at", "/usr/lib/pcoip-agent/pcoip-authentication-proxy"
     ) or
     process.parent.name in ("update-notifier", "language-options", "osqueryd", "saposcol", "dbus-daemon", "osqueryi", "sdbrun") or
     process.command_line like ("sudo*BECOME-SUCCESS*", "/bin/sh*sapsysinfo.sh*", "sudo su", "sudo su -", "sudo -E -H bash -l") or
     process.name in ("sudo", "fgrep", "lsb_release", "apt-update", "dbus-daemon-launch-helper", "man") or
     process.parent.command_line like "/usr/bin/python*ansible*" or
     process.working_directory like ("/opt/Elastic/Agent/data/*", "/usr/sap/tmp") or
     process.args like ("/usr/bin/lsb_release*", "/bin/fgrep*")
   )]
  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
   and user.id == "0"]
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.001"
name = "Setuid and Setgid"
reference = "https://attack.mitre.org/techniques/T1548/001/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.001"
name = "Setuid and Setgid"
reference = "https://attack.mitre.org/techniques/T1548/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"