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

nldcsc_elastic_rules/rules/cross-platform/initial_access_azure_o365_with_network_alert.toml

@@ -0,0 +1,137 @@
+[metadata]
+creation_date = "2025/04/29"
+integration = ["azure", "o365"]
+maturity = "production"
+updated_date = "2025/07/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule correlate Azure or Office 356 mail successful sign-in events with network security alerts by source.ip.
+Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud
+resources.
+"""
+false_positives = [
+    """
+    Custom network security rules that triggers on a proxy or gateway used by users to access Azure or O365.
+    """,
+]
+from = "now-60m"
+language = "esql"
+license = "Elastic License v2"
+name = "Microsoft 365 or Entra ID Sign-in from a Suspicious Source"
+note = """## Triage and analysis
+
+### Investigating Microsoft 365 or Entra ID Sign-in from a Suspicious Source
+
+#### Possible investigation steps
+
+- Investiguate all the alerts associated with the source.ip.
+  - Verify the network security alert details associated with this source.ip.
+  - Verify all sign-in events associated with this source.ip.
+  - Consider the source IP address and geolocation for the involved user account.
+  - Consider the device used to sign in. Is it registered and compliant?
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Check if this operation was approved and performed according to the organization's change management policy.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Disable or limit the account during the investigation and response.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Assess the criticality of affected services and servers.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
+- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
+- Consider enabling multi-factor authentication for users.
+- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via 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).
+
+## Setup
+
+The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+risk_score = 73
+rule_id = "f0cc239b-67fa-46fc-89d4-f861753a40f5"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Domain: SaaS",
+    "Data Source: Azure",
+    "Data Source: Entra ID",
+    "Data Source: Entra ID Sign-in Logs",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+    "Rule Type: Higher-Order Rule",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.*
+// query runs every 1 hour looking for activities occurred during last 8 hours to match on disparate events
+| where @timestamp > now() - 8 hours
+// filter for azure or m365 sign-in and external alerts with source.ip not null
+| where to_ip(source.ip) is not null
+  and (event.dataset in ("o365.audit", "azure.signinlogs") or kibana.alert.rule.name == "External Alerts")
+  and not cidr_match(
+    to_ip(source.ip),
+    "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+    "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+    "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4",
+    "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24",
+    "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8"
+  )
+
+// capture relevant raw fields
+| keep source.ip, event.action, event.outcome, event.dataset, kibana.alert.rule.name, event.category
+
+// classify each source ip based on alert type
+| eval
+  Esql.source_ip_mail_access_case = case(event.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip), null),
+  Esql.source_ip_azure_signin_case = case(event.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip), null),
+  Esql.source_ip_network_alert_case = case(kibana.alert.rule.name == "external alerts" and not event.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip), null)
+
+// aggregate by source ip
+| stats
+    Esql.event_count = count(*),
+    Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case),
+    Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case),
+    Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case),
+    Esql.event_dataset_count_distinct = count_distinct(event.dataset),
+    Esql.event_dataset_values = values(event.dataset),
+    Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),
+    Esql.event_category_values = values(event.category)
+  by Esql.source_ip = to_ip(source.ip)
+
+// correlation condition
+| where
+  Esql.source_ip_network_alert_case_count_distinct > 0
+  and Esql.event_dataset_count_distinct >= 2
+  and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0)
+  and Esql.event_count <= 100
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/cross-platform/initial_access_exfiltration_new_usb_device_mounted.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2025/11/11"
+integration = ["endpoint"]
+maturity = "production"
+min_stack_comments = "Device mount events were added as part of the Elastic Defend Device Control feature."
+min_stack_version = "9.2.0"
+updated_date = "2025/11/11"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies newly seen removable devices by device.serial_number and host.id using the Elastic Defend device mount events. While this activity
+is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.device-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "New USB Storage Device Mounted"
+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 New USB Storage Device Mounted
+
+Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts.
+
+This detection uses Elastic Defend device control events, Device control helps protect your Windows and Mac endpoints from data loss, malware, and unauthorized access by managing which devices can connect to your computers. Specifically, it restricts which external USB storage devices can connect to hosts that have Elastic Defend installed.
+
+
+### Possible investigation steps
+
+- Review the device mount event details to confirm the presence of a new device by checking the device.serial_number.
+- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration.
+- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere.
+- Analyze any related alerts or logs for additional context or suspicious activities linked to the device.
+
+### False positive analysis
+
+- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system.
+- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts.
+- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts.
+- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives.
+- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware.
+- Block the device by serial number using the relevant Elastic Defend Device Control policy.
+- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device.
+- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action.
+- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats.
+- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated.
+- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections."""
+references = [
+"https://www.elastic.co/docs/solutions/security/manage-elastic-defend/trusted-devices", 
+"https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-an-integration-policy-for-elastic-defend#device-control"
+]
+risk_score = 21
+rule_id = "483832a8-ffdd-4e11-8e96-e0224f7bda9b"
+severity = "low"
+tags = [
+    "Domain: Endpoint", 
+    "OS: Windows",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Use Case: Device Control",
+    "Tactic: Initial Access",
+    "Tactic: Exfiltration",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+host.os.type:(macos or windows) and event.type:device and event.action:mount and event.outcome:success and volume.removable:true
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1091"
+name = "Replication Through Removable Media"
+reference = "https://attack.mitre.org/techniques/T1091/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1052"
+name = "Exfiltration Over Physical Medium"
+reference = "https://attack.mitre.org/techniques/T1052/"
+[[rule.threat.technique.subtechnique]]
+id = "T1052.001"
+name = "Exfiltration over USB"
+reference = "https://attack.mitre.org/techniques/T1052/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["device.serial_number", "host.id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"

nldcsc_elastic_rules/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml

@@ -0,0 +1,85 @@
+[metadata]
+creation_date = "2020/09/14"
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies Zoom meetings that are created without a passcode. Meetings without a passcode are susceptible to
+Zoombombing. Zoombombing is carried out by taking advantage of Zoom sessions that are not protected with a passcode.
+Zoombombing refers to the unwanted, disruptive intrusion, generally by Internet trolls and hackers, into a video
+conference call. In a typical Zoombombing incident, a teleconferencing session is hijacked by the insertion of material
+that is lewd, obscene, racist, or antisemitic in nature, typically resulting of the shutdown of the session.
+"""
+index = ["filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Zoom Meeting with no Passcode"
+references = [
+    "https://blog.zoom.us/a-message-to-our-users/",
+    "https://www.fbi.gov/contact-us/field-offices/boston/news/press-releases/fbi-warns-of-teleconferencing-and-online-classroom-hijacking-during-covid-19-pandemic",
+]
+risk_score = 47
+rule_id = "58ac2aa5-6718-427c-a845-5f3ac5af00ba"
+setup = """## Setup
+
+The Zoom Filebeat module or similarly structured data is required to be compatible with this rule."""
+severity = "medium"
+tags = ["Data Source: Zoom", "Use Case: Configuration Audit", "Tactic: Initial Access", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.type:creation and event.module:zoom and event.dataset:zoom.webhook and
+  event.action:meeting.created and not zoom.meeting.password:*
+'''
+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 Zoom Meeting with no Passcode
+
+Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by joining unsecured meetings to cause chaos or gather sensitive information. The detection rule identifies such meetings by monitoring Zoom event logs for sessions created without a passcode, helping to mitigate potential security breaches.
+
+### Possible investigation steps
+
+- Review the Zoom event logs to identify the specific meeting details, including the meeting ID and the organizer's information, using the fields event.type, event.module, event.dataset, and event.action.
+- Contact the meeting organizer to verify if the meeting was intentionally created without a passcode and understand the context or purpose of the meeting.
+- Check for any unusual or unauthorized participants who joined the meeting by examining the participant logs associated with the meeting ID.
+- Assess if any sensitive information was discussed or shared during the meeting that could have been exposed to unauthorized participants.
+- Evaluate the need to implement additional security measures, such as enabling passcodes for all future meetings or using waiting rooms to control participant access.
+
+### False positive analysis
+
+- Internal team meetings may be scheduled without a passcode for convenience, especially if all participants are within a secure network. To handle this, create exceptions for meetings initiated by trusted internal users or within specific IP ranges.
+- Recurring meetings with a consistent group of participants might not use passcodes to simplify access. Consider excluding these meetings by identifying and whitelisting their unique meeting IDs.
+- Training sessions or webinars intended for a broad audience might be set up without passcodes to ease access. Implement a policy to review and approve such meetings in advance, ensuring they are legitimate and necessary.
+- Meetings created by automated systems or bots for integration purposes may not require passcodes. Identify these systems and exclude their meeting creation events from triggering alerts.
+- In some cases, meetings may be intentionally left without passcodes for public access, such as community events. Establish a process to verify and document these events, allowing them to be excluded from the rule.
+
+### Response and remediation
+
+- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption.
+- Notify the meeting host and relevant stakeholders about the security incident, advising them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room.
+- Review and update Zoom account settings to enforce mandatory passcodes for all future meetings, ensuring compliance with security policies.
+- Conduct a security audit of recent Zoom meetings to identify any other sessions that may have been created without a passcode and take corrective actions as necessary.
+- Escalate the incident to the IT security team for further investigation and to assess any potential data breaches or information leaks resulting from the unauthorized access.
+- Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes.
+- Coordinate with the communications team to prepare a response plan for any potential public relations issues arising from the incident, ensuring clear and consistent messaging."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1190"
+name = "Exploit Public-Facing Application"
+reference = "https://attack.mitre.org/techniques/T1190/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_different_tactics_host.toml

@@ -0,0 +1,79 @@
+[metadata]
+creation_date = "2022/11/16"
+maturity = "production"
+updated_date = "2025/06/27"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are
+triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.
+"""
+false_positives = [
+    """
+    False positives can occur because the rules may be mapped to a few MITRE ATT&CK tactics. Use the attached Timeline
+    to determine which detections were triggered on the host.
+    """,
+]
+from = "now-24h"
+index = [".alerts-security.*"]
+interval = "1h"
+language = "kuery"
+license = "Elastic License v2"
+name = "Multiple Alerts in Different ATT&CK Tactics on a Single Host"
+risk_score = 73
+rule_id = "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*
+'''
+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 Multiple Alerts in Different ATT&CK Tactics on a Single Host
+
+The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
+
+
+
+[rule.threshold]
+field = ["host.id", "host.name"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "kibana.alert.rule.threat.tactic.id"
+value = 3
+
+

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_edr_elastic_defend_by_host.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2025/11/19"
+maturity = "production"
+updated_date = "2025/11/19"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered.
+Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.
+"""
+from = "now-60m"
+interval = "30m"
+language = "esql"
+license = "Elastic License v2"
+name = "Multiple Elastic Defend Alerts by Agent"
+risk_score = 73
+rule_id = "ab25369e-ea5e-46f1-9cd5-478a0a4a131a"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Data Source: Elastic Defend"]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-endpoint.alerts-* metadata _id
+| eval target_time_window = DATE_TRUNC(24 hours, @timestamp)
+| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
+        agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_code_distinct_count = count_distinct(event.code),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
+        Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
+        Esql.process_name_distinct_count = COUNT_DISTINCT(process.entity_id),
+        Esql.event_code_values = VALUES(event.code),
+        Esql.rule_name_values = VALUES(rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.dll_path_values = VALUES(dll.path),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_parent_executable_values = VALUES(process.parent.executable),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_hash_sha256_values = VALUES(process.hash.sha256),
+        Esql.file_hash_sha256_values = VALUES(file.hash.sha256),
+        Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256) by agent.id
+| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)
+| keep agent.id,
+       Esql.alerts_count,
+       Esql.event_code_distinct_count,
+       Esql.rule_name_distinct_count,
+       Esql.message_values,
+       Esql.event_code_values,
+       Esql.rule_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values,
+       Esql.file_path_values,
+       Esql.dll_path_values,
+       Esql.process_hash_sha256_values,
+       Esql.file_hash_sha256_values,
+       Esql.dll_hash_sha256_values
+'''
+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 Multiple Elastic Defend Alerts by Agent
+
+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 host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
+references = ["https://github.com/elastic/protections-artifacts/tree/main/yara/rules"]

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_elastic_defend_netsecurity_by_host.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2025/11/18"
+integration = ["endpoint", "panw", "fortinet_fortigate", "suricata"]
+maturity = "production"
+updated_date = "2025/11/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto
+Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and
+triggering multi-datasource alerts.
+"""
+from = "now-60m"
+interval = "10m"
+language = "esql"
+license = "Elastic License v2"
+name = "Elastic Defend and Network Security Alerts Correlation"
+risk_score = 73
+rule_id = "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe"
+severity = "high"
+tags = [
+    "Use Case: Threat Detection",
+    "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+    "Data Source: Fortinet",
+    "Data Source: PAN-OS"
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+FROM logs-* metadata _id
+| WHERE
+        // Elastic Defend Alerts
+        (event.module == "endpoint" and event.dataset == "endpoint.alerts") or
+
+        // PANW suspicious events
+        (event.dataset == "panw.panos" and
+         event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or
+
+        // Fortigate suspicious events
+        (event.dataset == "fortinet_fortigate.log" and
+         (event.action in ("outbreak-prevention", "deny", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or
+
+        // Suricata
+        (event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected"))
+
+// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert
+|eval fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
+      elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
+| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
+| where Esql.source_ip is not null
+
+// group by host_source_ip shared between FG/PANW and Elastic Defend
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.message_values = VALUES(message),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.destination_ip_values = VALUES(destination.ip)
+        by Esql.source_ip
+| where Esql.event_module_distinct_count >= 2
+| keep Esql.alerts_count, Esql.source_ip, Esql.destination_ip_values, Esql.host_id_values, Esql.user_name_values, Esql.event_module_values, Esql.message_values, Esql.process_executable_values
+'''
+note = """## Triage and analysis
+
+### Investigating Elastic Defend and Network Security Alerts Correlation
+
+This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and users involved.
+- Investiguate the network alerts by destination.ip and message.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+
+- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert.
+- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
+
+
+