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

nldcsc_elastic_rules/rules/linux/execution_python_tty_shell.toml

@@ -0,0 +1,121 @@
+[metadata]
+creation_date = "2020/04/15"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a simple reverse shell to a fully
+interactive tty after obtaining initial access to a host.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Interactive Terminal Spawned via Python"
+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 Interactive Terminal Spawned via Python
+
+Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh).
+- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal.
+- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious.
+- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network.
+- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events.
+- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event.
+
+### False positive analysis
+
+- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks.
+- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration.
+- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships.
+- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control.
+- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files.
+- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
+risk_score = 73
+rule_id = "d76b02ef-fc95-4001-9297-01cb7412232f"
+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 = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "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") and
+(
+  (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh",
+   "fish") and process.parent.args_count >= 3 and process.parent.args : "*pty.spawn*" and process.parent.args : "-c") or
+  (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh",
+   "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1)
+)
+'''
+
+
+[[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.006"
+name = "Python"
+reference = "https://attack.mitre.org/techniques/T1059/006/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/linux/execution_python_webserver_spawned.toml

@@ -0,0 +1,142 @@
+[metadata]
+creation_date = "2024/11/04"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies when a web server is spawned via Python. Attackers may use Python to spawn a web server to
+exfiltrate/infiltrate data or to move laterally within a network.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Web Server Spawned via Python"
+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 Web Server Spawned via Python
+
+Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer".
+- Investigate the user account associated with the process to determine if it is a known or expected user for running such services.
+- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server".
+- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration.
+- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts.
+- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server.
+
+### False positive analysis
+
+- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses.
+- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule.
+- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods.
+- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts.
+- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement.
+- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server.
+- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector.
+- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident.
+- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
+risk_score = 21
+rule_id = "99c2b626-de44-4322-b1f9-157ca408c17e"
+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: Execution",
+    "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or
+    (
+      process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+      process.command_line like~ "*python* -m http.server*"
+    )
+  )
+'''
+
+
+[[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.006"
+name = "Python"
+reference = "https://attack.mitre.org/techniques/T1059/006/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1570"
+name = "Lateral Tool Transfer"
+reference = "https://attack.mitre.org/techniques/T1570/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+

nldcsc_elastic_rules/rules/linux/execution_remote_code_execution_via_postgresql.toml

@@ -0,0 +1,126 @@
+[metadata]
+creation_date = "2022/06/20"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for suspicious activities that may indicate an attacker attempting to execute arbitrary code within a
+PostgreSQL environment. Attackers can execute code via PostgreSQL as a result of gaining unauthorized access to a public
+facing PostgreSQL database or exploiting vulnerabilities, such as remote command execution and SQL injection attacks,
+which can result in unauthorized access and malicious actions, and facilitate post-exploitation activities for
+unauthorized access and malicious actions.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Code Execution via Postgresql"
+risk_score = 47
+rule_id = "2a692072-d78d-42f3-a48a-775677d79c4e"
+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: Execution",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "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", "fork", "fork_event") and user.name == "postgres" and (
+  (process.parent.args : "*sh" and process.parent.args : "echo*") or
+  (process.args : "*sh" and process.args : "echo*")
+) and not (
+  process.parent.name == "puppet" or
+  process.command_line like (
+    "*BECOME-SUCCESS-*", "bash -c while true; do sleep 1;*", "df -l", "sleep 1", "who", "head -v -n *", "tail -v -n *",
+    "/bin/sh -c echo BECOME-SUCCESS*", "/usr/bin/python3 /var/tmp/ansible-tmp*"
+  ) or
+  process.parent.command_line like "*BECOME-SUCCESS-*"
+)
+'''
+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 Code Execution via Postgresql
+
+PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*".
+- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule.
+- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account.
+- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack.
+- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats.
+
+### False positive analysis
+
+- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet".
+- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS".
+- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns.
+- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments.
+- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious.
+
+### Response and remediation
+
+- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions.
+- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities.
+- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events.
+- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access.
+- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited.
+- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect.
+- 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.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/"

nldcsc_elastic_rules/rules/linux/execution_shell_evasion_linux_binary.toml

@@ -0,0 +1,213 @@
+[metadata]
+creation_date = "2022/05/06"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive
+system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator,
+and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Linux Restricted Shell Breakout via Linux Binary(s)"
+note = """## Triage and analysis
+
+### Investigating Linux Restricted Shell Breakout via Linux Binary(s)
+Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or
+environments by spawning an interactive system shell.
+Here are some possible avenues of investigation:
+- Examine the entry point to the host and user in action via the Analyse View.
+  - Identify the session entry leader and session user
+- Examine the contents of session leading to the abuse via the Session View.
+  - Examine the command execution pattern in the session, which may lead to suspricous activities
+- Examine the execution of commands in the spawned shell.
+  - Identify imment threat to the system from the executed commands
+  - Take necessary incident response actions to contain any malicious behviour caused via this execution.
+
+### Related rules
+
+- A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences.
+- Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment
+
+### Response and remediation
+
+Initiate the incident response process based on the outcome of the triage.
+
+- If the triage releaved suspicious netwrok activity from the malicious spawned shell,
+  - Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware execution via the maliciously spawned shell,
+  - 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.
+- If the triage revelaed defence evasion for imparing defenses
+  - Isolate the involved host to prevent further post-compromise behavior.
+  - Identified the disabled security guard components on the host and take necessary steps in renebaling the same.
+  - If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same.
+- If the triage revelaed addition of persistence mechanism exploit like auto start scripts
+  - Isolate further login to the systems that can initae auto start scripts.
+  - Identify the auto start scripts and disable and remove the same from the systems
+- If the triage revealed data crawling or data export via remote copy
+  - Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling
+  - Intiate compromised credential deactivation and credential rotation process for all exposed crednetials.
+  - Investiagte if any IPR data was accessed during the data crawling and take appropriate actions.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+"""
+references = [
+    "https://gtfobins.github.io/gtfobins/apt/",
+    "https://gtfobins.github.io/gtfobins/apt-get/",
+    "https://gtfobins.github.io/gtfobins/nawk/",
+    "https://gtfobins.github.io/gtfobins/mawk/",
+    "https://gtfobins.github.io/gtfobins/awk/",
+    "https://gtfobins.github.io/gtfobins/gawk/",
+    "https://gtfobins.github.io/gtfobins/busybox/",
+    "https://gtfobins.github.io/gtfobins/c89/",
+    "https://gtfobins.github.io/gtfobins/c99/",
+    "https://gtfobins.github.io/gtfobins/cpulimit/",
+    "https://gtfobins.github.io/gtfobins/crash/",
+    "https://gtfobins.github.io/gtfobins/env/",
+    "https://gtfobins.github.io/gtfobins/expect/",
+    "https://gtfobins.github.io/gtfobins/find/",
+    "https://gtfobins.github.io/gtfobins/flock/",
+    "https://gtfobins.github.io/gtfobins/gcc/",
+    "https://gtfobins.github.io/gtfobins/mysql/",
+    "https://gtfobins.github.io/gtfobins/nice/",
+    "https://gtfobins.github.io/gtfobins/ssh/",
+    "https://gtfobins.github.io/gtfobins/vi/",
+    "https://gtfobins.github.io/gtfobins/vim/",
+    "https://gtfobins.github.io/gtfobins/capsh/",
+    "https://gtfobins.github.io/gtfobins/byebug/",
+    "https://gtfobins.github.io/gtfobins/git/",
+    "https://gtfobins.github.io/gtfobins/ftp/",
+    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
+]
+risk_score = 47
+rule_id = "52376a86-ee86-4967-97ae-1a05f55816f0"
+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).
+
+Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above.
+#### To confirm that Session View data is enabled:
+- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies.
+- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom.
+- Check the box for “Process events”, and turn on the “Include session data” toggle.
+- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”.
+- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle.
+For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the [helper guide](https://www.elastic.co/guide/en/security/current/session-view.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+(
+  /* launching shell from capsh */
+  (process.name == "capsh" and process.args == "--") or
+
+  /* launching shells from unusual parents or parent+arg combos */
+  (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and (
+    (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or
+    (process.parent.name == "git" and process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or
+     process.args : ("*PAGER*", "!*sh", "exec *sh") and not process.name == "ssh" ) or
+    (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and
+    (
+      process.parent.args : "BEGIN {system(*)}" or
+      (process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or process.args : ("*PAGER*", "!*sh", "exec *sh")) or
+      (
+        (process.parent.args : "exec=*sh" or (process.parent.args : "-I" and process.parent.args : "*sh")) or
+        (process.args : "exec=*sh" or (process.args : "-I" and process.args : "*sh"))
+        )
+      )
+    ) or
+
+    /* shells specified in parent args */
+    /* nice rule is broken in 8.2 */
+    (process.parent.args : "*sh" and
+      (
+        (process.parent.name == "nice") or
+        (process.parent.name == "cpulimit" and process.parent.args == "-f") or
+        (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and
+         process.parent.args == ";" and process.parent.args : "/bin/*sh") or
+        (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/")
+      )
+    )
+  )) or
+
+  /* shells specified in args */
+  (process.args : "*sh" and (
+    (process.parent.name == "crash" and process.parent.args == "-h") or
+    (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog")
+    /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */
+
+  )) or
+  (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not
+   process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and
+   process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs") or
+  (process.name == "env" and process.args_count == 2 and process.args : "*sh") or
+  (process.parent.name in ("vi", "vim") and process.parent.args == "-c" and process.parent.args : ":!*sh") or
+  (process.parent.name in ("c89", "c99", "gcc") and process.parent.args : "*sh,-s" and process.parent.args == "-wrapper") or
+  (process.parent.name == "expect" and process.parent.args == "-c" and process.parent.args : "spawn *sh;interact") or
+  (process.parent.name == "mysql" and process.parent.args == "-e" and process.parent.args : "\\!*sh") or
+  (process.parent.name == "ssh" and process.parent.args == "-o" and process.parent.args : "ProxyCommand=;*sh 0<&2 1>&2")
+)
+'''
+
+
+[[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/"
+