Process Execution Followed by Self-Deletion

[metadata]
creation_date = "2026/08/19"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/08/31"

[rule]
author = ["Elastic"]
description = """
Detects a process execution followed by immediate self-deletion, a common technique used by adversaries to
remove traces of their activity on the system. This pattern is often observed in malware and APT campaigns.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Process Execution Followed by Self-Deletion"
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 Process Execution Followed by Self-Deletion

This rule detects a Linux process launched from a temporary, shared-memory, web, or file-descriptor path whose executable is deleted within 30 seconds, a pattern that can erase evidence and hinder analysis. An attacker may drop a payload in `/dev/shm`, execute it to establish access or run malicious commands, and immediately unlink the file while the process continues running.

### Possible investigation steps

- Reconstruct the process tree and review the command line, user, working directory, execution context, and parent legitimacy to determine whether the activity was expected.
- If the process remains active, preserve volatile evidence such as its executable through `/proc/<pid>/exe`, memory, open file descriptors, and cryptographic hashes before containment.
- Correlate nearby child processes, file modifications, persistence changes, DNS requests, and network connections to identify payload behavior and command-and-control activity.
- Trace how the executable reached the host using file-creation events, download records, shell activity, web-server logs, authentication events, and relevant audit telemetry.
- Search the environment for the same hash, command line, user, parent process, destination infrastructure, or deletion pattern, then isolate affected hosts and revoke exposed credentials when malicious activity is confirmed.

### False positive analysis

- Legitimate installation, update, or maintenance scripts may execute a temporary helper from `/tmp`, `/var/tmp`, or `/run` and remove it after completion; verify the parent process, package or change records, signer or hash reputation, and timing against approved activity.
- Administrators or applications may intentionally run short-lived executables from shared memory, web directories, or file descriptors and unlink them immediately; confirm the initiating user, command line, expected application workflow, and absence of suspicious child processes or network activity.

### Response and remediation

- Isolate affected Linux hosts from the network while preserving access for responders, and terminate malicious processes after capturing `/proc/<pid>/exe`, memory, open file descriptors, hashes, and active connections.
- Remove related payloads and persistence from cron jobs, systemd units, shell profiles, SSH `authorized_keys`, startup scripts, web directories, temporary paths, and shared-memory locations.
- Revoke or rotate credentials, API keys, SSH keys, and session tokens used by the malicious process or exposed on the host, and block identified hashes, domains, IP addresses, and download sources.
- Reimage the host or restore it from a verified known-good backup when system integrity cannot be established, then validate packages, configurations, accounts, services, and security tooling before reconnecting it.
- Escalate to incident response immediately if the same payload or infrastructure appears on multiple hosts, privileged accounts were accessed, persistence is present, or command-and-control or data-exfiltration activity is identified.
- Prevent recurrence by restricting execution from `/tmp`, `/var/tmp`, `/dev/shm`, and web-writable directories where operationally feasible, correcting unsafe permissions, patching the initial access vector, and deploying detections for related hashes and behaviors.
"""
risk_score = 47
rule_id = "702a2046-ea74-4bdc-b8ea-b185471f64c8"
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",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id, host.id with maxspan=30s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
  process.executable like (
    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/var/www/*",
    "/proc/*/fd/*", "?memfd:*", "memfd:*"
  )] by process.executable
  [file where host.os.type == "linux" and event.action == "deletion"] by file.path
'''

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

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

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

    [[rule.threat.technique.subtechnique]]
    name = "File Deletion"
    id = "T1070.004"
    reference = "https://attack.mitre.org/techniques/T1070/004/"