Polkit Version Discovery
This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/01/16"
3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
4maturity = "production"
5min_stack_version = "8.13.0"
6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
7updated_date = "2025/01/22"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an
13indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service.
14"""
15from = "now-9m"
16index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Polkit Version Discovery"
20risk_score = 21
21rule_id = "ca3bcacc-9285-4452-a742-5dae77538f61"
22setup = """## Setup
23This rule requires data coming in from Elastic Defend.
24### Elastic Defend Integration Setup
25Elastic 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.
26#### Prerequisite Requirements:
27- Fleet is required for Elastic Defend.
28- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
29#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
30- Go to the Kibana home page and click "Add integrations".
31- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
32- Click "Add Elastic Defend".
33- Configure the integration name and optionally add a description.
34- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
35- 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).
36- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
37- 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.
38For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
39- Click "Save and Continue".
40- 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.
41For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
42"""
43severity = "low"
44tags = [
45 "Domain: Endpoint",
46 "OS: Linux",
47 "Use Case: Threat Detection",
48 "Tactic: Discovery",
49 "Data Source: Elastic Defend",
50 "Data Source: Elastic Endgame",
51 "Data Source: Crowdstrike",
52 "Data Source: SentinelOne",
53 "Resources: Investigation Guide",
54]
55timestamp_override = "event.ingested"
56type = "eql"
57query = '''
58process where host.os.type == "linux" and event.type == "start" and
59event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
60 (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or
61 (process.name == "rpm" and process.args == "polkit") or
62 (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or
63 (process.name == "pkaction" and process.args == "--version")
64)
65'''
66note = """## Triage and analysis
67
68> **Disclaimer**:
69> 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.
70
71### Investigating Polkit Version Discovery
72
73Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers.
74
75### Possible investigation steps
76
77- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction".
78- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
79- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target.
80- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities.
81- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous.
82
83### False positive analysis
84
85- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions.
86- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule.
87- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments.
88- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments.
89
90### Response and remediation
91
92- Isolate the affected system from the network to prevent potential lateral movement by the attacker.
93- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands.
94- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities.
95- Apply any available security patches or updates to the Polkit service to address known vulnerabilities.
96- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities.
97- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
98- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats."""
99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1082"
105name = "System Information Discovery"
106reference = "https://attack.mitre.org/techniques/T1082/"
107
108[rule.threat.tactic]
109id = "TA0007"
110name = "Discovery"
111reference = "https://attack.mitre.org/tactics/TA0007/"
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 Polkit Version Discovery
Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers.
Possible investigation steps
- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction".
- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target.
- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities.
- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous.
False positive analysis
- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions.
- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule.
- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments.
- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments.
Response and remediation
- Isolate the affected system from the network to prevent potential lateral movement by the attacker.
- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands.
- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities.
- Apply any available security patches or updates to the Polkit service to address known vulnerabilities.
- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats.
Related rules
- Hping Process Activity
- Nping Process Activity
- Private Key Searching Activity
- Sudo Command Enumeration Detected
- Suspicious Dynamic Linker Discovery via od