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

nldcsc_elastic_rules/rules/linux/persistence_shared_object_creation.toml

@@ -0,0 +1,205 @@
+[metadata]
+creation_date = "2023/06/09"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/03/11"
+
+[transform]
+[[transform.osquery]]
+label = "Osquery - Retrieve File Listing Information"
+query = "SELECT * FROM file WHERE path = {{file.path}}\n"
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Additional File Listing Information"
+query = """
+SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS
+file_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS
+file_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT
+JOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path = {{file.path}}
+"""
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Running Processes by User"
+query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Crontab Information"
+query = "SELECT * FROM crontab"
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Listening Ports"
+query = "SELECT pid, address, port, socket, protocol, path FROM listening_ports"
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Open Sockets"
+query = "SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"
+
+[[transform.osquery]]
+label = "Osquery - Retrieve Information for a Specific User"
+query = "SELECT * FROM users WHERE username = {{user.name}}"
+
+[[transform.osquery]]
+label = "Osquery - Investigate the Account Authentication Status"
+query = "SELECT * FROM logged_in_users WHERE user = {{user.name}}"
+
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors the creation of shared object files by previously unknown processes. The creation of a shared object
+file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime. While
+this process is typically used for legitimate purposes, malicious actors can leverage shared object files to execute
+unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows
+malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the
+affected system and its data.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.*", "endgame-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Shared Object Created or Changed by Previously Unknown Process"
+note = """## Triage and analysis
+
+### Investigating Shared Object Created or Changed by Previously Unknown Process
+
+A shared object file is a compiled library file (typically with a .so extension) that can be dynamically linked to executable programs at runtime, allowing for code reuse and efficient memory usage. The creation of a shared object file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime.
+
+Malicious actors can leverage shared object files to execute unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the affected system and its data.
+
+This rule monitors the creation of shared object files by previously unknown processes through the usage of the new terms rule type.
+
+> **Note**:
+> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.
+
+#### Possible Investigation Steps
+
+- Investigate the shared object that was created or modified through OSQuery.
+  - $osquery_0
+  - $osquery_1
+- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
+  - $osquery_2
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. 
+  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
+    - Use a private sandboxed malware analysis system to perform analysis.
+      - Observe and collect information about the following activities:
+        - Attempts to contact external domains and addresses.
+          - Check if the domain is newly registered or unexpected.
+          - Check the reputation of the domain or IP address.
+        - File access, modification, and creation activities.
+        - Cron jobs, services and other persistence mechanisms.
+            - $osquery_3
+- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.
+  - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.
+    - $osquery_4
+    - $osquery_5
+  - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
+    - $osquery_6
+- Investigate whether the user is currently logged in and active.
+    - $osquery_7
+
+### False Positive Analysis
+
+- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
+- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. 
+- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+"""
+references = ["https://threatpost.com/sneaky-malware-backdoors-linux/180158/"]
+risk_score = 47
+rule_id = "aebaa51f-2a91-4f6a-850b-b601db2293f4"
+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: Persistence",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+host.os.type:"linux" and event.action:("creation" or "file_create_event" or "file_rename_event" or "rename" or "file_write_event") and
+(file.extension:"so" or file.name:*.so.*) and
+file.path:(
+  /dev/shm/* or /usr/lib/* or /usr/lib64/* or /usr/local/lib/* or /usr/local/lib64/* or /lib/x86_64-linux-gnu/* or
+  /usr/lib/x86_64-linux-gnu/* or /lib/i386-linux-gnu/* or /usr/lib/i386-linux-gnu/* or /lib/* or /lib64/*
+) and not (
+  process.name:(
+    "dockerd" or "dpkg" or "rpm" or "snapd" or "yum" or "vmis-launcher" or "pacman" or "apt-get" or "dnf" or "podman" or
+    platform-python* or "dnf-automatic" or "unattended-upgrade" or "apk" or "snap-update-ns" or "install" or "exe" or
+    "systemd" or "root" or "sshd" or "pip" or "jlink" or python* or "update-alternatives" or pip* or "crio" or "packagekitd"
+  ) or 
+  (process.name:"vmware-install.pl" and file.path:/usr/lib/vmware-tools/*) or
+  (process.name:"ssm-agent-worker" and file.path:/usr/lib/jvm/java*) or 
+  process.executable : (/dev/fd/* or "/" or "/kaniko/executor" or "/usr/bin/buildah")
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1574"
+name = "Hijack Execution Flow"
+reference = "https://attack.mitre.org/techniques/T1574/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1574.006"
+name = "Dynamic Linker Hijacking"
+reference = "https://attack.mitre.org/techniques/T1574/006/"
+
+[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/persistence_shell_configuration_modification.toml

@@ -0,0 +1,154 @@
+[metadata]
+creation_date = "2024/04/30"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/06/03"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors the creation/alteration of a shell configuration file. Unix systems use shell configuration files to
+set environment variables, create aliases, and customize the user's environment. Adversaries may modify or add a shell
+configuration file to execute malicious code and gain persistence in the system. This behavior is consistent with the
+Kaiji malware family.
+"""
+false_positives = ["Legitimate user shell modification activity."]
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Shell Configuration Creation or Modification"
+references = [
+    "https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/",
+    "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
+]
+risk_score = 47
+rule_id = "28f6f34b-8e16-487a-b5fd-9d22eb903db8"
+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: Persistence",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path : (
+  // system-wide configurations
+  "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/bash.bash_logout", "/etc/zsh/*",
+  "/etc/csh.cshrc", "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc",
+  // root and user configurations
+  "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", "/home/*/.bash_profile",
+  "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", "/root/.bash_profile",
+  "/root/.bash_aliases", "/home/*/.bash_aliases", "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile",
+  "/root/.zshrc", "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login",
+  "/root/.logout", "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish", "/home/*/.kshrc",
+  "/root/.kshrc"
+) and not (
+  process.executable in (
+    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
+    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
+    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
+    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
+    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
+    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
+    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*",  "/usr/bin/pamac-daemon",
+    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/sbin/adduser", "/usr/sbin/useradd", "/usr/local/bin/dockerd",
+    "/usr/sbin/gdm", "/usr/bin/unzip", "/usr/bin/gnome-shell", "/sbin/mkhomedir_helper", "/usr/sbin/sshd",
+    "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/xfce4-session", "/usr/libexec/oddjob/mkhomedir", "/sbin/useradd",
+    "/usr/lib/systemd/systemd", "/usr/sbin/crond", "/usr/bin/pamac-daemon", "/usr/sbin/mkhomedir_helper",
+    "/opt/pbis/sbin/lwsmd", "/usr/sbin/oddjobd"
+  ) or
+  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
+  file.Ext.original.extension == "dpkg-new" or
+  process.executable : (
+    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
+    "/usr/libexec/platform-python*"
+  ) or
+  process.executable == null or
+  process.name in ("adclient", "mkhomedir_helper", "teleport", "mkhomedir", "adduser", "desktopDaemon", "executor", "crio") or
+  (process.name == "sed" and file.name : "sed*") or
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
+)
+'''
+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 Shell Configuration Creation or Modification
+
+Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query.
+- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose.
+- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change.
+- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands.
+- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised.
+- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts.
+- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client.
+- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios.
+- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives.
+- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code.
+- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1546.004"
+name = "Unix Shell Configuration Modification"
+reference = "https://attack.mitre.org/techniques/T1546/004/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/linux/persistence_simple_web_server_connection_accepted.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2024/12/17"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may
+create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell
+payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when
+an attacker requests the server to execute a command or script via a potential backdoor.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-endpoint.events.network*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Simple HTTP Web Server Connection"
+risk_score = 21
+rule_id = "183f3cd2-4cc6-44c0-917c-c5d29ecdcf74"
+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: Persistence",
+    "Tactic: Execution",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+sequence by process.entity_id with maxspan=1m
+[process where host.os.type == "linux" and event.type == "start" and 
+ (
+  (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or
+  (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
+ )]
+[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"]
+'''
+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 Simple HTTP Web Server Connection
+
+Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.
+- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.
+- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.
+- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.
+- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.
+- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.
+- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.
+- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.
+- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.
+- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.
+- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+  [rule.threat.tactic]
+  name = "Persistence"
+  id = "TA0003"
+  reference = "https://attack.mitre.org/tactics/TA0003/"
+
+    [[rule.threat.technique]]
+    id = "T1505"
+    name = "Server Software Component"
+    reference = "https://attack.mitre.org/techniques/T1505/"
+
+      [[rule.threat.technique.subtechnique]]
+      id = "T1505.003"
+      name = "Web Shell"
+      reference = "https://attack.mitre.org/techniques/T1505/003/"
+
+[[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]]
+framework = "MITRE ATT&CK"
+
+  [rule.threat.tactic]
+  name = "Command and Control"
+  id = "TA0011"
+  reference = "https://attack.mitre.org/tactics/TA0011/"
+
+    [[rule.threat.technique]]
+    name = "Application Layer Protocol"
+    id = "T1071"
+    reference = "https://attack.mitre.org/techniques/T1071/"