Process Execution Followed by Self-Deletion

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/19"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/08/31"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a process execution followed by immediate self-deletion, a common technique used by adversaries to
 11remove traces of their activity on the system. This pattern is often observed in malware and APT campaigns.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.process*", "logs-endpoint.events.file*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "Process Execution Followed by Self-Deletion"
 18note = """ ## Triage and analysis
 19
 20> **Disclaimer**:
 21> 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.
 22
 23### Investigating Process Execution Followed by Self-Deletion
 24
 25This 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.
 26
 27### Possible investigation steps
 28
 29- Reconstruct the process tree and review the command line, user, working directory, execution context, and parent legitimacy to determine whether the activity was expected.
 30- 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.
 31- Correlate nearby child processes, file modifications, persistence changes, DNS requests, and network connections to identify payload behavior and command-and-control activity.
 32- Trace how the executable reached the host using file-creation events, download records, shell activity, web-server logs, authentication events, and relevant audit telemetry.
 33- 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.
 34
 35### False positive analysis
 36
 37- 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.
 38- 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.
 39
 40### Response and remediation
 41
 42- 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.
 43- 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.
 44- 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.
 45- 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.
 46- 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.
 47- 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.
 48"""
 49risk_score = 47
 50rule_id = "702a2046-ea74-4bdc-b8ea-b185471f64c8"
 51setup = """## Setup
 52
 53This rule requires data coming in from Elastic Defend.
 54
 55### Elastic Defend Integration Setup
 56Elastic 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.
 57
 58#### Prerequisite Requirements:
 59- Fleet is required for Elastic Defend.
 60- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 61
 62#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 63- Go to the Kibana home page and click "Add integrations".
 64- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 65- Click "Add Elastic Defend".
 66- Configure the integration name and optionally add a description.
 67- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 68- 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).
 69- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 70- 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.
 71For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 72- Click "Save and Continue".
 73- 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.
 74For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 75"""
 76severity = "medium"
 77tags = [
 78    "Domain: Endpoint",
 79    "OS: Linux",
 80    "Use Case: Threat Detection",
 81    "Tactic: Defense Evasion",
 82    "Data Source: Elastic Defend",
 83    "Resources: Investigation Guide",
 84]
 85type = "eql"
 86query = '''
 87sequence by process.entity_id, host.id with maxspan=30s
 88  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
 89  process.executable like (
 90    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/var/www/*",
 91    "/proc/*/fd/*", "?memfd:*", "memfd:*"
 92  )] by process.executable
 93  [file where host.os.type == "linux" and event.action == "deletion"] by file.path
 94'''
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99  [rule.threat.tactic]
100  name = "Defense Evasion"
101  id = "TA0005"
102  reference = "https://attack.mitre.org/tactics/TA0005/"
103
104  [[rule.threat.technique]]
105  name = "Indicator Removal"
106  id = "T1070"
107  reference = "https://attack.mitre.org/techniques/T1070/"
108
109    [[rule.threat.technique.subtechnique]]
110    name = "File Deletion"
111    id = "T1070.004"
112    reference = "https://attack.mitre.org/techniques/T1070/004/"

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.

Related rules

to-top