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

nldcsc_elastic_rules/rules/linux/defense_evasion_potential_kubectl_masquerading.toml

@@ -0,0 +1,155 @@
+[metadata]
+creation_date = "2025/06/19"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects potential kubectl masquerading activity by monitoring for process events where the process name
+is not "kubectl" but the command line arguments include kubectl-related commands. This could indicate an adversary
+attempting to masquerade as legitimate kubectl activity to evade detection. This rule covers evasion gaps
+introduced by renaming the kubectl binary, or placing it in an unusual directory.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Kubectl Masquerading via Unexpected Process"
+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 Kubectl Masquerading via Unexpected Process
+
+Kubectl is a command-line tool for interacting with Kubernetes clusters, crucial for managing containerized applications. Adversaries may exploit this by renaming the kubectl binary or placing it in unusual directories to mimic legitimate activity and evade detection. The detection rule identifies such masquerading by monitoring for non-standard process names executing kubectl-related commands, thus highlighting potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is located in a non-standard directory such as /tmp, /var/tmp, /dev/shm, or other specified paths in the query.
+- Examine the process name to check if it deviates from the expected "kubectl" name, which could indicate an attempt to masquerade the process.
+- Analyze the command line arguments used in the process to identify any kubectl-related commands, such as "get", "describe", "exec", "port-forward", or authentication commands, which may suggest unauthorized access or activity.
+- Investigate the user account associated with the process to determine if it has legitimate access to execute kubectl commands or if it might be compromised.
+- Check for any recent changes or anomalies in the Kubernetes cluster that could correlate with the suspicious process activity, such as unauthorized deployments or configuration changes.
+- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities.
+- If possible, capture and analyze network traffic associated with the process to detect any unusual or unauthorized communication with the Kubernetes API server or other cluster components.
+
+### False positive analysis
+
+- Processes running in development or testing environments may trigger alerts if kubectl is executed from non-standard directories. To manage this, create exceptions for known development paths where kubectl is legitimately used.
+- Automated scripts or CI/CD pipelines that use kubectl from custom directories might be flagged. Identify these scripts and exclude their specific paths or process names from the rule.
+- Some legitimate applications might wrap kubectl commands for functionality, leading to unexpected process names. Review these applications and add their process names to the exclusion list if they are verified as non-threatening.
+- Users with custom kubectl installations in home directories could cause false positives. Verify these installations and exclude the specific user paths if they are deemed safe.
+- Temporary or experimental setups where kubectl is renamed for testing purposes might be mistakenly flagged. Document these setups and apply temporary exclusions during the testing phase.
+
+### Response and remediation
+
+- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes identified by the detection rule that are masquerading as kubectl to halt potential malicious activity.
+- Conduct a thorough review of the affected system's logs and command history to identify any unauthorized kubectl commands executed and assess the scope of the compromise.
+- Revoke any potentially compromised credentials or access tokens associated with the Kubernetes cluster to prevent further unauthorized access.
+- Restore any altered or deleted Kubernetes resources from backups, ensuring the integrity and availability of the cluster's services.
+- Implement stricter access controls and monitoring on the Kubernetes cluster, such as enforcing the principle of least privilege and enabling audit logging for kubectl commands.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+"""
+references = ["https://kubernetes.io/docs/reference/kubectl/"]
+risk_score = 21
+rule_id = "2388c687-cb2c-4b7b-be8f-6864a2385048"
+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",
+    "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", "executed", "process_started") and
+(
+  process.executable like~ ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/var/www/*", "./kubectl", "/home/*/kubectl") or
+  process.name like ".*"
+) and
+process.command_line like~ (
+
+  // get and describe commands
+  "*get po*", "*get deploy*", "*get node*", "*get svc*", "*get service*", "*get secret*", "*get clusterrole*", "*get ingress*",
+  "*get configmap*", "*describe po*", "*describe deploy*", "*describe node*", "*describe svc*", "*describe service*",
+  "*describe secret*", "*describe configmap*", "*describe clusterrole*", "*describe ingress*",
+  
+  // exec commands
+  "*exec -it*", "*exec --stdin*", "*exec --tty*",
+  
+  // networking commands
+  "*port-forward* ", "*proxy --port*", "*run --image=*", "*expose*",
+
+  // authentication/impersonation commands
+  "*auth can-i*", "*--kubeconfig*", "*--as *", "*--as=*", "*--as-group*", "*--as-uid*"
+) and not (
+  process.executable like "/tmp/newroot/*" or
+  process.name == ".flatpak-wrapped"
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1036.003"
+name = "Rename Legitimate Utilities"
+reference = "https://attack.mitre.org/techniques/T1036/003/"
+
+[[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_potential_proot_exploits.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2023/03/07"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the execution of the PRoot utility, an open-source tool for user-space implementation of chroot, mount
+--bind, and binfmt_misc. Adversaries can leverage an open-source tool PRoot to expand the scope of their operations to
+multiple Linux distributions and simplify their necessary efforts. In a normal threat scenario, the scope of an attack
+is limited by the varying configurations of each Linux distribution. With PRoot, it provides an attacker with a
+consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine. PRoot also
+provides emulation capabilities that allow for malware built on other architectures, such as ARM, to be run.The
+post-exploitation technique called bring your own filesystem (BYOF), can be used by the threat actors to execute
+malicious payload or elevate privileges or perform network scans or orchestrate another attack on the environment.
+Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Defense Evasion via PRoot"
+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 Defense Evasion via PRoot
+
+PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent.
+- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed.
+- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent.
+- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe.
+
+### False positive analysis
+
+- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes.
+- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts.
+- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope.
+- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources.
+- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes.
+- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot.
+- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
+references = ["https://proot-me.github.io/"]
+risk_score = 47
+rule_id = "5c9ec990-37fa-4d5c-abfc-8d432f3dedd0"
+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 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 == "proot"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1211"
+name = "Exploitation for Defense Evasion"
+reference = "https://attack.mitre.org/techniques/T1211/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_prctl_process_name_tampering.toml

@@ -0,0 +1,121 @@
+[metadata]
+creation_date = "2025/01/09"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages Auditd data to detect the use of the `prctl` syscall to potentially hide a process
+by changing its name. The `prctl` syscall is used to control various process attributes. Attackers can use
+this syscall to change the name of a process to a hidden directory or file, making it harder to detect. The query
+looks for the `prctl` syscall with the `PR_SET_NAME` argument set to `f` (PR_SET_NAME is used to set the name of a process).
+"""
+from = "now-9m"
+index = ["logs-auditd_manager.auditd-*", "auditbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Process Name Stomping with Prctl"
+references = [
+    "https://haxrob.net/process-name-stomping/",
+    "https://haxrob.net/hiding-in-plain-sight-part-2/",
+    "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
+]
+risk_score = 47
+rule_id = "fef62ecf-0260-4b71-848b-a8624b304828"
+setup = """## Setup
+
+This rule requires data coming in from Auditd Manager.
+
+### Auditd Manager Integration Setup
+The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
+Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
+- Click “Add Auditd Manager”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
+
+#### Rule Specific Setup Note
+Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
+However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+- For this detection rule the following additional audit rules are required to be added to the integration:
+  -- "-a exit,always -F arch=b64 -S prctl -k prctl_detection"
+"""
+severity = "medium"
+tags = [
+    "Data Source: Auditd Manager",
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and auditd.data.syscall == "prctl" and auditd.data.a0 == "f" and
+process.executable like (
+  "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/var/run/*", "/etc/update-motd.d/*",
+  "/tmp/*", "/var/log/*", "/var/tmp/*", "/home/*", "/run/shm/*", "/run/*", "./*"
+)
+'''
+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 Process Name Stomping with Prctl
+
+The `prctl` syscall in Linux allows processes to modify their attributes, including renaming themselves. This capability can be exploited by attackers to disguise malicious processes, making them harder to identify. The detection rule monitors for `prctl` invocations with specific arguments indicative of name changes, especially when linked to suspicious directories, thus flagging potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the executable path to determine if it matches any suspicious directories listed in the query, such as "/tmp/*" or "/var/tmp/*".
+- Examine the process tree to identify the parent process and any child processes spawned by the suspicious process, which may provide context on how the process was initiated and its potential impact.
+- Check the command line arguments and environment variables of the process to gather additional context on its intended function and any anomalies.
+- Investigate the user account under which the process is running to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Correlate the alert with other security events or logs, such as file modifications or network connections, to identify any related malicious activity or patterns.
+- Assess the historical activity of the process executable and its associated files to determine if this behavior is new or part of a recurring pattern.
+
+### False positive analysis
+
+- System maintenance scripts may invoke prctl to rename processes for legitimate reasons. Review scheduled tasks and maintenance scripts in directories like /etc/cron.* and /etc/init.d to identify benign uses.
+- Development environments often use prctl for testing purposes. Exclude known development directories such as /home/developer or /tmp/dev from the rule to reduce noise.
+- Some monitoring or logging tools might use prctl to rename their processes for clarity. Identify these tools and add their executable paths to an exception list.
+- Custom scripts or applications that manage process names for operational reasons should be documented. Exclude these scripts by specifying their paths in the rule configuration.
+- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes identified by the detection rule, especially those with altered names in critical directories.
+- Conduct a thorough review of the affected system's process tree and file system to identify any additional signs of compromise or persistence mechanisms.
+- Restore any altered or suspicious files from a known good backup to ensure system integrity.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
+- Monitor the network for any signs of similar activity or attempts to use the `prctl` syscall with the `PR_SET_NAME` argument in other systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1036.005"
+name = "Match Legitimate Resource Name or Location"
+reference = "https://attack.mitre.org/techniques/T1036/005/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"

nldcsc_elastic_rules/rules/linux/defense_evasion_rename_esxi_files.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2023/04/11"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies instances where VMware-related files, such as those with extensions like ".vmdk", ".vmx", ".vmxf", ".vmsd",
+".vmsn", ".vswp", ".vmss", ".nvram", and ".vmem", are renamed on a Linux system. The rule monitors for the "rename"
+event action associated with these file types, which could indicate malicious activity.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious Renaming of ESXI Files"
+references = [
+    "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
+]
+risk_score = 47
+rule_id = "97db8b42-69d8-4bf3-9fd4-c69a1d895d68"
+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 Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.action == "rename" and
+file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
+and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
+'''
+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 Suspicious Renaming of ESXI Files
+
+VMware ESXi files are critical for virtual machine operations, storing configurations and states. Adversaries may rename these files to evade detection or disrupt services, a tactic known as masquerading. The detection rule identifies renaming events of specific VMware file types on Linux systems, flagging potential malicious activity by monitoring deviations from expected file extensions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file that was renamed, including its original and new name, to understand the nature of the change.
+- Check the timestamp of the rename event to correlate it with other activities on the system, such as user logins or other file operations, to identify potential patterns or anomalies.
+- Investigate the user account or process responsible for the rename action by examining system logs or user activity to determine if the action was authorized or suspicious.
+- Analyze the system for any other recent rename events involving VMware-related files to assess if this is an isolated incident or part of a broader pattern.
+- Examine the system for signs of compromise or unauthorized access, such as unexpected processes, network connections, or changes in system configurations, to identify potential threats.
+- Consult with relevant stakeholders, such as system administrators or security teams, to verify if the rename action was part of a legitimate maintenance or operational task.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may involve renaming VMware ESXi files for organizational purposes. To manage this, identify and exclude specific users or processes that regularly perform these tasks from triggering alerts.
+- Automated backup or snapshot processes might rename files temporarily as part of their operation. Review and whitelist these processes to prevent unnecessary alerts.
+- Development or testing environments often involve frequent renaming of virtual machine files for configuration testing. Consider excluding these environments from the rule or setting up a separate monitoring profile with adjusted thresholds.
+- System updates or patches might include scripts that rename files as part of the update process. Verify and exclude these scripts if they are known and trusted.
+- Custom scripts or tools used by IT teams for managing virtual machines may rename files as part of their functionality. Ensure these scripts are documented and excluded from triggering the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or potential spread of malicious activity.
+- Verify the integrity of the renamed VMware ESXi files by comparing them with known good backups or snapshots, and restore any altered files from a secure backup if necessary.
+- Conduct a thorough review of recent system logs and user activity to identify any unauthorized access or actions that may have led to the file renaming.
+- Revert any unauthorized changes to system configurations or permissions that may have facilitated the renaming of critical files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar environments to detect any further attempts at file masquerading or other suspicious activities.
+- Review and update access controls and permissions for VMware ESXi files to ensure only authorized users have the ability to rename or modify these files."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+[[rule.threat.technique.subtechnique]]
+id = "T1036.003"
+name = "Rename Legitimate Utilities"
+reference = "https://attack.mitre.org/techniques/T1036/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_rename_esxi_index_file.toml

@@ -0,0 +1,119 @@
+[metadata]
+creation_date = "2023/04/11"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies instances where the "index.html" file within the "/usr/lib/vmware/*" directory is renamed on a Linux system.
+The rule monitors for the "rename" event action associated with this specific file and path, which could indicate
+malicious activity.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious Renaming of ESXI index.html File"
+references = [
+    "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
+]
+risk_score = 47
+rule_id = "c125e48f-6783-41f0-b100-c3bf1b114d16"
+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 Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and
+file.Ext.original.path : "/usr/lib/vmware/*"
+'''
+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 Suspicious Renaming of ESXI index.html File
+
+VMware ESXi hosts use the index.html file within their web interface for management tasks. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule monitors Linux systems for renaming actions targeting this file in the VMware directory, flagging potential defense evasion attempts by correlating file path and event actions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and event action, ensuring the "rename" action occurred on the "index.html" file within the "/usr/lib/vmware/*" directory.
+- Check the timestamp of the rename event to determine when the activity occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Identify the user or process responsible for the rename action by examining the associated user account and process details in the event logs.
+- Investigate the system's recent login history and user activity to identify any unauthorized access or anomalies that could be linked to the rename event.
+- Analyze the renamed file and any new files in the directory for signs of tampering or malicious content, using file integrity monitoring tools or antivirus scans.
+- Review network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or communication with a command and control server.
+- Consider isolating the affected host from the network to prevent further potential malicious activity while the investigation is ongoing.
+
+### False positive analysis
+
+- Routine maintenance or updates on VMware ESXi hosts may involve renaming the index.html file temporarily. Users can create exceptions for known maintenance windows to prevent unnecessary alerts.
+- Automated scripts or backup processes might rename the index.html file as part of their operations. Identify and whitelist these scripts or processes to avoid false positives.
+- System administrators may manually rename the index.html file for legitimate customization or troubleshooting purposes. Document and exclude these actions by specific user accounts or during specific time frames.
+- Security tools or monitoring solutions might trigger renaming actions as part of their scanning or remediation tasks. Verify and exclude these tools from the rule to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected VMware ESXi host from the network to prevent further unauthorized access or data exfiltration.
+- Verify the integrity of the index.html file by comparing it with a known good version from a trusted source to determine if it has been tampered with or replaced.
+- Restore the original index.html file from a secure backup if it has been altered or replaced, ensuring that the backup is from a time before the suspicious activity was detected.
+- Conduct a thorough review of recent access logs and system changes on the affected host to identify any unauthorized access or modifications that may have occurred.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be compromised.
+- Implement additional monitoring on the affected host and similar systems to detect any further attempts to rename or modify critical files.
+- Review and update access controls and permissions on the VMware ESXi host to ensure that only authorized personnel have the ability to modify critical system files."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+[[rule.threat.technique.subtechnique]]
+id = "T1036.003"
+name = "Rename Legitimate Utilities"
+reference = "https://attack.mitre.org/techniques/T1036/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+