Elastic rules: 0g

[metadata]
creation_date = "2025/10/01"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/18"

[rule]
author = ["Elastic"]
description = """
This rule monitors for attempts to clear logs using the "journalctl" command on Linux systems. Adversaries may use this
technique to cover their tracks by deleting or truncating log files, making it harder for defenders to investigate their
activities. The rule looks for the execution of "journalctl" with arguments that indicate log clearing actions, such as
"--vacuum-time", "--vacuum-size", or "--vacuum-files".
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Attempt to Clear Logs via Journalctl"
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 Attempt to Clear Logs via Journalctl

This detection flags attempts to purge systemd journal logs by invoking journalctl with vacuum options, which attackers use to erase evidence and impede investigations. A common pattern is a compromised user escalating to root and immediately running sudo journalctl --vacuum-time=1s or --vacuum-size=1M, sometimes via a script or cron job, to rapidly truncate the journal across all boots and hide prior execution traces.

### Possible investigation steps

- Enrich with user/UID, effective privileges, parent and command-line, session/TTY, and origin (SSH IP or local), and determine if execution came from a scheduled job (cron/systemd timer) or a script.
- Quantify destructiveness by extracting the exact vacuum parameter value(s) and immediately checking journal state (journalctl --disk-usage and --list-boots) and /var/log/journal size/mtime to see how much history was removed.
- Inspect configuration and persistence paths for intentional log suppression, including recent changes in /etc/systemd/journald.conf (Storage=volatile, SystemMaxUse, SystemMaxFileSize, MaxRetentionSec) and any new systemd units or scripts invoking journalctl vacuum.
- Correlate the vacuum timestamp with preceding activity to identify what might be concealed (privilege escalation, new accounts, sudoers edits, suspicious binaries), using auditd/EDR telemetry and shell history to rebuild the timeline.
- Verify remote log forwarding and SIEM ingestion for this host, compare gaps around the vacuum time, and recover pre-vacuum events from central storage to assess impact and intent.

### False positive analysis

- A sysadmin or maintenance script ran journalctl --vacuum-time or --vacuum-size to reclaim space on a host under log disk pressure, which should correlate with low-free-space alerts, approved retention policy, and a scheduled systemd timer or cron job.
- OS provisioning or image-preparation steps vacuumed the journal with journalctl --vacuum-files to sanitize logs before snapshotting, typically a one-time root action occurring near installation and matching documented build procedures.

### Response and remediation

- Immediately kill any active journalctl vacuum invocation (e.g., pkill -x journalctl), lock or remove sudo for the initiating user, and network-quarantine the host to prevent further tampering.
- Remove persistence by disabling systemd units/timers and cron jobs that call "journalctl --vacuum-*", inspecting /etc/systemd/system/* for ExecStart=journalctl vacuum and /etc/crontab, /etc/cron.*, and user crontabs, then deleting the offending scripts.
- Recover logging by setting Storage=persistent and policy-compliant SystemMaxUse/SystemMaxFileSize/MaxRetentionSec in /etc/systemd/journald.conf, restarting systemd-journald, and backfilling missing events from central log archives.
- Harden by enabling remote forwarding (ForwardToSyslog=yes and rsyslog/syslog-ng to SIEM), adding auditd rules to alert on "journalctl --vacuum-*", and tightening sudoers to require MFA and record command I/O for journalctl on critical hosts.
- Preserve evidence by archiving remaining /var/log/journal entries, journald.conf and its mtime, modified unit files under /etc/systemd/system, and shell/auth logs, and capture a disk snapshot before making further changes.
- Escalate to incident response if root executed "journalctl --vacuum-time/size/files" outside a documented maintenance window, if Storage=volatile was set or retention reduced below policy, or if the same actor performed vacuums on multiple hosts within 24 hours.
"""
risk_score = 47
rule_id = "09073bf4-a8ea-4bce-9fd5-2bb56b4d31f4"
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: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "journalctl" and process.args like ("--vacuum-time=*", "--vacuum-size=*", "--vacuum-files=*") and
not process.parent.args == "/etc/cron.daily/clean-journal-logs"
'''

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

[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"

[[rule.threat.technique.subtechnique]]
id = "T1070.002"
name = "Clear Linux or Mac System Logs"
reference = "https://attack.mitre.org/techniques/T1070/002/"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

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

[metadata]
creation_date = "2024/04/16"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS
snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit
ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data
in an environment they control. This activity often precedes data exfiltration or persistence operations, where the
attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation.
"""
event_category_override = "event.type"
false_positives = [
    """
    AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS EC2 EBS Snapshot Shared or Made Public"
note = """## Triage and analysis 

### Investigating AWS EC2 EBS Snapshot Shared or Made Public

This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable.

#### Possible investigation steps:

**Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`).

**Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host.

**Examine the scope of the change**:
  - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list.  
    - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious.  
    - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party.  
  - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status.  
  - Identify whether other snapshots or AMIs were shared in the same timeframe.

**Correlate with other activities**:
  - Search CloudTrail for related events involving the same actor or `source.ip`.  
    - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior.  
    - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact.  
  - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer.

**Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review.

### False positive analysis:

- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts.  
- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags.  
- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored.  

If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing.

### Response and remediation:

**Containment and validation**
- If unauthorized, immediately remove added permissions using the AWS CLI:  
  `aws ec2 modify-snapshot-attribute --snapshot-id <id> --create-volume-permission "Remove=[{UserId=<unauthorized_id>}]"`  
- Revoke public sharing (`group=all`) to prevent external access.  
- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only.

**Investigate for data exfiltration or persistence**
- Determine whether the shared snapshot was copied to another account (`CopySnapshot`).  
- Engage AWS Support if evidence suggests external copying or data theft.  
- Review subsequent API calls or IAM changes for further persistence or data movement.

**Strengthen detection and monitoring**
- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`.  
- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations.  
- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts.

**Recovery and hardening**
- Enable default encryption and validate that all snapshots remain private.  
- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide.  
- Audit existing snapshots to ensure no others have unauthorized permissions.  
- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts.

### Additional information

- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: reference playbooks for investigating data exfiltration and unauthorized access.  
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: example framework for developing custom playbooks for snapshot configuration and data protection.  
- **AWS Documentation**  
  - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)  
  - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)  
"""
references = [
    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump",
    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
]
risk_score = 47
rule_id = "4182e486-fc61-11ee-a05d-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"  
  and event.action == "ModifySnapshotAttribute"
  and event.outcome == "success"
  and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION")
  and stringContains (aws.cloudtrail.request_parameters, "add=")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"


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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[rule]
description = """
Identifies the presence of unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII
characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections.
"""
id = "2c7b91fa-f43d-46aa-887d-e5f3f032b29e"
license = "Elastic License v2"
name = "Command Obfuscation via Unicode Modifier Letters"
os_list = ["windows"]
reference = ["https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation"]
version = "1.0.1"

query = '''
process where event.action == "start" and user.id != "S-1-5-18" and
 (
   process.name : ("reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe") or
   process.pe.original_file_name in ("reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EX", "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe", "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe")
 ) and
 process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*""" and
 not (process.name : "cmd.exe" and process.parent.executable : ("C:\\Program Files\\Smaart Suite\\Smaart.exe", "C:\\Program Files (x86)\\NetDocuments\\ndOffice\\ndOffice.exe", "C:\\Program Files (x86)\\Smaart 8\\Smaart.exe", "E:\\Spectrum\\Notifier\\sd_notifier\\SD_Notifier.exe")) and
 not (process.name : "rundll32.exe" and process.args : "C:\\WINDOWS\\system32\\davclnt.dll,DavSetCookie")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"
[[threat.technique.subtechnique]]
id = "T1027.010"
name = "Command Obfuscation"
reference = "https://attack.mitre.org/techniques/T1027/010/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2020/11/23"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/06/30"

[rule]
author = ["Elastic"]
description = "Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool."
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Credential Acquisition via Registry Hive Dumping"
references = [
    "https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8",
    "https://www.elastic.co/security-labs/detect-credential-access",
]
risk_score = 73
rule_id = "a7e7bfa3-088e-4f13-b29e-3986e0e756b8"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Sysmon",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
 (?process.pe.original_file_name == "reg.exe" or process.name : "reg.exe") and
 process.args : ("save", "export") and
 process.args : (
   "hklm\\sam", "hklm\\security", "hklm\\system",
   "hkey_local_machine\\sam", "hkey_local_machine\\security", "hkey_local_machine\\system"
 )
'''

note = """## Triage and analysis

### Investigating Credential Acquisition via Registry Hive Dumping

#### Possible investigation steps

- What exact hive-export behavior did the alert capture?
  - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, and `process.code_signature.subject_name`.
  - Implication: escalate if the command saves or exports SAM or SECURITY to temp, public, admin-share, UNC, removable, or deceptive paths; lower suspicion only when the signed Microsoft reg.exe identity, destination, and export set fit the same recognized backup, recovery, forensic, or break-glass workflow. Identity alone never clears the export.

- Does the parent and session context explain why credential-bearing hives were exported?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
  - Hint: If the parent is generic and lineage remains unclear, expand ancestry before accepting a maintenance explanation.
  - Implication: escalate when an interactive shell, script host, RMM tool, service account, remote-style session, or unexpected user initiated the export; lower suspicion when the same user or service identity, parent workflow, and session type recur for a recognized backup, recovery, forensic, or break-glass process.

- Did the alert parent launch accompanying SYSTEM export, staging, transfer, cleanup, or alternate dump commands?
  - Focus: process events from the alert parent and reg.exe children, using `process.parent.entity_id`, `process.parent.pid`, `process.executable`, and `process.command_line`. $investigate_2 $investigate_3
  - Hint: If `process.parent.entity_id` is absent, use the `host.id` + alert `process.parent.pid` branch in a tight alert-time window; if reg.exe spawned a helper, pivot from alert `process.entity_id` to child `process.parent.entity_id`.
  - Hint: If file or network telemetry is available, recover file activity and connections for reg.exe and its children to identify hive output, archives, share writes, removable-media staging, or off-host transfer. Missing network telemetry is unresolved, not benign. $investigate_4 $investigate_5
  - Implication: escalate when the same parent exports SYSTEM, packages, copies, deletes, or transfers hive output, or launches vssadmin.exe, diskshadow.exe, or shadow-copy paths to continue dumping outside this rule; absence of same-parent support reduces staging evidence but does not clear the original export.

- Does the host role or hive combination raise credential-exposure severity?
  - Focus: `host.id`, `host.name`, and `process.command_line`, plus asset or case records only as corroboration.
  - Hint: Do not infer privileged role from `host.name` alone.
  - Implication: raise urgency when asset context or host history identifies a jump host, backup node, admin workstation, server, or shared management platform, or when same-parent process review confirms SYSTEM was exported with SAM or SECURITY; lower urgency only when the host role and export set fit the same recognized workflow.

- If local evidence remains suspicious or unresolved, does related alert scope show broader credential-access activity?
  - Focus: related alerts for the same `user.id` and `host.id`, looking for credential dumping, archiving, privilege escalation, persistence, or lateral movement.
  - Hint: Start with same-user alerts. $investigate_0
  - Hint: Compare same-host alerts. $investigate_1
  - Implication: broaden scope and credential review when related alerts show complementary abuse; keep the case local when related alert scope is quiet and local telemetry already binds the export to one recognized workflow.

- Based on the evidence gathered, what disposition is supported?
  - Focus: binary identity, hive targets and output path, parent/session context, same-parent or child-process activity, host exposure, and related-alert scope.
  - Implication: escalate when an unrecognized SAM or SECURITY export has a risky destination, suspicious lineage or session, follow-on staging, privileged-host exposure, or related credential-access alerts; close only when the same evidence categories bind one exact recognized workflow on this host, with outside confirmation if telemetry cannot prove legitimacy; preserve artifacts and escalate when evidence is mixed or incomplete.

### False positive analysis

- Backup, recovery, forensic, or break-glass workflows can legitimately export SAM or SECURITY hives. Confirm that the signed Microsoft utility identity, command-line hive and destination pattern, parent workflow, session context, `user.id`, `host.id`, host role, and same-parent or child-process activity all align with the same workflow. If telemetry cannot prove legitimacy, use case records, change records, or owner confirmation only as corroboration for that exact activity. If any evidence dimension contradicts the workflow, do not close as benign.
- Before creating an exception, validate that the same `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `process.command_line` hive/destination pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build from that minimum confirmed pattern. Avoid exceptions on `process.name`, reg.exe, the hive name, or the host alone.

### Response and remediation

- If confirmed benign, reverse any temporary restriction and document the recognized utility path, hive/destination pattern, parent and session context, `user.id`, `host.id`, host role, and corroborating case evidence that justified closure. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, `process.command_line`, output path named in the command, same-parent or child-process command lines, session context, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment tied to the findings, such as temporary share restriction or limited outbound access for the affected host; escalate to host isolation or account action only if staging, transfer commands, related alerts, or host criticality justify the impact.
- If confirmed malicious, preserve the same evidence set, then isolate the host if its role can tolerate it and the findings show unauthorized hive export or movement risk. Contain the responsible account only when the user/session evidence indicates account misuse. Terminate the process only after evidence capture if it is still running.
- Scope exposure from the copied material: SAM implies local account hash exposure; SECURITY implies LSA secret or cached-credential exposure; a same-parent SYSTEM export makes offline decryption more plausible and should raise urgency.
- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same command patterns, hive-copy names, archive names, share paths, transfer commands, and alternate copy methods such as vssadmin.exe, diskshadow.exe, or raw shadow-copy access. Then remove only the unauthorized dump scripts, archives, copied hive files, and persistence mechanisms identified during the investigation, and remediate the access path that allowed the export.
- Post-incident hardening: restrict hive export activity to recognized recovery or forensic workflows, document the confirmed `process.command_line` and destination patterns behind any exception, and retain process telemetry needed to distinguish future recovery work from repeated abuse.
"""

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

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "host.name",
    "user.name",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.pe.original_file_name",
    "process.parent.entity_id",
    "process.parent.pid",
    "process.parent.executable",
    "process.parent.command_line",
    "process.code_signature.subject_name",
    "process.Ext.session_info.logon_type",
]

[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Processes from same parent as alert"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.parent.pid}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Child processes of reg.exe"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File activity for reg.exe and children"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Network activity for reg.exe and children"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[rule.threat.technique.subtechnique]]
id = "T1003.002"
name = "Security Account Manager"
reference = "https://attack.mitre.org/techniques/T1003/002/"

[[rule.threat.technique.subtechnique]]
id = "T1003.004"
name = "LSA Secrets"
reference = "https://attack.mitre.org/techniques/T1003/004/"

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

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

[rule]
author = ["Elastic"]
description = """
This rule identifies a sequence of events where a process named "entrypoint.sh" is started in a container, followed by a
network connection attempt. This sequence indicates a potential egress connection from an entrypoint in a container. An
entrypoint is a command or script specified in the Dockerfile and executed when the container starts. Attackers can use
this technique to establish a foothold in the environment, escape from a container to the host, or establish persistence.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Egress Connection from Entrypoint in Container"
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 Egress Connection from Entrypoint in Container

Containers, often used for deploying applications, start with an entrypoint script that initializes the environment. Adversaries may exploit this by embedding malicious commands to initiate unauthorized network connections, potentially breaching security boundaries. The detection rule monitors for processes named `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to external IPs, thus identifying potential threats.

### Possible investigation steps

- Review the process details for the `entrypoint.sh` script execution, focusing on the `process.entity_id` and `host.id` to understand the context of the container where the script was executed.
- Examine the network connection attempt details, particularly the `destination.ip`, to determine if the IP address is known to be malicious or associated with suspicious activity.
- Check the container's Dockerfile or image configuration to verify if the `entrypoint.sh` script is expected and whether it contains any unauthorized modifications or additions.
- Investigate the parent process of the network connection attempt using `process.parent.entity_id` to identify if there are any other suspicious processes or activities linked to the same parent.
- Correlate the event with other logs or alerts from the same `host.id` to identify any additional indicators of compromise or related suspicious activities within the same timeframe.

### False positive analysis

- Legitimate application updates or installations may trigger the rule if they involve network connections from the entrypoint script. To handle this, identify and whitelist specific applications or update processes that are known to perform such actions.
- Automated configuration management tools might execute scripts that initiate network connections as part of their normal operations. Exclude these tools by specifying their process names or parent entity IDs in the rule exceptions.
- Containers designed to perform network diagnostics or monitoring could naturally attempt connections to external IPs. Review and exclude these containers by their image names or specific entrypoint scripts.
- Development or testing environments often run scripts that connect to external services for integration testing. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
- Scheduled maintenance scripts that run periodically and require network access might be flagged. Document these scripts and create exceptions based on their execution schedule or specific network destinations.

### Response and remediation

- Immediately isolate the affected container to prevent further unauthorized network connections. This can be done by stopping the container or disconnecting it from the network.
- Conduct a thorough review of the `entrypoint.sh` script within the container to identify and remove any malicious commands or scripts that may have been injected.
- Analyze the network traffic logs to identify any external IP addresses that the container attempted to connect to. Block these IPs at the firewall level to prevent future connections.
- Check for any signs of lateral movement or attempts to escape the container to the host system. If detected, escalate to the security team for a comprehensive investigation.
- Restore the container from a known good backup if available, ensuring that the restored version is free from any malicious modifications.
- Implement additional monitoring on the affected host and container environment to detect any similar suspicious activities in the future.
- Report the incident to the appropriate internal security team or incident response team for further analysis and to update threat intelligence databases."""
risk_score = 47
rule_id = "c75d0c86-38d6-4821-98a1-465cff8ff4c8"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
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.entry_leader.entry_meta.type == "container" and process.name == "entrypoint.sh"] by process.entity_id
  [network where event.type == "start" and event.action == "connection_attempted" and process.executable != null 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"
       ) or
    // Excluding vast majority of noise
    (process.name like ("python*", "pip*") and destination.port == 443)
    )] by process.parent.entity_id
'''

[[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.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 = "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/"

[rule]
description = """
Identifies the execution of a PE File that was written by the Windows native TAR utility. Adversaries may compress
malicious content to bypass existing ingress tool transfer restrictions.
"""
id = "5b856290-d3f5-4b2f-9f49-e753ce4ade28"
license = "Elastic License v2"
name = "Execution of a Binary Dropped via Microsoft BSDTAR Archive Tool"
os_list = ["windows"]
version = "1.0.25"

query = '''
sequence with maxspan=5m
   [file where process.executable : "?:\\Windows\\Sys*\\tar.exe" and file.Ext.header_bytes : "4d5a*"] by file.path
   [process where event.action == "start" and not process.code_signature.trusted == true and
    process.executable : "C:\\*" and
    not process.hash.sha256 :
               ("762abab44d25a0e6441600f6ad3a08e8f07016774608d80edc71b5b90b1ac5d8",
                "70d994f269c652a3a5fb639251f8247a6d914bfde068eb807f6023909de89530",
                "68b41beae36e4aa7ba4237b6067ed36dc0c6e0d9d5453fd8d61af335d0efd37f",
                "70d994f269c652a3a5fb639251f8247a6d914bfde068eb807f6023909de89530",
                "e8368338fe5d2f0cc7529df9f3684ea6d79a627d2cc33b1685b8f7adcfa952ae",
                "82909875e911bb7b5c31a3338449368f62e1ff7cbc09829ed72e31789b1a0712",
                "40d20e6dfb0654419b289c71f3d048202550d462df1c41675b0c5f18b6bada14") and
    not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")] by process.executable
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2024/06/26"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects child processes spawned by Git hooks. Git hooks are scripts that Git executes before or after events
such as commit, push, and receive. The rule identifies child processes spawned by Git hooks that are not typically
spawned by the Git process itself. This behavior may indicate an attacker attempting to hide malicious activity by
leveraging the legitimate Git process to execute unauthorized commands.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "logs-crowdstrike.fdr*",
    "logs-sentinel_one_cloud_funnel.*",
    "endgame-*",
]
language = "eql"
license = "Elastic License v2"
name = "Git Hook Child Process"
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 Child Process

Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse.

### Possible investigation steps

- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process.
- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed.
- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful.
- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner.
- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise.
- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks.

### False positive analysis

- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers.
- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows.
- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening.
- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities.
- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables.
- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts.
- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations.
- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks.
- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected."""
references = [
    "https://git-scm.com/docs/githooks/2.26.0",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 21
rule_id = "7ce5e1c7-6a49-45e6-a101-0720d185667f"
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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
process.parent.name in (
  "applypatch-msg", "commit-msg", "fsmonitor-watchman", "post-update", "post-checkout", "post-commit",
  "pre-applypatch", "pre-commit", "pre-merge-commit", "prepare-commit-msg", "pre-push", "pre-rebase", "pre-receive",
  "push-to-checkout", "update", "post-receive", "pre-auto-gc", "post-rewrite", "sendemail-validate", "p4-pre-submit",
  "post-index-change", "post-merge", "post-applypatch"
) and
(
  process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
  process.name like ("php*", "perl*", "ruby*", "lua*") or
  process.executable like (
    "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*",
    "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*"
  )
) and
not process.name in ("git", "dirname")
'''

[[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/"

[metadata]
creation_date = "2026/06/30"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/06/30"

[rule]
author = ["Elastic"]
description = """
Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes
and can support privilege escalation, especially with ptrace or privileged containers. System identities and
controller-owned workloads are excluded.
"""
false_positives = [
    """
    Debug pods may legitimately use hostPID. Exclude trusted admin workflows after baselining.
    """,
]
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Pod Created With HostPID"
note = """## Triage and analysis

### Investigating GKE Pod Created With HostPID

HostPID visibility into host processes is high risk. Confirm whether the pod spec change was authorized.

### Investigation steps

- Review actor (`user.email`), target pod, and images in the audit request.
- Correlate with exec, secret access, or RBAC changes from the same identity.

### False positives

- Break-glass troubleshooting; tune by user or namespace.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://kubernetes.io/docs/concepts/security/pod-security-standards/",
    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
]
risk_score = 47
rule_id = "f2108687-553d-45ac-b8f0-d0efeac5d45f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and
event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and
gcp.audit.request.spec.hostPID:true and not user.email:system\:* and
not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
'''

[[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 = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

[metadata]
creation_date = "2023/01/12"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/06/05"

[rule]
author = ["Elastic"]
description = """
Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable
and use WSL to avoid detection.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Host File System Changes via Windows Subsystem for Linux"
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 Host File System Changes via Windows Subsystem for Linux

Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, facilitating seamless file access between systems. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, particularly those involving the Plan9FileSystem, to flag potential defense evasion attempts.

### Possible investigation steps

- Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}".
- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories.
- Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes.
- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern.
- Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access.

### False positive analysis

- Routine file operations by legitimate applications using WSL may trigger alerts. Identify and whitelist these applications to prevent unnecessary alerts.
- Development activities involving WSL, such as compiling code or running scripts, can generate false positives. Exclude specific development directories or processes from monitoring.
- Automated backup or synchronization tools that interact with WSL might be flagged. Configure exceptions for these tools by specifying their process names or file paths.
- System maintenance tasks that involve WSL, like updates or system checks, could be mistaken for suspicious activity. Schedule these tasks during known maintenance windows and adjust monitoring rules accordingly.
- Frequent downloads or file transfers to directories outside the typical user download paths may appear suspicious. Define clear policies for acceptable file paths and exclude them from alerts.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes associated with "dllhost.exe" that are linked to the Plan9FileSystem CLSID to stop ongoing malicious activities.
- Conduct a thorough review of recent file changes on the host system to identify and restore any unauthorized modifications or deletions.
- Revoke any unauthorized access or permissions granted to WSL that may have been exploited by the adversary.
- Update and patch the Windows Subsystem for Linux and related components to mitigate any known vulnerabilities that could be exploited.
- Monitor for any recurrence of similar activities by setting up alerts for processes and file operations involving "dllhost.exe" and the Plan9FileSystem.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = [
  "https://github.com/microsoft/WSL",
  "https://detect.fyi/the-interesting-case-of-wsl-for-payload-staging-bfaa0f69329a",
]
risk_score = 47
rule_id = "e88d1fe9-b2f4-48d4-bace-a026dc745d4b"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by process.entity_id with maxspan=5m
[process where host.os.type == "windows" and event.type == "start" and
 process.name : "dllhost.exe" and
  /* Plan9FileSystem CLSID - WSL Host File System Worker */
 process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"]
[file where host.os.type == "windows" and process.name : "dllhost.exe" and
  not file.path : "?:\\Windows\\Prefetch\\DLLHOST.exe-????????.pf"]
'''

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

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
"""


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

[[rule.threat.technique]]
id = "T1202"
name = "Indirect Command Execution"
reference = "https://attack.mitre.org/techniques/T1202/"

[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 = "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/"

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

[rule]
author = ["Elastic"]
description = """
Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal
RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and
path fingerprinting during reconnaissance.
"""
from = "now-9m"
index = ["logs-network_traffic.icmp-*"]
language = "kuery"
license = "Elastic License v2"
name = "ICMP Timestamp or Information Request from the Internet"
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 ICMP Timestamp or Information Request from the Internet

ICMP Timestamp and Information requests are legacy diagnostic messages. Inbound use from the Internet toward internal
hosts is uncommon in production networks and often indicates active scanning or OS fingerprinting.

### Possible investigation steps

- Review `source.ip` against threat intelligence and prior scan activity on the environment.
- Determine whether the targeted `destination.ip` is an exposed host, VPN concentrator, or mis-NATed internal asset.
- Look for adjacent port scans, SYN sweeps, or exploit attempts from the same source around the alert window.
- Check whether the destination host replied and whether follow-on connections were attempted.

### False positive analysis

- Some legacy network monitoring or SLA probes may still use ICMP Timestamp requests. Maintain exceptions for known
  monitoring source ranges after validation.
- Shared hosting or multi-tenant environments with overlapping address space may require destination-specific tuning.

### Response and remediation

- Block or rate-limit the external source at the perimeter if activity is unauthorized.
- Verify that the targeted internal host is not unintentionally exposed to the Internet.
- Increase monitoring on targeted assets for follow-on exploitation attempts."""
references = [
    "https://www.rfc-editor.org/rfc/rfc792",
    "https://nmap.org/book/host-discovery-techniques.html",
    "https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml",
]
risk_score = 21
rule_id = "81139742-4d3a-49f3-a6dd-e0fb9834f959"
setup = """## Setup

This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (`network_traffic.icmp`
data stream).
"""
severity = "low"
tags = [
    "Domain: Network",
    "Tactic: Discovery",
    "Tactic: Reconnaissance",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Data Source: Network Traffic",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:network_traffic.icmp
  and (network_traffic.icmp.request.type:(13 or 15) or icmp.request.type:(13 or 15))
  and destination.ip:(
    10.0.0.0/8 or
    172.16.0.0/12 or
    192.168.0.0/16
  )
  and not source.ip:(
    10.0.0.0/8 or
    100.64.0.0/10 or
    127.0.0.0/8 or
    169.254.0.0/16 or
    172.16.0.0/12 or
    192.168.0.0/16 or
    192.0.0.0/24 or
    192.0.0.0/29 or
    192.0.0.8/32 or
    192.0.0.9/32 or
    192.0.0.10/32 or
    192.0.0.170/32 or
    192.0.0.171/32 or
    192.0.2.0/24 or
    192.175.48.0/24 or
    192.31.196.0/24 or
    192.52.193.0/24 or
    192.88.99.0/24 or
    198.18.0.0/15 or
    198.51.100.0/24 or
    203.0.113.0/24 or
    224.0.0.0/4 or
    240.0.0.0/4 or
    "::1" or
    "FE80::/10" or
    "FF00::/8"
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1018"
name = "Remote System Discovery"
reference = "https://attack.mitre.org/techniques/T1018/"


[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1595"
name = "Active Scanning"
reference = "https://attack.mitre.org/techniques/T1595/"
[[rule.threat.technique.subtechnique]]
id = "T1595.001"
name = "Scanning IP Blocks"
reference = "https://attack.mitre.org/techniques/T1595/001/"



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

[metadata]
creation_date = "2020/09/02"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies Mshta.exe making outbound network connections. This may indicate adversarial activity, as Mshta is often
leveraged by adversaries to execute malicious scripts and evade detection.
"""
from = "now-20m"
index = [
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "winlogbeat-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Mshta Making Network Connections"
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 Mshta Making Network Connections

Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. The detection rule identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. This approach helps in identifying unauthorized network connections indicative of malicious intent.

### Possible investigation steps

- Review the process tree to understand the parent-child relationship of mshta.exe, focusing on any unusual or unexpected parent processes that are not excluded by the rule, such as Microsoft.ConfigurationManagement.exe or known benign executables.
- Analyze the command-line arguments used by mshta.exe to identify any suspicious or unexpected scripts being executed, especially those not matching the excluded ADSelfService_Enroll.hta.
- Examine the network connections initiated by mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints.
- Check for any related alerts or logs from the same host around the time of the mshta.exe activity to identify potential lateral movement or additional malicious behavior.
- Investigate the user account associated with the mshta.exe process to determine if it has been compromised or is exhibiting unusual activity patterns.

### False positive analysis

- Mshta.exe may be triggered by legitimate software updates or installations, such as those from Microsoft Configuration Management. To handle this, add exceptions for processes with parent names like Microsoft.ConfigurationManagement.exe.
- Certain applications like Amazon Assistant and TeamViewer may use Mshta.exe for legitimate purposes. Exclude these by specifying their executable paths, such as C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe and C:\\TeamViewer\\TeamViewer.exe.
- Custom scripts or internal tools that utilize HTA files for automation might cause false positives. Identify these scripts and exclude them by their specific arguments, such as ADSelfService_Enroll.hta.
- Regularly review and update the list of exceptions to ensure that only verified benign activities are excluded, minimizing the risk of overlooking genuine threats.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate the mshta.exe process if it is confirmed to be making unauthorized network connections.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files.
- Review and analyze the process tree and network connections associated with mshta.exe to identify any additional compromised processes or systems.
- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
- Implement application whitelisting to prevent unauthorized execution of mshta.exe and similar system binaries.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
references = [
    "https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
]
risk_score = 47
rule_id = "c2d90150-0133-451c-a783-533e736c12d7"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by process.entity_id with maxspan=10m
  [process where host.os.type == "windows" and event.type == "start" and process.name : "mshta.exe" and
     not process.parent.name : "Microsoft.ConfigurationManagement.exe" and
     not (process.parent.executable : "C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe" or
          process.parent.executable : "C:\\TeamViewer\\TeamViewer.exe") and
     not process.args : "ADSelfService_Enroll.hta"]
  [network where host.os.type == "windows" and process.name : "mshta.exe"]
'''

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

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[rule.threat.technique.subtechnique]]
id = "T1218.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"



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

[metadata]
creation_date = "2025/11/11"
integration = ["endpoint"]
maturity = "production"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.3.0"
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
Identifies newly seen removable devices by device.serial_number and host.id using the Elastic Defend device mount events. While this activity
is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices.
"""
from = "now-9m"
index = ["logs-endpoint.events.device-*"]
language = "kuery"
license = "Elastic License v2"
name = "New USB Storage Device Mounted"
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 New USB Storage Device Mounted

Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts.

This detection uses Elastic Defend device control events, Device control helps protect your Windows and Mac endpoints from data loss, malware, and unauthorized access by managing which devices can connect to your computers. Specifically, it restricts which external USB storage devices can connect to hosts that have Elastic Defend installed.


### Possible investigation steps

- Review the device mount event details to confirm the presence of a new device by checking the device.serial_number.
- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration.
- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere.
- Analyze any related alerts or logs for additional context or suspicious activities linked to the device.

### False positive analysis

- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system.
- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts.
- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts.
- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives.
- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening.

### Response and remediation

- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware.
- Block the device by serial number using the relevant Elastic Defend Device Control policy.
- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device.
- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action.
- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats.
- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated.
- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections."""
references = [
"https://www.elastic.co/docs/solutions/security/manage-elastic-defend/trusted-devices", 
"https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-an-integration-policy-for-elastic-defend#device-control"
]
risk_score = 21
rule_id = "483832a8-ffdd-4e11-8e96-e0224f7bda9b"
severity = "low"
tags = [
    "Domain: Endpoint", 
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Use Case: Device Control",
    "Tactic: Initial Access",
    "Tactic: Exfiltration",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:(macos or windows) and event.type:device and event.action:mount and event.outcome:success and volume.removable:true
'''


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

[[rule.threat.technique]]
id = "T1091"
name = "Replication Through Removable Media"
reference = "https://attack.mitre.org/techniques/T1091/"

[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 = "T1052"
name = "Exfiltration Over Physical Medium"
reference = "https://attack.mitre.org/techniques/T1052/"

[[rule.threat.technique.subtechnique]]
id = "T1052.001"
name = "Exfiltration over USB"
reference = "https://attack.mitre.org/techniques/T1052/001/"

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

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

[[rule.threat.technique]]
id = "T1091"
name = "Replication Through Removable Media"
reference = "https://attack.mitre.org/techniques/T1091/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[rule.new_terms]
field = "new_terms_fields"
value = ["device.serial_number", "host.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[rule]
description = """
Detects when a script interpreter executes via a shell (sh, bash, zsh) or osascript with only a single argument, being
the process name and followed immediately by a network connection. This activity occurs when script code gets piped to
the interpreter via a shell and that code is intended to reach out to an external destination like a C2 server.
"""
id = "e413073c-4d6b-40d4-9ef1-b4de22d137d3"
license = "Elastic License v2"
name = "Payload Piped to Script Interpreter"
os_list = ["macos"]
reference = ["https://github.com/nnsee/fileless-elf-exec"]
version = "1.0.14"

query = '''
sequence by process.parent.entity_id with maxspan=10s
[process where event.type == "start" and event.action == "exec" and
  process.name like~ ("zsh", "sh", "bash", "python*", "terminal") and
  process.args == "-c" and
  (
    process.command_line : ("*curl*|*", "*nscurl*|*", "*wget*|*", "*osascript*|*",
                            "*/dev/tcp/*", "*base64*|*", "*openssl*|*", "*nc *|*") or
    process.command_line : ("*curl*>*", "*wget*>*") or
    process.command_line : "*http*|*"
  )]
[process where event.type == "start" and event.action == "exec" and 
  process.name like~ ("python*", "perl*", "ruby*", "osascript") and
  process.parent.name in ("sh", "bash", "zsh", "osascript") and 
  process.args like~ ("python*", "perl*", "ruby*", "osascript") and 
  process.args_count == 1]
'''

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

[[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.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[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.3.0"

[metadata]
creation_date = "2024/01/31"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies processes loading Active Directory related modules followed by a network connection to the ADWS dedicated TCP
port. Adversaries may abuse the ADWS Windows service that allows Active Directory to be queried via this web service.
"""
from = "now-9m"
index = ["logs-endpoint.events.library-*", "logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Enumeration via Active Directory Web Service"
references = ["https://github.com/FalconForceTeam/SOAPHound"]
risk_score = 47
rule_id = "9c951837-7d13-4b0c-be7a-f346623c8795"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by process.entity_id with maxspan=3m
 [library where host.os.type == "windows" and
  dll.name : ("System.DirectoryServices*.dll", "System.IdentityModel*.dll") and
  not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and
  not process.executable :
                ("?:\\windows\\system32\\dsac.exe",
                 "?:\\program files\\powershell\\?\\pwsh.exe",
                 "?:\\windows\\system32\\windowspowershell\\*.exe",
                 "?:\\windows\\syswow64\\windowspowershell\\*.exe",
                 "?:\\program files\\microsoft monitoring agent\\*.exe",
                 "?:\\windows\\adws\\microsoft.activedirectory.webservices.exe")]
 [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and
  network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
'''

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
"""

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 Enumeration via Active Directory Web Service

Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes that load AD-related modules and establish network connections to the ADWS port, indicating potential unauthorized enumeration attempts.

### Possible investigation steps

- Review the process entity ID to identify the specific process that triggered the alert and gather details such as the process name, executable path, and user context.
- Examine the user ID associated with the process to determine if it belongs to a legitimate user or service account, and verify if the user has a history of accessing Active Directory resources.
- Investigate the network connection details, focusing on the destination IP address and port 9389, to identify the target server and assess if it is a legitimate Active Directory Web Service endpoint.
- Check for any recent changes or unusual activity on the host machine, such as new software installations or configuration changes, that could explain the loading of Active Directory-related modules.
- Correlate the alert with other security events or logs from the same timeframe to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort.

### False positive analysis

- Legitimate administrative tools or scripts may load Active Directory-related modules and connect to the ADWS port. To handle this, create exceptions for known administrative processes that regularly perform these actions.
- Scheduled tasks or automated scripts running under service accounts might trigger the rule. Identify these tasks and exclude their associated user IDs or process paths from the detection rule.
- Security or monitoring software that queries Active Directory for legitimate purposes can cause false positives. Review and whitelist these applications by adding their executable paths to the exclusion list.
- Development or testing environments where developers frequently interact with Active Directory services may generate alerts. Consider excluding specific user IDs or process paths associated with these environments to reduce noise.
- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or administrative practices.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified in the alert that are loading Active Directory-related modules and making network connections to the ADWS port.
- Conduct a thorough review of the affected system's user accounts and permissions to identify any unauthorized changes or access.
- Reset credentials for any accounts that were potentially compromised or used in the suspicious activity.
- Implement network segmentation to limit access to the ADWS port (9389) to only trusted systems and users.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Update and enhance monitoring rules to detect similar enumeration attempts in the future, focusing on unusual process behavior and network connections to critical services."""


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

[[rule.threat.technique]]
id = "T1018"
name = "Remote System Discovery"
reference = "https://attack.mitre.org/techniques/T1018/"

[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"

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

[[rule.threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"

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

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