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

nldcsc_elastic_rules/rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml

@@ -0,0 +1,153 @@
+[metadata]
+creation_date = "2025/03/11"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable
+locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/
+directory, which is commonly used for logging system events.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "File Creation in /var/log via Suspicious 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 File Creation in /var/log via Suspicious Process
+
+In Linux environments, the `/var/log` directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity.
+- Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities.
+- Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file.
+- Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise.
+- Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment.
+
+### False positive analysis
+
+- System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths.
+- Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes.
+- Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log.
+- Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files.
+- Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging.
+- Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
+- Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories.
+"""
+risk_score = 21
+rule_id = "ddf26e25-3e30-42b2-92db-bde8eb82ad67"
+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",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.category:file and host.os.type:linux and event.action:(creation or file_create_event or file_rename_event or rename) and
+(process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or ./* or /boot/*) or process.name:.*) and
+file.path:/var/log/* and not file.extension:*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1564"
+name = "Hide Artifacts"
+reference = "https://attack.mitre.org/techniques/T1564/"
+[[rule.threat.technique.subtechnique]]
+id = "T1564.001"
+name = "Hidden Files and Directories"
+reference = "https://attack.mitre.org/techniques/T1564/001/"
+
+
+
+[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 = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["file.path", "process.executable"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"
+
+

nldcsc_elastic_rules/rules/linux/discovery_docker_socket_discovery.toml

@@ -0,0 +1,128 @@
+[metadata]
+creation_date = "2025/03/04"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/04/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the
+Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact
+with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers.
+Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or
+move laterally within the environment.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Docker Socket Enumeration"
+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 Docker Socket Enumeration
+
+Docker sockets facilitate communication between the Docker client and daemon, enabling container management. Adversaries exploit this by accessing the socket to control containers, potentially escalating privileges or moving laterally. The detection rule identifies suspicious processes interacting with the Docker socket, using specific commands, to flag unauthorized enumeration attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious commands interacting with the Docker socket, specifically looking for the use of tools like curl, socat, nc, netcat, ncat, or nc.traditional.
+- Examine the command line arguments of the flagged process to understand the intent and scope of the interaction with the Docker socket, focusing on paths like /var/run/docker.sock or /run/docker.sock.
+- Identify the user account under which the suspicious process was executed to assess if it has legitimate access to Docker resources or if it might be compromised.
+- Check the historical activity of the involved user and process to determine if this behavior is anomalous or part of a known pattern.
+- Investigate any recent changes or deployments in the Docker environment that might explain the interaction with the Docker socket, such as new container setups or updates.
+- Correlate the alert with other security events or logs from the same host or network segment to identify potential lateral movement or privilege escalation attempts.
+
+### False positive analysis
+
+- Legitimate administrative tasks using tools like curl or socat to interact with Docker for monitoring or management purposes can trigger alerts. To handle this, create exceptions for specific user accounts or scripts that are known to perform these tasks regularly.
+- Automated scripts or services that check the status of Docker containers might be flagged. Identify these scripts and whitelist their process names or command lines to prevent unnecessary alerts.
+- Development environments where developers frequently use command-line tools to interact with Docker may cause false positives. Consider excluding specific development machines or user groups from the rule to reduce noise.
+- Continuous integration or deployment pipelines that use Docker commands as part of their workflow can be mistaken for enumeration attempts. Exclude these processes by identifying their unique command patterns or execution contexts.
+- Security tools that perform regular audits or checks on Docker environments might trigger the rule. Verify these tools and add them to an exception list to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert that are interacting with the Docker socket, such as those using curl, socat, or netcat.
+- Conduct a thorough review of Docker containers on the affected host to identify any unauthorized or malicious containers. Stop and remove any that are not recognized or are deemed suspicious.
+- Check for any unauthorized changes to Docker configurations or images and revert them to a known good state.
+- Review and restrict permissions on the Docker socket file (/var/run/docker.sock) to limit access to only trusted users and processes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional hosts or systems are affected.
+- Implement enhanced monitoring and logging for Docker socket interactions to detect and respond to similar threats more quickly in the future.
+"""
+risk_score = 21
+rule_id = "dd983e79-22e8-44d1-9173-d57dba514cac"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "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", "executed", "process_started") and
+process.name in ("curl", "socat", "nc", "netcat", "ncat", "nc.traditional") and
+process.command_line like ("*/var/run/docker.sock*", "*/run/docker.sock*")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1613"
+name = "Container and Resource Discovery"
+reference = "https://attack.mitre.org/techniques/T1613/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/discovery_dynamic_linker_via_od.toml

@@ -0,0 +1,126 @@
+[metadata]
+creation_date = "2024/02/01"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for dynamic linker discovery via the od utility. od (octal dump) is a command-line utility in Unix operating
+systems used for displaying data in various formats, including octal, hexadecimal, decimal, and ASCII, primarily used
+for examining and debugging binary files or data streams. Attackers can leverage od to analyze the dynamic linker by
+identifying injection points and craft exploits based on the observed behaviors and structures within these files.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious Dynamic Linker Discovery via od"
+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 Dynamic Linker Discovery via od
+
+The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files.
+- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs.
+- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities.
+- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts.
+- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives.
+- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files.
+- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity.
+- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign.
+- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files."""
+references = ["https://github.com/arget13/DDexec"]
+risk_score = 21
+rule_id = "0369e8a6-0fa7-4e7a-961a-53180a4c966e"
+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: Auditd Manager",
+    "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", "executed", "process_started")
+ and process.name == "od" and process.args in (
+  "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/etc/ld.so.preload", "/lib64/ld-linux-x86-64.so.2",
+  "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
+)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1057"
+name = "Process Discovery"
+reference = "https://attack.mitre.org/techniques/T1057/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/discovery_esxi_software_via_find.toml

@@ -0,0 +1,125 @@
+[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 instances where the 'find' command is started on a Linux system with arguments targeting specific VM-related
+paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization
+software, and their presence in the find command arguments may indicate that a threat actor is attempting to search for,
+analyze, or manipulate VM-related files and configurations on the system.
+"""
+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 = "ESXI Discovery via Find"
+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 ESXI Discovery via Find
+
+VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
+- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process.
+- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
+- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns.
+- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system.
+- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks.
+- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule.
+- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts.
+- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities.
+- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files.
+- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity.
+- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities.
+- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
+]
+risk_score = 47
+rule_id = "33a6752b-da5e-45f8-b13a-5f094c09522f"
+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: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "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 == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and
+  not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1518"
+name = "Software Discovery"
+reference = "https://attack.mitre.org/techniques/T1518/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+