[New Rule] Potential Fileless Execution via O_TMPFILE

[Aegrah]

Summary

Adding additional coverage for fileless execution via O_TMPFILE.

Reference: https://matheuzsecurity.github.io/hacking/fileless-loader-bypassing-elastic-memfd/

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[Copilot]

🟡 Changes recommended

Several rule fields need corrections/alignments (index pattern, references, tags, and description/setup text mismatches with the implemented query) before it can be safely approved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR adds a new Linux EQL detection rule intended to identify potential fileless ELF execution patterns associated with anonymous temporary executables (e.g., O_TMPFILE/execveat-style execution).

Changes:

• Introduces a new Linux EQL rule file with metadata, query, and MITRE ATT&CK mapping.
• Adds an investigation guide (note) and setup guidance.
• Configures indices/integrations and tags for multiple endpoint telemetry sources.

File summaries

File	Description
rules/linux/defense_evasion_fileless_execution_via_o_tempfile.toml	New Linux EQL rule and investigation guide for potential fileless execution via anonymous temporary executable paths.

Review details

Suppressed comments (2)

rules/linux/defense_evasion_fileless_execution_via_o_tempfile.toml:33

• The investigation guide intro states the rule detects files created with O_TMPFILE and executed via execveat/AT_EMPTY_PATH, but the current query only looks for process.executable matching an anonymous /#<digits> path. Update the guide text to avoid over-asserting how the executable was created/executed.

This rule detects Linux processes launched from anonymous temporary files created with O_TMPFILE, a pattern associated with execveat and AT_EMPTY_PATH execution that leaves no normal filesystem pathname. An attacker can write a malicious ELF payload into an unnamed file descriptor and execute it directly, reducing disk artifacts and making the payload harder to discover through routine file inspection.

rules/linux/defense_evasion_fileless_execution_via_o_tempfile.toml:66

• The setup section says the rule requires Elastic Defend, but the rule is configured for multiple integrations/data sources (Auditd Manager, CrowdStrike, SentinelOne, Endgame) via integration and index. Update the setup text to reflect that Elastic Defend is one supported source rather than the only requirement.

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup

• Files reviewed: 1/1 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[bryans3c]

One nit, LGTM!

[eric-forte-elastic]

Good rule 👍

[elastic-vault-github-plugin-prod]

⛔️ Test failed

Results

• ❌ Potential Fileless Execution via O_TMPFILE (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta