nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/linux/discovery_manual_mount_discovery_via_exports_or_fstab.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2025/04/25"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used
+by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this
+file to gather information about shared directories and potential targets for further exploitation.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Manual Mount Discovery via /etc/exports or /etc/fstab"
+note = """ ## 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 Manual Mount Discovery via /etc/exports or /etc/fstab
+
+In Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields.
+- Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks.
+- Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events.
+- Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity.
+- Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities.
+- Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access.
+
+### False positive analysis
+
+- Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows.
+- Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives.
+- Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts.
+- Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives.
+- Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Conduct a thorough review of the `/etc/exports` and `/etc/fstab` files on the affected system to identify any unauthorized changes or suspicious entries.
+- Revoke any unauthorized access to shared directories identified in the `/etc/exports` file and ensure that only trusted hosts have access.
+- Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access.
+- Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future.
+"""
+risk_score = 21
+rule_id = "bd18f4a3-c4c6-43b9-a1e4-b05e09998110"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic 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.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- 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).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- 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.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- 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.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like ("/etc/exports", "/etc/fstab")
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"

nldcsc_elastic_rules/rules/linux/discovery_pam_version_discovery.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2024/12/16"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an
+attacker attempting to backdoor the authentication process through malicious PAM modules.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Pluggable Authentication Module (PAM) Version Discovery"
+note = """## 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 Pluggable Authentication Module (PAM) Version Discovery
+
+Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam".
+- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior.
+- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts.
+- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts.
+- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context.
+- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts.
+- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods.
+- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM.
+- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications.
+- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process.
+- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future."""
+references = [
+    "https://www.group-ib.com/blog/pluggable-authentication-module/",
+    "https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/",
+]
+risk_score = 21
+rule_id = "135abb91-dcf4-48aa-b81a-5ad036b67c68"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic 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.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- 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).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- 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.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- 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.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Tactic: Persistence",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name != null and
+  (
+    (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or
+    (process.name == "rpm" and process.args == "pam")
+  ) and
+not process.parent.name in ("dcservice", "inspectorssmplugin")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1543"
+name = "Create or Modify System Process"
+reference = "https://attack.mitre.org/techniques/T1543/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/discovery_ping_sweep_detected.toml

@@ -0,0 +1,122 @@
+[metadata]
+creation_date = "2023/09/04"
+integration = ["endpoint", "auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This threshold rule monitors for the rapid execution of unix utilities that are capable of conducting network scans.
+Adversaries may leverage built-in tools such as ping, netcat or socat to execute ping sweeps across the network while
+attempting to evade detection or due to the lack of network mapping tools available on the compromised host.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Potential Network Scan Executed From Host"
+risk_score = 47
+rule_id = "03c23d45-d3cb-4ad4-ab5d-b361ffe8724a"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic 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.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- 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).
+- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- 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.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- 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.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and
+event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat)
+'''
+note = """## 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 Network Scan Executed From Host
+
+In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools.
+
+### Possible investigation steps
+
+- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert.
+- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior.
+- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan.
+- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior.
+- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan.
+- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity.
+
+### False positive analysis
+
+- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics.
+- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths.
+- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts.
+- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts.
+- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans.
+- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity.
+- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access.
+- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries.
+- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1046"
+name = "Network Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1046/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[rule.threshold]
+field = ["host.id", "process.parent.entity_id", "process.executable"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "process.args"
+value = 100
+
+

nldcsc_elastic_rules/rules/linux/discovery_polkit_version_discovery.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2025/01/16"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Polkit Version Discovery"
+note = """## 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."""
+risk_score = 21
+rule_id = "ca3bcacc-9285-4452-a742-5dae77538f61"
+setup = """## Setup
+This rule requires data coming in from Elastic Defend.
+### Elastic Defend Integration Setup
+Elastic 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.
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- 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).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- 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.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- 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.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
+  (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or
+  (process.name == "rpm" and process.args == "polkit") or
+  (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or
+  (process.name == "pkaction" and process.args == "--version")
+)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+