« Suspicious Execution from a Mounted Device Execution via Windows Subsystem for Linux »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.16

Potential Timestomp in Executable Files

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Timestomp in Executable Files

edit

Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-windows.sysmon_operational-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Sysmon
  • Resources: Investigation Guide

Version: 110

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Disclaimer: This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.

Investigating Potential Timestomp in Executable Files

This alert indicates that a process modified the creation timestamp of a file with an executable extension in a sensitive Windows directory or a common persistence location. Timestomping can be used to make recently created or modified files appear older and blend in with legitimate system content.

Possible investigation steps

  • Establish scope and validate context:
  • Identify the affected endpoint using host.name and host.id, and determine whether similar alerts or related file-timestamp changes are occurring on the same host.
  • Review user.name, user.domain, and user.id to understand whether the account typically performs administrative or software management activities on this endpoint.
  • Use @timestamp to bound a focused time window for pivots (for example, shortly before and after the change).
  • Assess the timestamp change behavior:
  • Compare winlog.event_data.PreviousCreationUtcTime to winlog.event_data.CreationUtcTime and note whether the timestamp was backdated, forward-dated, or aligned to an apparent baseline.
  • Identify whether multiple files were modified in the same window by searching for additional events on the same host.id and process.entity_id.
  • Evaluate the target file:
  • Review file.path, file.directory, file.name, and file.extension to determine whether the target is expected in that location and whether the name resembles a legitimate component for the directory.
  • If the file is in a Startup location, treat it as a potential persistence artifact and prioritize determining whether it later executed on the host.
  • If the file is in a system directory, assess whether the host role and recent maintenance activity could reasonably explain changes to that specific file.
  • Investigate the process responsible for the change:
  • Review process.executable and process.name for signs of an unusual execution location, unexpected binary name, or a process that does not normally manage files in the target directory.
  • Pivot using process.entity_id (or process.pid within a narrow time range) to reconstruct process ancestry and command context using your available process telemetry.
  • Look for additional activity by the same process in the same time window, such as other file modifications involving the same file.path or other executable files in similar directories.
  • Check for follow-on execution and related activity:
  • Search for subsequent activity on the same host.id where process.executable matches the alerted file.path, which can indicate the modified file was executed after timestomping.
  • If the target is a shortcut (file.extension such as lnk), look for later execution on the host that aligns with user logon activity for user.id and the alert timeline.
  • Identify whether the same file.name and file.path appear on other endpoints, which may indicate propagation, a shared deployment mechanism, or a broader intrusion set.

False positive analysis

  • Enterprise software deployment, patching, and self-update mechanisms can rewrite binaries and adjust file metadata as part of normal operations.
  • Backup, restore, profile reset, and file synchronization workflows can preserve or reapply timestamps when placing executables into directories.
  • Administrative troubleshooting or recovery activities (for example, repairing installations or restoring components) may result in unexpected timestamp changes for legitimate files.

Response and remediation

  • If the activity is unexpected or suspicious:
  • Contain the host to limit further tampering and reduce the risk of execution or persistence.
  • Preserve evidence for the alert by capturing the values of file.path, process.executable, process.entity_id, user.id, and the before/after timestamps, and collect related events on the same host.id in the surrounding window.
  • Determine whether the affected file executed after the change by correlating activity on the same host.id and comparing process.executable to the alerted file.path.
  • Acquire and analyze the target file and the modifying process binary using your standard tooling to assess reputation, integrity, and suspected origin.
  • Remove or quarantine malicious files and remediate unauthorized persistence, especially for items placed in Startup locations.
  • Scope across the environment for the same file.path, file.name, and process.executable, and apply containment actions to additional affected hosts as needed.
  • If compromise is suspected, review access associated with user.id and follow incident response procedures for account containment and recovery.
  • If the activity is confirmed benign:
  • Document the legitimate software or workflow responsible for the timestamp change, including the expected process.executable and target paths, to support consistent triage and future tuning.

Setup

edit

Setup

Sysmon must be installed and configured to generate the events used by this rule (Event ID 2). Setup instructions: https://ela.st/sysmon-event-2-setup

Rule query

edit
file where host.os.type == "windows" and
  event.provider == "Microsoft-Windows-Sysmon" and event.code == "2" and
  file.extension : (
    "exe", "dll", "sys", "msi", "scr", "pif", "lnk"
  ) and
  file.path : (
    "?:\\Windows\\System32\\*",
    "?:\\Windows\\SysWOW64\\*",
    "?:\\ProgramData\\*",
    "?:\\Users\\Public\\*",
    "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
    "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*"
  ) and
  not process.executable : (
    "?:\\Program Files\\*",
    "?:\\Program Files (x86)\\*",
    "?:\\Windows\\system32\\cleanmgr.exe",
    "?:\\Windows\\system32\\msiexec.exe",
    "?:\\Windows\\syswow64\\msiexec.exe",
    "?:\\Windows\\system32\\svchost.exe",
    "?:\\Windows\\System32\\Robocopy.exe",
    "?:\\Windows\\SysWOW64\\Robocopy.exe"
  ) and
  not (process.executable : "?:\\Windows\\System32\\spoolsv.exe" and file.path : "?:\\Windows\\System32\\spool\\*") and
  not user.name : ("SYSTEM", "Local Service", "Network Service")

Framework: MITRE ATT&CKTM

« Suspicious Execution from a Mounted Device Execution via Windows Subsystem for Linux »