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

nldcsc_elastic_rules/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml

@@ -0,0 +1,109 @@
+[metadata]
+creation_date = "2023/09/14"
+integration = ["dga", "endpoint", "network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 70
+author = ["Elastic"]
+description = """
+A population analysis machine learning job detected potential DGA (domain generation algorithm) activity. Such activity
+is often used by malware command and control (C2) channels. This machine learning job looks for a source IP address
+making DNS requests that have an aggregate high probability of being DGA activity.
+"""
+from = "now-45m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "dga_high_sum_probability"
+name = "Potential DGA Activity"
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/dga",
+    "https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration",
+]
+risk_score = 21
+rule_id = "ff0d807d-869b-4a0d-a493-52bc46d2f1b1"
+setup = """## Setup
+
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
+
+### DGA Detection Setup
+The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
+
+#### Prerequisite Requirements:
+- Fleet is required for DGA Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- DNS events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint), [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration, or [Packetbeat](https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html).
+- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+- To set up and run Packetbeat, follow [this](https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html) guide.
+
+#### The following steps should be executed to install assets associated with the DGA Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+### Anomaly Detection Setup
+Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job.
+- Go to the Kibana homepage. Under Analytics, click Machine Learning.
+- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched DNS events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture.
+- If the selected Data View contains events that match the query in [this](https://github.com/elastic/integrations/blob/main/packages/dga/kibana/ml_module/dga-ml.json) configuration file, you will see a card for DGA under "Use preconfigured jobs".
+- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed.
+"""
+severity = "low"
+tags = [
+    "Use Case: Domain Generation Algorithm Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Command and Control",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+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 DGA Activity
+Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address identified in the alert to determine if it belongs to a known or trusted entity within the organization.
+- Analyze the DNS request patterns from the source IP to identify any unusual or suspicious domain names that may indicate DGA activity.
+- Cross-reference the flagged domains with threat intelligence feeds to check for known malicious domains or patterns associated with DGAs.
+- Investigate the network traffic associated with the source IP to identify any additional indicators of compromise or communication with known malicious IPs.
+- Check for any recent changes or anomalies in the system or network configurations that could explain the detected activity.
+- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response efforts.
+
+### False positive analysis
+
+- Legitimate software updates or cloud services may generate high volumes of DNS requests that resemble DGA patterns. Users can create exceptions for known update servers or cloud service domains to reduce false positives.
+- Content delivery networks (CDNs) often use dynamically generated subdomains for load balancing and distribution, which can trigger DGA alerts. Identifying and excluding these CDN domains from analysis can help mitigate false positives.
+- Large organizations with complex internal networks might have internal applications that generate DNS requests similar to DGA activity. Conducting a thorough review of internal DNS traffic and whitelisting known internal domains can prevent these false positives.
+- Some security tools or network appliances may perform DNS lookups as part of their normal operation, which could be misclassified as DGA activity. Identifying these tools and excluding their IP addresses from the analysis can help manage false positives.
+
+### Response and remediation
+
+- Isolate the affected systems: Immediately disconnect any systems identified as making suspicious DNS requests from the network to prevent further communication with potential C2 servers.
+- Block identified domains: Use firewall and DNS filtering solutions to block the domains flagged by the detection rule, preventing any further communication attempts.
+- Conduct a thorough system scan: Use updated antivirus and anti-malware tools to scan the isolated systems for any signs of infection or malicious software.
+- Analyze network traffic: Review network logs to identify any additional suspicious activity or other systems that may be affected, focusing on unusual DNS requests and connections.
+- Patch and update systems: Ensure all systems, especially those identified in the alert, are fully patched and updated to mitigate vulnerabilities that could be exploited by malware.
+- Restore from backups: If malware is confirmed, restore affected systems from clean backups to ensure no remnants of the infection remain.
+- Escalate to incident response team: If the threat is confirmed and widespread, escalate the incident to the organization's incident response team for further investigation and coordinated response efforts."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1568"
+name = "Dynamic Resolution"
+reference = "https://attack.mitre.org/techniques/T1568/"
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

nldcsc_elastic_rules/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2023/09/14"
+integration = ["dga", "endpoint", "network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+A supervised machine learning model has identified a DNS question name with a high probability of sourcing from a Domain
+Generation Algorithm (DGA), which could indicate command and control network activity.
+"""
+from = "now-10m"
+index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Machine Learning Detected a DNS Request With a High DGA Probability Score"
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/dga",
+    "https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration",
+]
+risk_score = 21
+rule_id = "da7f5803-1cd4-42fd-a890-0173ae80ac69"
+setup = """## Setup
+
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
+
+### DGA Detection Setup
+The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
+
+#### Prerequisite Requirements:
+- Fleet is required for DGA Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- DNS events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint), [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration, or [Packetbeat](https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html).
+- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+- To set up and run Packetbeat, follow [this](https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html) guide.
+
+#### The following steps should be executed to install assets associated with the DGA Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Configure the ingest pipeline**.
+"""
+severity = "low"
+tags = [
+    "Domain: Network",
+    "Domain: Endpoint",
+    "Data Source: Elastic Defend",
+    "Use Case: Domain Generation Algorithm Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Command and Control",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+ml_is_dga.malicious_probability > 0.98
+'''
+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 Machine Learning Detected a DNS Request With a High DGA Probability Score
+
+Machine learning models analyze DNS requests to identify patterns indicative of Domain Generation Algorithms (DGAs), often used by attackers to establish command and control channels. These algorithms generate numerous domain names, making detection challenging. The detection rule leverages a model to flag DNS queries with high DGA probability, aiding in identifying potential malicious activity.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and gather additional context about the request, such as the timestamp and the source IP address.
+- Cross-reference the identified domain name with threat intelligence databases to determine if it is a known malicious domain or associated with any known threat actors or campaigns.
+- Investigate the source IP address to determine if it belongs to a legitimate user or system within the network, and check for any unusual or suspicious activity associated with this IP address.
+- Analyze network traffic logs to identify any additional communication attempts to the flagged domain or other suspicious domains, which may indicate further command and control activity.
+- Check endpoint security logs for any signs of compromise or suspicious behavior on the device that initiated the DNS request, such as unexpected processes or connections.
+- Consider isolating the affected system from the network if there is strong evidence of compromise, to prevent further potential malicious activity while conducting a deeper forensic analysis.
+
+### False positive analysis
+
+- Legitimate software updates or services may use domain generation techniques for load balancing or redundancy, leading to false positives. Users can create exceptions for known update services or trusted software to reduce these alerts.
+- Content delivery networks (CDNs) often use dynamically generated domains to optimize content delivery, which might be flagged. Identifying and whitelisting these CDN domains can help minimize unnecessary alerts.
+- Some security tools and applications use DGA-like patterns for legitimate purposes, such as generating unique identifiers. Users should verify the source and purpose of these requests and consider excluding them if they are confirmed to be non-threatening.
+- Internal testing environments or development tools might generate domains that resemble DGA activity. Users can exclude these environments from monitoring or adjust the rule to ignore specific internal IP ranges or domain patterns.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential command and control communication.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and block the identified suspicious domain names at the network perimeter to prevent any further communication attempts.
+- Analyze network traffic logs to identify any other systems that may have communicated with the flagged domains and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring on the affected system and network segment to detect any signs of persistence or further malicious activity.
+- Update and reinforce endpoint protection measures, ensuring all systems have the latest security patches and configurations to prevent similar threats in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1568"
+name = "Dynamic Resolution"
+reference = "https://attack.mitre.org/techniques/T1568/"
+[[rule.threat.technique.subtechnique]]
+id = "T1568.002"
+name = "Domain Generation Algorithms"
+reference = "https://attack.mitre.org/techniques/T1568/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

nldcsc_elastic_rules/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2023/09/14"
+integration = ["dga", "endpoint", "network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+A supervised machine learning model has identified a DNS question name that is predicted to be the result of a Domain
+Generation Algorithm (DGA), which could indicate command and control network activity.
+"""
+from = "now-10m"
+index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Machine Learning Detected a DNS Request Predicted to be a DGA Domain"
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/dga",
+    "https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration",
+]
+risk_score = 21
+rule_id = "f3403393-1fd9-4686-8f6e-596c58bc00b4"
+setup = """## Setup
+
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
+
+### DGA Detection Setup
+The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
+
+#### Prerequisite Requirements:
+- Fleet is required for DGA Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- DNS events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint), [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration, or [Packetbeat](https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html).
+- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+- To set up and run Packetbeat, follow [this](https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html) guide.
+
+#### The following steps should be executed to install assets associated with the DGA Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Configure the ingest pipeline**.
+"""
+severity = "low"
+tags = [
+    "Domain: Network",
+    "Domain: Endpoint",
+    "Data Source: Elastic Defend",
+    "Use Case: Domain Generation Algorithm Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Command and Control",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com
+'''
+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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain
+
+Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), which adversaries use to dynamically generate domain names for command and control (C2) communication. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus helping to identify potential C2 activity.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific domain flagged by the machine learning model as a potential DGA domain. Focus on the field ml_is_dga.malicious_prediction:1 to confirm the prediction.
+- Cross-reference the flagged domain with threat intelligence sources to determine if it is associated with known malicious activity or threat actors.
+- Investigate the source IP address of the DNS request to identify the device or user responsible for the query. This can help determine if the activity is isolated or part of a larger pattern.
+- Analyze network traffic logs for any additional suspicious activity originating from the same source IP, such as unusual outbound connections or data transfers.
+- Check for any recent changes or anomalies in the endpoint's behavior or configuration that could indicate compromise or unauthorized software installation.
+- If the domain is confirmed to be malicious, initiate containment procedures to block further communication with the domain and prevent potential data exfiltration or further compromise.
+
+### False positive analysis
+
+- DNS requests to content delivery networks or cloud service providers can be flagged as DGA domains due to their dynamic nature. Users should review these domains and consider adding them to an exception list if they are verified as legitimate.
+- Internal applications that generate dynamic DNS requests for load balancing or failover purposes might trigger false positives. Identify these applications and exclude their domains from the rule to prevent unnecessary alerts.
+- Automated testing environments often generate numerous DNS requests that can appear suspicious. Regularly update the exception list with domains used by these environments to minimize false alerts.
+- Frequent updates or patches from software vendors may involve dynamic DNS requests. Verify these domains and exclude them if they are confirmed to be part of legitimate update processes.
+- Consider monitoring the frequency and pattern of flagged DNS requests. If a domain is consistently flagged but verified as non-threatening, it may be a candidate for exclusion from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential command and control communication.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and block the identified DGA domain and any associated IP addresses at the network perimeter to prevent further access.
+- Analyze network traffic logs to identify any other systems that may have communicated with the DGA domain and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
+- Implement enhanced monitoring for similar DGA patterns and update detection capabilities to quickly identify future occurrences.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known DGA patterns and suspicious DNS activity."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1568"
+name = "Dynamic Resolution"
+reference = "https://attack.mitre.org/techniques/T1568/"
+[[rule.threat.technique.subtechnique]]
+id = "T1568.002"
+name = "Domain Generation Algorithms"
+reference = "https://attack.mitre.org/techniques/T1568/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

nldcsc_elastic_rules/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml

@@ -0,0 +1,168 @@
+[metadata]
+creation_date = "2024/03/24"
+integration = ["endpoint"]
+maturity = "production"
+promotion = true
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule
+allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend
+memory signature detections only, and does not include prevention alerts.
+"""
+enabled = false
+from = "now-2m"
+index = ["logs-endpoint.alerts-*"]
+interval = "1m"
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 1000
+name = "Memory Threat - Detected - Elastic Defend"
+note = """## Triage and analysis
+
+### Investigating Memory Threat - Detected - Elastic Defend
+
+Elastic Endpoint’s memory threat protection adds a layer of coverage for advanced attacks which avoid the traditional approach of writing payloads to disk. Instead, the malicious code runs only in-memory, an effective technique for evading legacy security products. There are currently two sub-categories of memory threat protection.
+
+The first category is referred to as memory signatures and is available on all supported OS. It operates by periodically scanning process executable memory regions based on their activity to identify and terminate known bad malware.
+
+The second category is referred to as shellcode thread and is unique to Windows endpoints today. A common technique of in-memory malware is to load the payload in a memory region not backed by a file on disk and create a thread to execute it.
+
+
+### Possible investigation steps
+
+- 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.
+- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts :
+   - For shellcode alerts, the key for bucketing alerts is stored in the `Memory_protection.unique_key_v1` field.
+   - For Memory signature alerts, bucket based on the signatures which match `rule.name`.
+- Examine the following fields if there are any matches on known Yara signatures:
+  - `process.Ext.memory_region.malware_signature.all_names`
+  - `Target.process.Ext.memory_region.malware_signature.all_names`
+  - `process.Ext.memory_region.malware_signature.primary.signature.name`
+- Review the memory region strings for any suspicious or unique keywords captured in `process.Ext.memory_region.strings` and `Target.process.Ext.memory_region.strings`.
+- For signature matches review the `process.Ext.memory_region.malware_signature.primary.matches` and `process.Ext.memory_region.malware_signature.secondary.matches` to understand which keywords or byte sequences matched on the memory Yara signature.
+- For shellcode alerts, check the field `Memory_protection.self_injection` value, if it's false it means it's a remote shellcode injection and you need to review the Target process details like `Target.process.executable` fields.
+- Even if the acting process is signed, review any unsigned or suspicious loaded libraries (adversaries may use `DLL Side-Loading`) captured in:
+  - `process.thread.Ext.call_stack.module_path`
+  - `process.Ext.dll.path and process.Ext.dll.hash.sha256`
+  - `Target.process.Ext.dll.hash.sha256`
+  - `Target.process.Ext.dll.path`
+- If you have access to VirusTotal of similar services, you can also perform vGrep searches to look for files with bytes matching on `process.thread.Ext.start_address_bytes` or `Target.process.thread.Ext.start_address_bytes`.
+- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
+
+### False positive analysis
+
+- False positives may include Yara signature matches on generic keywords or some third party softwares performing code injection (often all involved files are signed and by the same vendor).
+
+### Response and Remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
+- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
+   - Contain the affected system by isolating it from the network to prevent further spread of the attack.
+- 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.
+- Remove and block malicious artifacts identified during triage.
+- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
+- 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.
+- 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/elastic/protections-artifacts/tree/main/yara",
+    "https://docs.elastic.co/en/integrations/endpoint",
+]
+risk_score = 73
+rule_id = "017de1e4-ea35-11ee-a417-f661ea17fbce"
+rule_name_override = "message"
+setup = """## Setup
+
+### Elastic Defend Alerts
+This rule is designed to capture specific alerts generated by Elastic Defend.
+
+To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules:
+
+Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce)
+Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce)
+Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce)
+Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce)
+Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce)
+Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce)
+Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce)
+Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce)
+
+To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306).
+
+### Additional notes
+
+For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
+"""
+severity = "high"
+tags = ["Data Source: Elastic Defend", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.kind : alert and event.code : (memory_signature or shellcode_thread) and (event.type : allowed or (event.type: denied and event.outcome: failure))
+'''
+
+
+[[rule.exceptions_list]]
+id = "endpoint_list"
+list_id = "endpoint_list"
+namespace_type = "agnostic"
+type = "endpoint"
+
+[[rule.risk_score_mapping]]
+field = "event.risk_score"
+operator = "equals"
+value = ""
+
+[[rule.severity_mapping]]
+field = "event.severity"
+operator = "equals"
+severity = "low"
+value = "21"
+
+[[rule.severity_mapping]]
+field = "event.severity"
+operator = "equals"
+severity = "medium"
+value = "47"
+
+[[rule.severity_mapping]]
+field = "event.severity"
+operator = "equals"
+severity = "high"
+value = "73"
+
+[[rule.severity_mapping]]
+field = "event.severity"
+operator = "equals"
+severity = "critical"
+value = "99"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1055"
+name = "Process Injection"
+reference = "https://attack.mitre.org/techniques/T1055/"
+
+[[rule.threat.technique]]
+id = "T1620"
+name = "Reflective Code Loading"
+reference = "https://attack.mitre.org/techniques/T1620/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+