Network Connections Initiated Through XDG Autostart Entry
Detects network connections initiated through Cross-Desktop Group (XDG) autostart entries for GNOME and XFCE-based Linux distributions. XDG Autostart entries can be used to execute arbitrary commands or scripts when a user logs in. This rule helps to identify potential malicious activity where an attacker may have modified XDG autostart scripts to establish persistence on the system.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/06/03"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects network connections initiated through Cross-Desktop Group (XDG) autostart entries for GNOME and XFCE-based Linux
11distributions. XDG Autostart entries can be used to execute arbitrary commands or scripts when a user logs in. This rule
12helps to identify potential malicious activity where an attacker may have modified XDG autostart scripts to establish
13persistence on the system.
14"""
15from = "now-9m"
16index = ["logs-endpoint.events.*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Network Connections Initiated Through XDG Autostart Entry"
20references = [
21 "https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html",
22 "https://hadess.io/the-art-of-linux-persistence/",
23 "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
24]
25risk_score = 47
26rule_id = "dd52d45a-4602-4195-9018-ebe0f219c273"
27setup = """## Setup
28
29This rule requires data coming in from one of the following integrations:
30- Elastic Defend
31- Auditbeat
32
33### Elastic Defend Integration Setup
34Elastic 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.
35
36#### Prerequisite Requirements:
37- Fleet is required for Elastic Defend.
38- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
39
40#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
41- Go to the Kibana home page and click "Add integrations".
42- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
43- Click "Add Elastic Defend".
44- Configure the integration name and optionally add a description.
45- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
46- 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).
47- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
48- 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.
49For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
50- Click "Save and Continue".
51- 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.
52For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
53
54### Auditbeat Setup
55Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
56
57#### The following steps should be executed in order to add the Auditbeat on a Linux System:
58- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
59- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
60- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
61- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
62- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
63
64#### Custom Ingest Pipeline
65For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
66"""
67severity = "medium"
68tags = [
69 "Domain: Endpoint",
70 "OS: Linux",
71 "Use Case: Threat Detection",
72 "Tactic: Persistence",
73 "Data Source: Elastic Defend",
74 "Resources: Investigation Guide",
75]
76timestamp_override = "event.ingested"
77type = "eql"
78
79query = '''
80sequence by host.id, process.entity_id with maxspan=1s
81 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
82 (process.parent.executable == "/usr/bin/xfce4-session") or
83 (process.executable == "/bin/sh" and process.args == "-e" and process.args == "-u" and
84 process.args == "-c" and process.args : "export GIO_LAUNCHED_DESKTOP_FILE_PID=$$;*")
85 )
86 ]
87 [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not (
88 destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
89 destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
90 "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
91 "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
92 "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
93 "FF00::/8", "172.31.0.0/16"
94 ) or
95 process.executable in (
96 "/usr/lib64/firefox/firefox", "/usr/lib/firefox/firefox", "/opt/forticlient/fortitraylauncher"
97 )
98 )
99 ]
100'''
101note = """## Triage and analysis
102
103> **Disclaimer**:
104> 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.
105
106### Investigating Network Connections Initiated Through XDG Autostart Entry
107
108XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.
109
110### Possible investigation steps
111
112- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
113- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
114- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
115- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
116- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
117- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.
118
119### False positive analysis
120
121- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
122- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
123- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
124- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.
125
126### Response and remediation
127
128- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
129- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
130- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
131- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
132- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
133- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
134- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture."""
135
136
137[[rule.threat]]
138framework = "MITRE ATT&CK"
139[[rule.threat.technique]]
140id = "T1547"
141name = "Boot or Logon Autostart Execution"
142reference = "https://attack.mitre.org/techniques/T1547/"
143[[rule.threat.technique.subtechnique]]
144id = "T1547.013"
145name = "XDG Autostart Entries"
146reference = "https://attack.mitre.org/techniques/T1547/013/"
147
148
149
150[rule.threat.tactic]
151id = "TA0003"
152name = "Persistence"
153reference = "https://attack.mitre.org/tactics/TA0003/"
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 Network Connections Initiated Through XDG Autostart Entry
XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.
Possible investigation steps
- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.
False positive analysis
- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.
Response and remediation
- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture.
References
Related rules
- APT Package Manager Configuration File Creation
- At Job Created or Modified
- Bash Shell Profile Modification
- Chkconfig Service Add
- Creation or Modification of Pluggable Authentication Module or Configuration