Potential Process Name Stomping with Prctl
This rule leverages Auditd data to detect the use of the prctl
syscall to potentially hide a process
by changing its name. The prctl
syscall is used to control various process attributes. Attackers can use
this syscall to change the name of a process to a hidden directory or file, making it harder to detect. The query
looks for the prctl
syscall with the PR_SET_NAME
argument set to f
(PR_SET_NAME is used to set the name of a process).
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/01/09"
3integration = ["auditd_manager"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule leverages Auditd data to detect the use of the `prctl` syscall to potentially hide a process
11by changing its name. The `prctl` syscall is used to control various process attributes. Attackers can use
12this syscall to change the name of a process to a hidden directory or file, making it harder to detect. The query
13looks for the `prctl` syscall with the `PR_SET_NAME` argument set to `f` (PR_SET_NAME is used to set the name of a process).
14"""
15from = "now-9m"
16index = ["logs-auditd_manager.auditd-*", "auditbeat-*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Potential Process Name Stomping with Prctl"
20references = [
21 "https://haxrob.net/process-name-stomping/",
22 "https://haxrob.net/hiding-in-plain-sight-part-2/",
23 "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
24]
25risk_score = 47
26rule_id = "fef62ecf-0260-4b71-848b-a8624b304828"
27setup = """## Setup
28
29This rule requires data coming in from Auditd Manager.
30
31### Auditd Manager Integration Setup
32The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
33Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
34
35#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
36- Go to the Kibana home page and click “Add integrations”.
37- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
38- Click “Add Auditd Manager”.
39- Configure the integration name and optionally add a description.
40- Review optional and advanced settings accordingly.
41- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
42- Click “Save and Continue”.
43- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
44
45#### Rule Specific Setup Note
46Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
47However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
48- For this detection rule the following additional audit rules are required to be added to the integration:
49 -- "-a exit,always -F arch=b64 -S prctl -k prctl_detection"
50"""
51severity = "medium"
52tags = [
53 "Data Source: Auditd Manager",
54 "Domain: Endpoint",
55 "OS: Linux",
56 "Use Case: Threat Detection",
57 "Tactic: Defense Evasion",
58 "Resources: Investigation Guide",
59]
60timestamp_override = "event.ingested"
61type = "eql"
62query = '''
63process where host.os.type == "linux" and auditd.data.syscall == "prctl" and auditd.data.a0 == "f" and
64process.executable like (
65 "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/var/run/*", "/etc/update-motd.d/*",
66 "/tmp/*", "/var/log/*", "/var/tmp/*", "/home/*", "/run/shm/*", "/run/*", "./*"
67)
68'''
69note = """## Triage and analysis
70
71> **Disclaimer**:
72> 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.
73
74### Investigating Potential Process Name Stomping with Prctl
75
76The `prctl` syscall in Linux allows processes to modify their attributes, including renaming themselves. This capability can be exploited by attackers to disguise malicious processes, making them harder to identify. The detection rule monitors for `prctl` invocations with specific arguments indicative of name changes, especially when linked to suspicious directories, thus flagging potential evasion attempts.
77
78### Possible investigation steps
79
80- Review the process details associated with the alert, focusing on the executable path to determine if it matches any suspicious directories listed in the query, such as "/tmp/*" or "/var/tmp/*".
81- Examine the process tree to identify the parent process and any child processes spawned by the suspicious process, which may provide context on how the process was initiated and its potential impact.
82- Check the command line arguments and environment variables of the process to gather additional context on its intended function and any anomalies.
83- Investigate the user account under which the process is running to determine if it aligns with expected behavior or if it indicates potential compromise.
84- Correlate the alert with other security events or logs, such as file modifications or network connections, to identify any related malicious activity or patterns.
85- Assess the historical activity of the process executable and its associated files to determine if this behavior is new or part of a recurring pattern.
86
87### False positive analysis
88
89- System maintenance scripts may invoke prctl to rename processes for legitimate reasons. Review scheduled tasks and maintenance scripts in directories like /etc/cron.* and /etc/init.d to identify benign uses.
90- Development environments often use prctl for testing purposes. Exclude known development directories such as /home/developer or /tmp/dev from the rule to reduce noise.
91- Some monitoring or logging tools might use prctl to rename their processes for clarity. Identify these tools and add their executable paths to an exception list.
92- Custom scripts or applications that manage process names for operational reasons should be documented. Exclude these scripts by specifying their paths in the rule configuration.
93- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new threats.
94
95### Response and remediation
96
97- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
98- Terminate any suspicious processes identified by the detection rule, especially those with altered names in critical directories.
99- Conduct a thorough review of the affected system's process tree and file system to identify any additional signs of compromise or persistence mechanisms.
100- Restore any altered or suspicious files from a known good backup to ensure system integrity.
101- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
102- Monitor the network for any signs of similar activity or attempts to use the `prctl` syscall with the `PR_SET_NAME` argument in other systems.
103- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107
108[[rule.threat.technique]]
109id = "T1036"
110name = "Masquerading"
111reference = "https://attack.mitre.org/techniques/T1036/"
112
113[[rule.threat.technique.subtechnique]]
114id = "T1036.005"
115name = "Match Legitimate Name or Location"
116reference = "https://attack.mitre.org/techniques/T1036/005/"
117
118[rule.threat.tactic]
119id = "TA0005"
120name = "Defense Evasion"
121reference = "https://attack.mitre.org/tactics/TA0005/"
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 Potential Process Name Stomping with Prctl
The prctl
syscall in Linux allows processes to modify their attributes, including renaming themselves. This capability can be exploited by attackers to disguise malicious processes, making them harder to identify. The detection rule monitors for prctl
invocations with specific arguments indicative of name changes, especially when linked to suspicious directories, thus flagging potential evasion attempts.
Possible investigation steps
- Review the process details associated with the alert, focusing on the executable path to determine if it matches any suspicious directories listed in the query, such as "/tmp/" or "/var/tmp/".
- Examine the process tree to identify the parent process and any child processes spawned by the suspicious process, which may provide context on how the process was initiated and its potential impact.
- Check the command line arguments and environment variables of the process to gather additional context on its intended function and any anomalies.
- Investigate the user account under which the process is running to determine if it aligns with expected behavior or if it indicates potential compromise.
- Correlate the alert with other security events or logs, such as file modifications or network connections, to identify any related malicious activity or patterns.
- Assess the historical activity of the process executable and its associated files to determine if this behavior is new or part of a recurring pattern.
False positive analysis
- System maintenance scripts may invoke prctl to rename processes for legitimate reasons. Review scheduled tasks and maintenance scripts in directories like /etc/cron.* and /etc/init.d to identify benign uses.
- Development environments often use prctl for testing purposes. Exclude known development directories such as /home/developer or /tmp/dev from the rule to reduce noise.
- Some monitoring or logging tools might use prctl to rename their processes for clarity. Identify these tools and add their executable paths to an exception list.
- Custom scripts or applications that manage process names for operational reasons should be documented. Exclude these scripts by specifying their paths in the rule configuration.
- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new threats.
Response and remediation
- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
- Terminate any suspicious processes identified by the detection rule, especially those with altered names in critical directories.
- Conduct a thorough review of the affected system's process tree and file system to identify any additional signs of compromise or persistence mechanisms.
- Restore any altered or suspicious files from a known good backup to ensure system integrity.
- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
- Monitor the network for any signs of similar activity or attempts to use the
prctl
syscall with thePR_SET_NAME
argument in other systems. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.
References
Related rules
- Base16 or Base32 Encoding/Decoding Activity
- ESXI Timestomping using Touch Command
- Hidden Files and Directories via Hidden Flag
- Kernel Driver Load
- Kernel Driver Load by non-root User