Suspicious Symbolic Link Created

Identifies the creation of a symbolic link to a suspicious file or location. A symbolic link is a reference to a file or directory that acts as a pointer or shortcut, allowing users to access the target file or directory from a different location in the file system. An attacker can potentially leverage symbolic links for privilege escalation by tricking a privileged process into following the symbolic link to a sensitive file, giving the attacker access to data or capabilities they would not normally have.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/07/27"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/02/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the creation of a symbolic link to a suspicious file or location. A symbolic link is a reference to a file or
 11directory that acts as a pointer or shortcut, allowing users to access the target file or directory from a different
 12location in the file system. An attacker can potentially leverage symbolic links for privilege escalation by tricking a
 13privileged process into following the symbolic link to a sensitive file, giving the attacker access to data or
 14capabilities they would not normally have.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.process*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Suspicious Symbolic Link Created"
 21risk_score = 21
 22rule_id = "8a024633-c444-45c0-a4fe-78128d8c1ab6"
 23setup = """## Setup
 24
 25This rule requires data coming in from Elastic Defend.
 26
 27### Elastic Defend Integration Setup
 28Elastic 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.
 29
 30#### Prerequisite Requirements:
 31- Fleet is required for Elastic Defend.
 32- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 33
 34#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 35- Go to the Kibana home page and click "Add integrations".
 36- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 37- Click "Add Elastic Defend".
 38- Configure the integration name and optionally add a description.
 39- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 40- 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).
 41- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 42- 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.
 43For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 44- Click "Save and Continue".
 45- 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.
 46For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 47"""
 48severity = "low"
 49tags = [
 50    "Domain: Endpoint",
 51    "OS: Linux",
 52    "Use Case: Threat Detection",
 53    "Tactic: Privilege Escalation",
 54    "Tactic: Credential Access",
 55    "Data Source: Elastic Defend",
 56    "Resources: Investigation Guide",
 57]
 58timestamp_override = "event.ingested"
 59type = "eql"
 60query = '''
 61process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 62process.name == "ln" and process.args in ("-s", "-sf") and
 63  (
 64    /* suspicious files */
 65    (process.args in ("/etc/shadow", "/etc/shadow-", "/etc/shadow~", "/etc/gshadow", "/etc/gshadow-") or
 66    (process.working_directory == "/etc" and process.args in ("shadow", "shadow-", "shadow~", "gshadow", "gshadow-"))) or
 67
 68    /* suspicious bins */
 69    (process.args in ("/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh", "/bin/zsh", "/bin/ksh", "/bin/fish") or
 70    (process.working_directory == "/bin" and process.args : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or
 71    (process.args in ("/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh", "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish") or
 72    (process.working_directory == "/usr/bin" and process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or
 73
 74    /* suspicious locations */
 75    (process.args : ("/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.weekly/*", "/etc/cron.monthly/*")) or
 76    (process.args : ("/home/*/.ssh/*", "/root/.ssh/*","/etc/sudoers.d/*", "/dev/shm/*"))
 77  ) and
 78  process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
 79  not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 80'''
 81note = """## Triage and analysis
 82
 83> **Disclaimer**:
 84> 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.
 85
 86### Investigating Suspicious Symbolic Link Created
 87
 88Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries may exploit these links to redirect privileged processes to sensitive files, potentially escalating privileges or accessing restricted data. The detection rule identifies suspicious link creation by monitoring the execution of the 'ln' command with specific arguments and targets, especially when initiated by non-root users, indicating potential misuse.
 89
 90### Possible investigation steps
 91
 92- Review the process details to confirm the execution of the 'ln' command with suspicious arguments such as "-s" or "-sf" and verify the target files or directories listed in the query, like "/etc/shadow" or "/bin/bash".
 93- Check the user and group IDs associated with the process to ensure they are not root (ID "0"), as the rule specifically targets non-root users.
 94- Investigate the parent process name to determine if it is one of the shell processes listed in the query, such as "bash" or "zsh", which might indicate a user-initiated action.
 95- Examine the working directory and arguments to identify if the symbolic link creation is targeting sensitive locations like "/etc/cron.d/*" or "/home/*/.ssh/*".
 96- Analyze the user's recent activity and command history to understand the context and intent behind the symbolic link creation.
 97- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities involving the same user or system.
 98
 99### False positive analysis
100
101- Non-root users creating symbolic links for legitimate administrative tasks may trigger the rule. To manage this, identify and whitelist specific users or groups who regularly perform these tasks without malicious intent.
102- Automated scripts or applications that use symbolic links for configuration management or software deployment might be flagged. Review these processes and exclude them by specifying the script or application names in the detection rule.
103- Development environments where symbolic links are used to manage dependencies or version control can cause false positives. Exclude directories or processes associated with these environments to prevent unnecessary alerts.
104- Backup or synchronization tools that create symbolic links as part of their operation may be mistakenly identified. Identify these tools and add exceptions for their typical execution patterns.
105- System maintenance activities that involve symbolic link creation, such as linking to shared libraries or binaries, should be reviewed and excluded if they are part of routine operations.
106
107### Response and remediation
108
109- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
110- Terminate any suspicious processes related to the 'ln' command that are identified in the alert to stop any ongoing malicious activity.
111- Conduct a thorough review of the symbolic links created, especially those pointing to sensitive files or directories, and remove any unauthorized or suspicious links.
112- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack, focusing on those with elevated privileges.
113- Restore any altered or compromised files from a known good backup to ensure system integrity and prevent further exploitation.
114- Implement additional monitoring and logging for symbolic link creation and other related activities to detect similar threats in the future.
115- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
116
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119
120[[rule.threat.technique]]
121id = "T1548"
122name = "Abuse Elevation Control Mechanism"
123reference = "https://attack.mitre.org/techniques/T1548/"
124
125[rule.threat.tactic]
126id = "TA0004"
127name = "Privilege Escalation"
128reference = "https://attack.mitre.org/tactics/TA0004/"
129
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132
133[[rule.threat.technique]]
134id = "T1003"
135name = "OS Credential Dumping"
136reference = "https://attack.mitre.org/techniques/T1003/"
137
138[[rule.threat.technique.subtechnique]]
139id = "T1003.008"
140name = "/etc/passwd and /etc/shadow"
141reference = "https://attack.mitre.org/techniques/T1003/008/"
142
143[rule.threat.tactic]
144id = "TA0006"
145name = "Credential Access"
146reference = "https://attack.mitre.org/tactics/TA0006/"

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.

Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries may exploit these links to redirect privileged processes to sensitive files, potentially escalating privileges or accessing restricted data. The detection rule identifies suspicious link creation by monitoring the execution of the 'ln' command with specific arguments and targets, especially when initiated by non-root users, indicating potential misuse.

Possible investigation steps

  • Review the process details to confirm the execution of the 'ln' command with suspicious arguments such as "-s" or "-sf" and verify the target files or directories listed in the query, like "/etc/shadow" or "/bin/bash".
  • Check the user and group IDs associated with the process to ensure they are not root (ID "0"), as the rule specifically targets non-root users.
  • Investigate the parent process name to determine if it is one of the shell processes listed in the query, such as "bash" or "zsh", which might indicate a user-initiated action.
  • Examine the working directory and arguments to identify if the symbolic link creation is targeting sensitive locations like "/etc/cron.d/" or "/home//.ssh/*".
  • Analyze the user's recent activity and command history to understand the context and intent behind the symbolic link creation.
  • Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities involving the same user or system.

False positive analysis

  • Non-root users creating symbolic links for legitimate administrative tasks may trigger the rule. To manage this, identify and whitelist specific users or groups who regularly perform these tasks without malicious intent.
  • Automated scripts or applications that use symbolic links for configuration management or software deployment might be flagged. Review these processes and exclude them by specifying the script or application names in the detection rule.
  • Development environments where symbolic links are used to manage dependencies or version control can cause false positives. Exclude directories or processes associated with these environments to prevent unnecessary alerts.
  • Backup or synchronization tools that create symbolic links as part of their operation may be mistakenly identified. Identify these tools and add exceptions for their typical execution patterns.
  • System maintenance activities that involve symbolic link creation, such as linking to shared libraries or binaries, should be reviewed and excluded if they are part of routine operations.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
  • Terminate any suspicious processes related to the 'ln' command that are identified in the alert to stop any ongoing malicious activity.
  • Conduct a thorough review of the symbolic links created, especially those pointing to sensitive files or directories, and remove any unauthorized or suspicious links.
  • Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack, focusing on those with elevated privileges.
  • Restore any altered or compromised files from a known good backup to ensure system integrity and prevent further exploitation.
  • Implement additional monitoring and logging for symbolic link creation and other related activities to detect similar threats in the future.
  • Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures.

Related rules

to-top