Suspicious Kworker UID Elevation

Monitors for the elevation of regular user permissions to root permissions through the kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process, and hijack the execution flow by hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/10/26"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Monitors for the elevation of regular user permissions to root permissions through the kworker process. kworker, or
 11kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has
 12been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities,
 13and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process, and
 14hijack the execution flow by hooking certain functions/syscalls through a rootkit in order to provide easy access to
 15root via a special modified command.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.*", "endgame-*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Suspicious Kworker UID Elevation"
 22risk_score = 47
 23rule_id = "7dfaaa17-425c-4fe7-bd36-83705fde7c2b"
 24setup = """## Setup
 25
 26This rule requires data coming in from Elastic Defend.
 27
 28### Elastic Defend Integration Setup
 29Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
 30the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 31
 32#### Prerequisite Requirements:
 33- Fleet is required for Elastic Defend.
 34- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 35
 36#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 37- Go to the Kibana home page and click Add integrations.
 38- In the query bar, search for Elastic Defend and select the integration to see more details about it.
 39- Click Add Elastic Defend.
 40- Configure the integration name and optionally add a description.
 41- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads.
 42- 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).
 43- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 44- 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.
 45For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 46- Click Save and Continue.
 47- 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.
 48For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 49"""
 50severity = "medium"
 51tags = [
 52    "Domain: Endpoint",
 53    "OS: Linux",
 54    "Use Case: Threat Detection",
 55    "Tactic: Privilege Escalation",
 56    "Tactic: Defense Evasion",
 57    "Data Source: Elastic Defend",
 58    "Data Source: Elastic Endgame",
 59    "Resources: Investigation Guide",
 60]
 61timestamp_override = "event.ingested"
 62type = "eql"
 63
 64query = '''
 65process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and
 66user.id == "0"
 67'''
 68note = """## Triage and analysis
 69
 70> **Disclaimer**:
 71> 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.
 72
 73### Investigating Suspicious Kworker UID Elevation
 74
 75Kworker processes are integral to Linux, handling tasks like interrupts and background activities within the kernel. Adversaries may exploit these processes by disguising malicious activities as legitimate kernel operations, often using rootkits to hijack execution flow and gain root access. The detection rule identifies anomalies by monitoring for kworker processes that unexpectedly change session IDs and elevate privileges to root, signaling potential misuse.
 76
 77### Possible investigation steps
 78
 79- Review the process details for the kworker process with a session ID change and user ID of 0 to confirm the legitimacy of the process and its parent process.
 80- Check the system logs around the time of the session ID change event for any unusual activities or errors that might indicate tampering or exploitation attempts.
 81- Investigate any recent changes to the system, such as new software installations or updates, that could have introduced vulnerabilities or unauthorized modifications.
 82- Analyze the system for signs of rootkit presence, such as hidden files or processes, by using rootkit detection tools or manual inspection techniques.
 83- Correlate the event with other security alerts or anomalies in the network to determine if this is part of a broader attack campaign or isolated incident.
 84
 85### False positive analysis
 86
 87- Regular system updates or maintenance activities may trigger session ID changes in kworker processes. Users can monitor scheduled maintenance windows and exclude these time frames from triggering alerts.
 88- Custom kernel modules or legitimate software that interacts with kernel processes might cause kworker to change session IDs. Identify and whitelist these known modules or software to prevent false positives.
 89- Automated scripts or tools that require elevated privileges for legitimate tasks could inadvertently cause kworker processes to appear suspicious. Review and document these scripts, then create exceptions for their expected behavior.
 90- Certain system configurations or optimizations might lead to benign kworker session ID changes. Conduct a baseline analysis of normal system behavior and adjust the detection rule to accommodate these patterns without compromising security.
 91
 92### Response and remediation
 93
 94- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
 95- Terminate the suspicious kworker process identified in the alert to stop any ongoing malicious activity.
 96- Conduct a thorough review of system logs and process trees to identify any additional compromised processes or indicators of rootkit installation.
 97- Restore the system from a known good backup if rootkit presence is confirmed, as rootkits can deeply embed themselves into the system.
 98- Change all credentials and keys that may have been exposed or used on the compromised system to prevent unauthorized access using stolen credentials.
 99- Implement enhanced monitoring and logging for kworker processes and session ID changes to detect similar activities in the future.
100- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems."""
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1574"
107name = "Hijack Execution Flow"
108reference = "https://attack.mitre.org/techniques/T1574/"
109[[rule.threat.technique.subtechnique]]
110id = "T1574.013"
111name = "KernelCallbackTable"
112reference = "https://attack.mitre.org/techniques/T1574/013/"
113
114
115
116[rule.threat.tactic]
117id = "TA0004"
118name = "Privilege Escalation"
119reference = "https://attack.mitre.org/tactics/TA0004/"
120[[rule.threat]]
121framework = "MITRE ATT&CK"
122[[rule.threat.technique]]
123id = "T1014"
124name = "Rootkit"
125reference = "https://attack.mitre.org/techniques/T1014/"
126
127
128[rule.threat.tactic]
129id = "TA0005"
130name = "Defense Evasion"
131reference = "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 Suspicious Kworker UID Elevation

Kworker processes are integral to Linux, handling tasks like interrupts and background activities within the kernel. Adversaries may exploit these processes by disguising malicious activities as legitimate kernel operations, often using rootkits to hijack execution flow and gain root access. The detection rule identifies anomalies by monitoring for kworker processes that unexpectedly change session IDs and elevate privileges to root, signaling potential misuse.

Possible investigation steps

  • Review the process details for the kworker process with a session ID change and user ID of 0 to confirm the legitimacy of the process and its parent process.
  • Check the system logs around the time of the session ID change event for any unusual activities or errors that might indicate tampering or exploitation attempts.
  • Investigate any recent changes to the system, such as new software installations or updates, that could have introduced vulnerabilities or unauthorized modifications.
  • Analyze the system for signs of rootkit presence, such as hidden files or processes, by using rootkit detection tools or manual inspection techniques.
  • Correlate the event with other security alerts or anomalies in the network to determine if this is part of a broader attack campaign or isolated incident.

False positive analysis

  • Regular system updates or maintenance activities may trigger session ID changes in kworker processes. Users can monitor scheduled maintenance windows and exclude these time frames from triggering alerts.
  • Custom kernel modules or legitimate software that interacts with kernel processes might cause kworker to change session IDs. Identify and whitelist these known modules or software to prevent false positives.
  • Automated scripts or tools that require elevated privileges for legitimate tasks could inadvertently cause kworker processes to appear suspicious. Review and document these scripts, then create exceptions for their expected behavior.
  • Certain system configurations or optimizations might lead to benign kworker session ID changes. Conduct a baseline analysis of normal system behavior and adjust the detection rule to accommodate these patterns without compromising security.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
  • Terminate the suspicious kworker process identified in the alert to stop any ongoing malicious activity.
  • Conduct a thorough review of system logs and process trees to identify any additional compromised processes or indicators of rootkit installation.
  • Restore the system from a known good backup if rootkit presence is confirmed, as rootkits can deeply embed themselves into the system.
  • Change all credentials and keys that may have been exposed or used on the compromised system to prevent unauthorized access using stolen credentials.
  • Implement enhanced monitoring and logging for kworker processes and session ID changes to detect similar activities in the future.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems.

Related rules

to-top