XDG-Open Command Execution
This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system.
Rule type: eql
Rule indices:
- endgame-*
- logs-crowdstrike.fdr*
- logs-endpoint.events.process*
- logs-sentinel_one_cloud_funnel.*
- logs-auditd_manager.auditd-*
Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:
Tags:
- Domain: Endpoint
- OS: Linux
- Use Case: Threat Detection
- Tactic: Execution
- Data Source: Elastic Endgame
- Data Source: Elastic Defend
- Data Source: Crowdstrike
- Data Source: SentinelOne
- Data Source: Auditd Manager
- Resources: Investigation Guide
Version: 2
Rule authors:
- Elastic
Rule license: Elastic License v2
This rule requires data coming in from Elastic Defend.
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.
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the documentation.
- 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.
- 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.
- 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.
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.
This rule detects when the Linux xdg-open utility launches, which can indicate an attempt to hand a file or URL to the user’s default desktop application. That matters because attackers abuse this trusted helper to make malicious content appear as a normal user action and gain execution through user interaction. A common pattern is a script or archive invoking xdg-open on a local lure document or phishing URL so the desktop immediately opens it in the browser or document viewer.
- Trace the parent and ancestor chain to determine whether
xdg-openwas launched by a browser, email client, chat app, archive extractor, script interpreter, or remote shell, and assess whether that lineage matches normal user behavior. - Determine what was handed to
xdg-openand classify it as a local file or URL; for files, examine the path, hash, download origin, and recent creation time, and for URLs, review reputation, redirects, and whether the destination is a known phishing or malware host. - Correlate the event with nearby activity on the same host such as browser downloads, email attachment access, extraction of compressed archives, removable media access, or files written to temporary directories to identify the original delivery mechanism.
- Review the application that opened next and any follow-on child activity to see whether a browser, document viewer, or office suite subsequently spawned scripts, shell interpreters, network connections, or additional payloads.
- Validate the execution context by confirming an active graphical user session and the expected user account, since
xdg-openlaunched from headless, privileged, or automation contexts is more suspicious and may indicate script-driven abuse.
- A legitimate interactive desktop action such as a user clicking a help link, local document, or downloaded file can invoke
xdg-open, so verify the process has an expected GUI parent, runs in the user’s normal session, and opens a path or URL consistent with recent user activity. - Login, onboarding, or administrative scripts may use
xdg-opento launch an internal page or local documentation for users, so confirm the parent script or autostart entry is an approved file in a standard location and that the same command appears repeatedly for other users or hosts.
- Isolate the affected Linux host from the network except for approved management channels, stop the user from interacting further with the opened browser tab or document, and block the malicious URL, domain, and any downloaded file hashes across web, email, and endpoint controls.
- Terminate the malicious process chain launched after
xdg-open, quarantine the lure file or browser download, and remove persistence artifacts such as~/.config/autostartentries, user or systemsystemdunits, cron jobs, shell profile modifications, and unauthorized desktop launchers. - Reset the affected user’s passwords and revoke active sessions, tokens, and browser-stored credentials if
xdg-openled to a phishing page, credential prompt, or any site that could have captured authentication data. - Restore the host to a known-good state by reimaging or rolling back from a trusted baseline when the opened file or URL led to payload execution, unauthorized package installation, startup changes, or execution with elevated privileges.
- Escalate to incident response immediately if the same lure URL or document appears on multiple hosts, any root-level persistence or remote access tooling is found, or there are signs of lateral movement, data staging, or exfiltration.
- Harden the environment by patching browsers and document handlers, restricting script-driven
xdg-openuse from temporary or download directories where feasible, tightening email and web filtering for similar lures, and adding detections forxdg-openspawned by shell interpreters, archive extractors, chat clients, or remote shells.
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and (
process.name == "xdg-open" or
process.args in ("/bin/xdg-open", "/usr/bin/xdg-open", "/usr/local/bin/xdg-open", "xdg-open")
)
Framework: MITRE ATT&CK
Tactic:
- Name: Execution
- Id: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: User Execution
- Id: T1204
- Reference URL: https://attack.mitre.org/techniques/T1204/
Sub Technique:
- Name: Malicious Link
- Id: T1204.001
- Reference URL: https://attack.mitre.org/techniques/T1204/001/
Sub Technique:
- Name: Malicious File
- Id: T1204.002
- Reference URL: https://attack.mitre.org/techniques/T1204/002/
Sub Technique:
- Name: Malicious Copy and Paste
- Id: T1204.004
- Reference URL: https://attack.mitre.org/techniques/T1204/004/