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

nldcsc_elastic_rules/rules/cross-platform/execution_potential_widespread_malware_infection.toml

@@ -0,0 +1,92 @@
+[metadata]
+creation_date = "2024/05/08"
+maturity = "production"
+updated_date = "2025/07/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to
+prioritize triage and response, as this can potentially indicate a widespread malware infection.
+"""
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Potential Widespread Malware Infection Across Multiple Hosts"
+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 Widespread Malware Infection Across Multiple Hosts
+
+Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values.
+- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware.
+- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector.
+- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes.
+- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities.
+- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats.
+- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests.
+- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts.
+- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives.
+- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged.
+
+### Response and remediation
+
+- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques.
+- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures.
+- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions.
+- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited.
+- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning.
+- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds.
+- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response."""
+references = ["https://github.com/elastic/protections-artifacts/tree/main/yara/rules"]
+risk_score = 73
+rule_id = "28371aa1-14ed-46cf-ab5b-2fc7d1942278"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "Data Source: Elastic Defend",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-endpoint.alerts-*
+| where event.code in ("malicious_file", "memory_signature", "shellcode_thread") and rule.name is not null
+| keep host.id, rule.name, event.code
+| stats Esql.host_id_count_distinct = count_distinct(host.id) by rule.name, event.code
+| where Esql.host_id_count_distinct >= 3
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1204"
+name = "User Execution"
+reference = "https://attack.mitre.org/techniques/T1204/"
+[[rule.threat.technique.subtechnique]]
+id = "T1204.002"
+name = "Malicious File"
+reference = "https://attack.mitre.org/techniques/T1204/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/cross-platform/execution_revershell_via_shell_cmd.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2020/01/07"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity."
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Reverse Shell Activity via Terminal"
+note = """## Triage and analysis
+
+### Investigating Potential Reverse Shell Activity via Terminal
+
+A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. This activity is typically the result of vulnerability exploitation, malware infection, or penetration testing.
+
+This rule identifies commands that are potentially related to reverse shell activities using shell applications.
+
+#### Possible investigation steps
+
+- Examine the command line and extract the target domain or IP address information.
+  - Check if the domain is newly registered or unexpected.
+  - Check the reputation of the domain or IP address.
+  - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
+- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.
+
+### False positive analysis
+
+- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.
+
+### 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.
+- 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.
+- Take actions to terminate processes and connections used by the attacker.
+- 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.
+- 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://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md",
+    "https://github.com/WangYihang/Reverse-Shell-Manager",
+    "https://www.netsparker.com/blog/web-security/understanding-reverse-shells/",
+    "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security",
+]
+risk_score = 73
+rule_id = "a1a0375f-22c2-48c0-81a4-7c2d11cc6856"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where event.type in ("start", "process_started") and
+  process.name in ("sh", "bash", "zsh", "dash", "zmodload") and
+  process.args : ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*", "*zsh/net/udp*") and
+
+  /* noisy FPs */
+  not (process.parent.name : "timeout" and process.executable : "/var/lib/docker/overlay*") and
+  not process.command_line : (
+    "*/dev/tcp/sirh_db/*", "*/dev/tcp/remoteiot.com/*", "*dev/tcp/elk.stag.one/*", "*dev/tcp/kafka/*",
+    "*/dev/tcp/$0/$1*", "*/dev/tcp/127.*", "*/dev/udp/127.*", "*/dev/tcp/localhost/*", "*/dev/tcp/itom-vault/*") and
+  not process.parent.command_line : "runc init"
+'''
+
+
+[[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.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml

@@ -0,0 +1,132 @@
+[metadata]
+creation_date = "2021/12/10"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/27"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an outbound network connection by JAVA to LDAP, RMI or DNS standard ports followed by a suspicious JAVA child
+processes. This may indicate an attempt to exploit a JAVA/NDI (Java Naming and Directory Interface) injection
+vulnerability.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential JAVA/JNDI Exploitation Attempt"
+references = [
+    "https://www.lunasec.io/docs/blog/log4j-zero-day/",
+    "https://github.com/christophetd/log4shell-vulnerable-app",
+    "https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf",
+    "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security",
+    "https://www.elastic.co/security-labs/analysis-of-log4shell-cve-2021-45046",
+]
+risk_score = 73
+rule_id = "c3f5e1d8-910e-43b4-8d44-d748e498ca86"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Use Case: Vulnerability",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id with maxspan=1m
+ [network where event.action == "connection_attempted" and
+  process.name : "java" and
+  /*
+     outbound connection attempt to
+     LDAP, RMI or DNS standard ports
+     by JAVA process
+   */
+  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
+ [process where event.type == "start" and
+
+  /* Suspicious JAVA child process */
+  process.parent.name : "java" and
+   process.name : ("sh",
+                   "bash",
+                   "dash",
+                   "ksh",
+                   "tcsh",
+                   "zsh",
+                   "curl",
+                   "perl*",
+                   "python*",
+                   "ruby*",
+                   "php*",
+                   "wget") and
+    not process.command_line like~ (
+      "bash -c ulimit -u",
+      "bash /opt/flutter/bin/flutter*",
+      "bash -c echo $$",
+      "/bin/bash /opt/python3/bin/jira*",
+      "/bin/sh -c env LC_ALL=C /usr/sbin/lpc status*"
+    )] by process.parent.pid
+'''
+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 JAVA/JNDI Exploitation Attempt
+
+Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries exploit JNDI by injecting malicious payloads that trigger outbound connections to LDAP, RMI, or DNS services, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making suspicious outbound connections followed by the execution of potentially harmful child processes, such as shell scripts or scripting languages, indicating a possible compromise.
+
+### Possible investigation steps
+
+- Review the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and identify the destination IP addresses to determine if they are known malicious or suspicious entities.
+- Examine the process tree to verify the parent-child relationship between the Java process and any suspicious child processes such as shell scripts or scripting languages (e.g., sh, bash, curl, python).
+- Check the command line arguments and environment variables of the suspicious child processes to identify any potentially malicious payloads or commands being executed.
+- Investigate the host's recent activity and logs for any other indicators of compromise or unusual behavior that might correlate with the suspected exploitation attempt.
+- Assess the system for any unauthorized changes or new files that may have been introduced as a result of the exploitation attempt, focusing on directories commonly used by Java applications.
+
+### False positive analysis
+
+- Development and testing environments may trigger false positives when developers use Java applications to test connections to LDAP, RMI, or DNS services. To mitigate this, exclude known development servers or IP ranges from the detection rule.
+- Automated scripts or maintenance tasks that involve Java applications making legitimate outbound connections to the specified ports can be mistaken for exploitation attempts. Identify and whitelist these scripts or tasks by their process names or hashes.
+- Legitimate Java-based applications that require frequent updates or data retrieval from external services might generate similar network patterns. Monitor and document these applications, then create exceptions for their specific network behaviors.
+- Security tools or monitoring solutions that use Java for network scanning or analysis might inadvertently match the rule's criteria. Ensure these tools are recognized and excluded by their process identifiers or network activity profiles.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further outbound connections and potential lateral movement.
+- Terminate any suspicious Java processes identified in the alert, especially those making outbound connections to LDAP, RMI, or DNS ports.
+- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious processes, focusing on child processes like shell scripts or scripting languages.
+- Restore the affected system from a known good backup if unauthorized changes or malware are detected.
+- Update and patch Java and any related applications to the latest versions to mitigate known vulnerabilities.
+- Implement network-level controls to block outbound connections to suspicious or unauthorized LDAP, RMI, or DNS services from Java processes.
+- Escalate the incident to the security operations center (SOC) or incident response 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.007"
+name = "JavaScript"
+reference = "https://attack.mitre.org/techniques/T1059/007/"
+
+
+[[rule.threat.technique]]
+id = "T1203"
+name = "Exploitation for Client Execution"
+reference = "https://attack.mitre.org/techniques/T1203/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/cross-platform/guided_onboarding_sample_rule.toml

@@ -0,0 +1,80 @@
+[metadata]
+creation_date = "2022/09/22"
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat
+activity.
+"""
+enabled = false
+false_positives = [
+    "This rule is not looking for threat activity. Disable the rule if you're already familiar with alerts.",
+]
+from = "now-35m"
+index = ["auditbeat-*", "filebeat-*", "logs-*", "winlogbeat-*"]
+interval = "30m"
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 1
+name = "My First Rule"
+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 My First Rule
+Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively.
+
+### Possible investigation steps
+
+- Review the event data associated with the alert to understand the context and source of the event.kind:event.
+- Check the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time.
+- Identify the host or user associated with the event to assess if there is any unusual or unauthorized activity.
+- Examine related logs or events from the same source to identify any patterns or anomalies that could indicate suspicious behavior.
+- Consult with team members or use internal resources to determine if the event is part of normal operations or if it requires further investigation.
+
+### False positive analysis
+
+- Routine system events can trigger alerts, as the rule monitors all event data without filtering for specific threats.
+- Identify and document common non-threatening events that frequently trigger alerts, such as regular system updates or scheduled tasks.
+- Use exceptions to exclude these documented non-threatening events from triggering alerts, reducing noise and focusing on genuine threats.
+- Regularly review and update the list of exceptions to ensure it remains relevant and does not inadvertently exclude new potential threats.
+- Collaborate with IT and operations teams to understand normal event patterns and adjust the rule's exceptions accordingly.
+
+### Response and remediation
+
+- Verify the legitimacy of the event by cross-referencing with known benign activities or scheduled tasks to rule out false positives.
+- Contain any potential threat by isolating affected systems or accounts if suspicious activity is confirmed, preventing further unauthorized access or damage.
+- Remediate by reviewing and adjusting logging configurations to ensure accurate event capture and reduce the risk of adversaries exploiting logging mechanisms.
+- Escalate the incident to the appropriate security team or management if the event correlates with other suspicious activities or if it indicates a potential breach.
+- Enhance detection capabilities by updating alerting rules to include additional context or indicators observed during the investigation, ensuring better identification of similar threats in the future.
+
+This is a test alert.
+
+This alert does not show threat activity. Elastic created this alert to help you understand how alerts work.
+
+For normal rules, the Investigation Guide will help analysts investigate alerts.
+
+This alert will show once every 24 hours for each host. It is safe to disable this rule.
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-rules.html"]
+risk_score = 21
+rule_id = "a198fbbd-9413-45ec-a269-47ae4ccf59ce"
+severity = "low"
+tags = ["Use Case: Guided Onboarding", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.kind:event
+'''
+
+
+
+[rule.threshold]
+field = ["host.name"]
+value = 1
+

nldcsc_elastic_rules/rules/cross-platform/impact_hosts_file_modified.toml

@@ -0,0 +1,119 @@
+[metadata]
+creation_date = "2020/07/07"
+integration = ["endpoint", "windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first
+point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic
+to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or
+RHEL) and macOS systems.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Hosts File Modified"
+note = """## Triage and analysis
+
+### Investigating Hosts File Modified
+
+Operating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to "Fail open" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this [CISA Alert](https://www.cisa.gov/uscert/ncas/alerts/aa22-074a).
+
+This rule identifies modifications in the hosts file across multiple operating systems using process creation events for Linux and file events in Windows and macOS.
+
+#### Possible investigation steps
+
+- Identify the specifics of the involved assets, such as role, criticality, and associated users.
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Examine the changes to the hosts file by comparing it against file backups, volume shadow copies, and other restoration mechanisms.
+
+### False positive analysis
+
+- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and the configuration was justified.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Consider isolating the involved host to prevent further post-compromise behavior.
+- 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.
+- Review the privileges of the administrator account that performed the action.
+- 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.
+- 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://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-reference-yml.html"]
+risk_score = 47
+rule_id = "9c260313-c811-4ec8-ab89-8f6530e0246c"
+setup = """## Setup
+
+For Windows systems using Auditbeat, this rule requires adding `C:/Windows/System32/drivers/etc` as an additional path in the 'file_integrity' module of auditbeat.yml.
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: Windows",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+]
+timeline_id = "4d4c0b59-ea83-483f-b8c1-8c360ee53c5c"
+timeline_title = "Comprehensive File Timeline"
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where
+
+  /* file events for creation; file change events are not captured by some of the included sources for linux and so may
+     miss this, which is the purpose of the process + command line args logic below */
+  (
+   event.category == "file" and event.type in ("change", "creation") and
+     file.path : ("/private/etc/hosts", "/etc/hosts", "?:\\Windows\\System32\\drivers\\etc\\hosts") and 
+     not process.name in ("dockerd", "rootlesskit", "podman", "crio")
+  )
+  or
+
+  /* process events for change targeting linux only */
+  (
+   event.category == "process" and event.type in ("start") and
+     process.name in ("nano", "vim", "vi", "emacs", "echo", "sed") and
+     process.args : ("/etc/hosts") and 
+     not process.parent.name in ("dhclient-script", "google_set_hostname")
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1565"
+name = "Data Manipulation"
+reference = "https://attack.mitre.org/techniques/T1565/"
+[[rule.threat.technique.subtechnique]]
+id = "T1565.001"
+name = "Stored Data Manipulation"
+reference = "https://attack.mitre.org/techniques/T1565/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+