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

nldcsc_elastic_rules/rules/linux/defense_evasion_log_files_deleted.toml

@@ -0,0 +1,151 @@
+[metadata]
+creation_date = "2020/11/03"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of sensitive Linux system logs. This may indicate an attempt to evade detection or destroy
+forensic evidence on a system.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "System Log File Deletion"
+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 System Log File Deletion
+
+System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert.
+- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity.
+- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available.
+- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised.
+- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise.
+- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file.
+
+### False positive analysis
+
+- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule.
+- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening.
+- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts.
+- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature.
+- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
+- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity.
+- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
+- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies.
+- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future."""
+references = [
+    "https://www.fireeye.com/blog/threat-research/2020/11/live-off-the-land-an-overview-of-unc1945.html",
+    "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security",
+]
+risk_score = 47
+rule_id = "aa895aea-b69c-4411-b110-8d7599634b30"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+### 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).
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+
+#### Custom Ingest Pipeline
+For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.type == "deletion" and
+  file.path :
+    (
+    "/var/run/utmp",
+    "/var/log/wtmp",
+    "/var/log/btmp",
+    "/var/log/lastlog",
+    "/var/log/faillog",
+    "/var/log/syslog",
+    "/var/log/messages",
+    "/var/log/secure",
+    "/var/log/auth.log",
+    "/var/log/boot.log",
+    "/var/log/kern.log",
+    "/var/log/dmesg"
+    ) and
+    not process.name in ("gzip", "executor", "dockerd")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1070"
+name = "Indicator Removal"
+reference = "https://attack.mitre.org/techniques/T1070/"
+[[rule.threat.technique.subtechnique]]
+id = "T1070.002"
+name = "Clear Linux or Mac System Logs"
+reference = "https://attack.mitre.org/techniques/T1070/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_mount_execution.toml

@@ -0,0 +1,127 @@
+[metadata]
+creation_date = "2023/04/11"
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the execution of mount process with hidepid parameter, which can make processes invisible to other users from
+the system. Adversaries using Linux kernel version 3.2+ (or RHEL/CentOS v6.5+ above) can hide the process from other
+users. When hidepid=2 option is executed to mount the /proc filesystem, only the root user can see all processes and the
+logged-in user can only see their own process. This provides a defense evasion mechanism for the adversaries to hide
+their process executions from all other commands such as ps, top, pgrep and more. With the Linux kernel hardening
+hidepid option all the user has to do is remount the /proc filesystem with the option, which can now be monitored and
+detected.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Hidden Process via Mount Hidepid"
+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 Hidden Process via Mount Hidepid
+
+The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
+- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
+- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
+- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
+- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.
+
+### False positive analysis
+
+- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
+- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
+- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
+- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
+- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
+- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
+- Terminate any identified malicious processes and remove any associated files or scripts from the system.
+- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response."""
+references = ["https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/"]
+risk_score = 47
+rule_id = "dc71c186-9fe4-4437-a4d0-85ebb32b8204"
+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 = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "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", "executed", "process_started") and
+  process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
+  not process.parent.command_line like "/opt/cloudlinux/*"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1564"
+name = "Hide Artifacts"
+reference = "https://attack.mitre.org/techniques/T1564/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_multi_base64_decoding_attempt.toml

@@ -0,0 +1,163 @@
+[metadata]
+creation_date = "2025/07/24"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/09/01"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded
+data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Multi-Base64 Decoding Attempt from Suspicious Location"
+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 Multi-Base64 Decoding Attempt from Suspicious Location
+
+Base64 encoding is a common method to encode binary data into ASCII text, often used for data transmission. Adversaries exploit this by encoding malicious payloads to evade detection. The detection rule identifies suspicious decoding activities, especially from unusual directories, by monitoring rapid sequences of decoding commands. It excludes benign processes to reduce false positives, focusing on potential threats in Linux environments.
+
+### Possible investigation steps
+
+- Review the process details, including the parent entity ID and executable path, to understand the context of the decoding activity and identify the parent process responsible for initiating the base64 commands.
+- Examine the working directory where the decoding occurred, focusing on suspicious locations such as "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", and "/root/*" to determine if the activity aligns with typical usage patterns or if it indicates potential malicious behavior.
+- Analyze the command-line arguments used in the decoding process, specifically looking for "-d*" or "--d*" flags, to assess whether the decoding was intended to obfuscate data or execute hidden payloads.
+- Investigate the sequence of events within the 3-second maxspan to identify any rapid or automated decoding attempts that could suggest scripted or malicious activity.
+- Check for any exclusions in the rule, such as known benign processes or directories, to ensure the alert is not a false positive and the activity is genuinely suspicious.
+- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and determine if this is part of a larger attack or isolated incident.
+
+### False positive analysis
+
+- Scheduled tasks or cron jobs may trigger base64 decoding in benign processes. Exclude known executables like "/etc/cron.daily/vivaldi" and "/etc/cron.daily/opera-browser" to reduce false positives.
+- System management tools or agents, such as those located in "/opt/microsoft/omsagent/plugin" or "/opt/rapid7/ir_agent/*", might use base64 decoding for legitimate purposes. Add these directories to the exclusion list to prevent unnecessary alerts.
+- Temporary directories like "/tmp/newroot/*" may be used by legitimate applications for transient data processing. Consider excluding these paths if they are frequently involved in non-malicious activities.
+- User scripts or applications in home directories may use base64 for encoding or decoding data. Monitor and whitelist specific user processes that are known to be safe to avoid false positives.
+- Regularly review and update the exclusion list based on observed benign activities to ensure the rule remains effective without generating excessive false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further execution of potentially malicious payloads. Disconnect the system from the network to contain the threat.
+
+- Review and terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding from unusual directories. Use process management tools to kill these processes.
+
+- Conduct a thorough examination of the directories flagged by the alert (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any malicious files or scripts. Ensure these directories are cleaned of unauthorized or suspicious content.
+
+- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
+
+- Escalate the incident to the security operations team for further investigation and analysis. Provide them with logs and details of the processes and directories involved for deeper threat assessment.
+
+- Implement additional monitoring and alerting for similar suspicious activities, focusing on rapid sequences of base64 decoding commands and unusual directory usage to enhance detection capabilities.
+
+- Review and update access controls and permissions for the directories involved to prevent unauthorized access and execution of potentially harmful scripts or binaries.
+"""
+risk_score = 21
+rule_id = "03d856c2-7f74-4540-a530-e20af5e39789"
+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: Defense Evasion",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide"
+]
+type = "eql"
+query = '''
+sequence by process.parent.entity_id with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
+   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
+   // Only including potentially suspicious locations
+   process.args like~ ("-d*", "--d*") and process.working_directory like (
+     "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", "/root/*"
+   ) and not (
+     process.parent.executable in (
+       "/usr/share/ec2-instance-connect/eic_curl_authorized_keys", "/etc/cron.daily/vivaldi",
+       "/etc/cron.daily/opera-browser"
+     ) or
+     process.working_directory like (
+       "/opt/microsoft/omsagent/plugin", "/opt/rapid7/ir_agent/*", "/tmp/newroot/*"
+      )
+   )]
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
+   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
+   process.args like~ ("-d*", "--d*")]
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+  [rule.threat.tactic]
+  name = "Defense Evasion"
+  id = "TA0005"
+  reference = "https://attack.mitre.org/tactics/TA0005/"
+
+    [[rule.threat.technique]]
+    name = "Obfuscated Files or Information"
+    id = "T1027"
+    reference = "https://attack.mitre.org/techniques/T1027/"
+
+    [[rule.threat.technique]]
+    name = "Deobfuscate/Decode Files or Information"
+    id = "T1140"
+    reference = "https://attack.mitre.org/techniques/T1140/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+  [rule.threat.tactic]
+  name = "Execution"
+  id = "TA0002"
+  reference = "https://attack.mitre.org/tactics/TA0002/"
+
+    [[rule.threat.technique]]
+    id = "T1059"
+    name = "Command and Scripting Interpreter"
+    reference = "https://attack.mitre.org/techniques/T1059/"
+
+      [[rule.threat.technique.subtechnique]]
+      name = "Unix Shell"
+      id = "T1059.004"
+      reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+    [[rule.threat.technique]]
+    name = "User Execution"
+    id = "T1204"
+    reference = "https://attack.mitre.org/techniques/T1204/"
+
+      [[rule.threat.technique.subtechnique]]
+      name = "Malicious File"
+      id = "T1204.002"
+      reference = "https://attack.mitre.org/techniques/T1204/002/"

nldcsc_elastic_rules/rules/linux/defense_evasion_potential_kubectl_impersonation.toml

@@ -0,0 +1,158 @@
+[metadata]
+creation_date = "2025/06/19"
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/07/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects potential impersonation attempts via the "kubectl" command in Linux environments. It identifies
+process events where "kubectl" is executed with arguments that suggest an attempt to impersonate another user or
+group, such as using "--kubeconfig", "--token", "--as", or "--as-group". This could indicate an adversary trying
+to gain unauthorized access or escalate privileges within a Kubernetes cluster. If this rule is triggered, in
+conjunction with rules related to secret access or kubeconfig file discovery, it may indicate a potential
+impersonation attempt.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Impersonation Attempt via Kubectl"
+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 Impersonation Attempt via Kubectl
+
+Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit kubectl by using specific arguments to impersonate users, gaining unauthorized access or escalating privileges. The detection rule identifies suspicious kubectl executions, focusing on arguments that suggest impersonation, such as those related to user identity and authentication, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process arguments to confirm the presence of impersonation-related flags such as "--kubeconfig", "--token", "--as", "--as-group", or "--as-uid" to understand the scope of the impersonation attempt.
+- Examine the parent process name and executable path to determine if the kubectl command was initiated from a suspicious location or script, such as "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", or "/home/*".
+- Check the user account associated with the kubectl execution to assess whether it aligns with expected usage patterns or if it indicates potential unauthorized access.
+- Investigate related alerts or logs for secret access or kubeconfig file discovery to identify if there is a broader pattern of suspicious activity that could indicate a coordinated impersonation attempt.
+- Analyze the network activity associated with the kubectl execution to identify any unusual connections or data transfers that may suggest unauthorized access or data exfiltration.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use kubectl with impersonation arguments for legitimate purposes such as testing permissions or managing resources on behalf of other users. To handle this, create exceptions for known administrative accounts or specific IP addresses.
+- Automation scripts: Automated scripts or CI/CD pipelines might use impersonation arguments to perform tasks across different environments. Review and whitelist these scripts by identifying their unique execution patterns or specific user accounts.
+- Development and testing environments: Developers might use impersonation features in non-production environments for testing purposes. Exclude these environments by filtering based on environment-specific identifiers or network segments.
+- Security tools: Some security tools or monitoring solutions may use impersonation arguments to audit or verify access controls. Identify these tools and exclude their processes by recognizing their signatures or execution paths.
+- Frequent legitimate use cases: If certain teams or departments regularly use impersonation for valid reasons, consider creating role-based exceptions to reduce noise while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or privilege escalation.
+- Revoke any potentially compromised credentials, such as tokens or kubeconfig files, and issue new ones with updated security policies.
+- Review and audit the Kubernetes RBAC (Role-Based Access Control) settings to ensure that only authorized users have the necessary permissions, and adjust roles and permissions as needed to minimize privilege escalation risks.
+- Conduct a thorough investigation of the affected systems to identify any unauthorized changes or deployments made by the adversary, and roll back any malicious or suspicious configurations.
+- Monitor for any further suspicious kubectl activity, especially those involving impersonation arguments, and set up alerts for any similar future attempts.
+- Escalate the incident to the security operations team for a comprehensive review and to determine if additional security measures or incident response actions are required.
+- Implement additional logging and monitoring for kubectl commands and Kubernetes API interactions to enhance detection capabilities for similar threats in the future.
+"""
+risk_score = 21
+rule_id = "3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d"
+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",
+    "Domain: Container",
+    "Domain: Kubernetes",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Tactic: Discovery",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "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", "executed", "process_started") and
+process.name == "kubectl" and (
+  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
+  (
+    process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or
+    process.parent.name like (".*", "*.sh")
+  )
+) and process.args like~ ("--kubeconfig*", "--token*", "--as*", "--as-group*", "--as-uid*")
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1550.001"
+name = "Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1550/001/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"