Suspicious which Enumeration

 1[metadata]
 2creation_date = "2023/08/30"
 3integration = ["endpoint", "sentinel_one_cloud_funnel"]
 4maturity = "production"
 5updated_date = "2025/03/20"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule monitors for the usage of the which command with an unusual amount of process arguments. Attackers may
11leverage the which command to enumerate the system for useful installed utilities that may be used after compromising a
12system to escalate privileges or move latteraly across the network.
13"""
14from = "now-9m"
15index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Suspicious which Enumeration"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating Suspicious which Enumeration
25
26The `which` command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule flags unusual usage patterns, such as excessive arguments, which may indicate malicious enumeration. It filters out benign scenarios, focusing on potential threats by examining process attributes and parent-child relationships.
27
28### Possible investigation steps
29
30- Review the process details to confirm the command line arguments used with the which command, focusing on whether the args_count is unusually high and if the arguments are related to known enumeration or exploitation tools.
31- Examine the parent process of the which command to determine if it is a legitimate process or if it is associated with suspicious activity, especially if it is not one of the excluded parent names or paths.
32- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.
33- Check for any other recent alerts or logs related to the same host or user that might indicate a broader attack pattern or ongoing compromise.
34- Assess the network activity from the host to identify any connections to known malicious IP addresses or unusual outbound traffic that could suggest lateral movement or data exfiltration.
35
36### False positive analysis
37
38- Processes initiated by the 'jem' parent process may trigger false positives. To handle this, add 'jem' to the list of exceptions in the rule configuration.
39- Executions within containerized environments, such as those under '/vz/root/' or '/var/lib/docker/', are often benign. Exclude these paths from the rule to reduce noise.
40- The '--tty-only' argument is typically used in legitimate scenarios. Consider adding this argument to the exception list to prevent unnecessary alerts.
41- If the rule is noisy due to common utilities like 'nmap', 'nc', 'gcc', or 'socat' being used with shell interpreters like 'bash' or 'zsh', refine the rule by excluding these combinations.
42- Regularly review and update the list of exceptions based on the evolving environment and usage patterns to maintain an effective balance between detection and false positive reduction.
43
44### Response and remediation
45
46- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
47- Terminate any suspicious processes associated with the `which` command that have an unusually high number of arguments, as identified by the detection rule.
48- Conduct a thorough review of the system's installed software and utilities to identify any unauthorized or suspicious installations that could be leveraged for privilege escalation.
49- Analyze the process tree and parent-child relationships of the flagged `which` command execution to identify potential malicious scripts or binaries that initiated the command.
50- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
51- Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse.
52- Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities."""
53risk_score = 21
54rule_id = "5b18eef4-842c-4b47-970f-f08d24004bde"
55severity = "low"
56tags = [
57    "Domain: Endpoint",
58    "OS: Linux",
59    "Use Case: Threat Detection",
60    "Tactic: Discovery",
61    "Data Source: Elastic Defend",
62    "Data Source: Elastic Endgame",
63    "Data Source: SentinelOne",
64    "Resources: Investigation Guide",
65]
66timestamp_override = "event.ingested"
67type = "eql"
68
69query = '''
70process where host.os.type == "linux" and event.type == "start" and
71  event.action in ("exec", "exec_event", "start") and
72  process.name == "which" and process.args_count >= 10 and not (
73    process.parent.name == "jem" or
74    process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
75    process.args == "--tty-only"
76  )
77
78/* potential tuning if rule would turn out to be noisy
79and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and
80process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
81*/
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1082"
89name = "System Information Discovery"
90reference = "https://attack.mitre.org/techniques/T1082/"
91
92
93[rule.threat.tactic]
94id = "TA0007"
95name = "Discovery"
96reference = "https://attack.mitre.org/tactics/TA0007/"