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

nldcsc_elastic_rules/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2023/10/26"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/27"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for the elevation of regular user permissions to root permissions through a previously unknown executable.
+Attackers may attempt to evade detection by hijacking the execution flow and hooking certain functions/syscalls through
+a rootkit in order to provide easy access to root via a special modified command.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "UID Elevation from Previously Unknown Executable"
+risk_score = 47
+rule_id = "7787362c-90ff-4b1a-b313-8808b1020e64"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
+the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click Add integrations.
+- In the query bar, search for Elastic Defend and select the integration to see more details about it.
+- Click Add Elastic Defend.
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads.
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click Save and Continue.
+- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+host.os.type:"linux" and event.category:"process" and event.action:"uid_change" and event.type:"change" and user.id:"0"
+and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish") and not (
+  process.executable:(
+    /bin/* or /usr/bin/* or /sbin/* or /usr/sbin/* or /snap/* or /tmp/newroot/* or /var/lib/docker/* or /usr/local/* or
+    /opt/psa/admin/* or /usr/lib/snapd/snap-confine or /opt/dynatrace/* or /opt/microsoft/* or
+    /var/lib/snapd/snap/bin/node or /opt/gitlab/embedded/sbin/logrotate or /etc/apt/universal-hooks/* or
+    /opt/puppetlabs/puppet/bin/puppet or /opt/cisco/* or /run/k3s/containerd/* or /usr/lib/postfix/sbin/master or
+    /usr/libexec/postfix/local or /var/lib/snapd/snap/bin/postgresql* or /opt/puppetlabs/puppet/bin/ruby
+  ) or
+  process.name:(
+    "bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish" or "sudo" or "su" or "apt" or "apt-get" or
+    "aptitude" or "squid" or "snap" or "fusermount" or "pkexec" or "umount" or "master" or "omsbaseline" or "dzdo" or
+    "sandfly" or "logrotate" or "nix-installer" 
+  ) or
+  process.args:/usr/bin/python*
+)
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating UID Elevation from Previously Unknown Executable
+
+In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin.
+- Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity.
+- Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised.
+- Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change".
+- Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation.
+- Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits.
+- If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description.
+
+### False positive analysis
+
+- Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule.
+- Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe.
+- Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity.
+- Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list.
+- Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes.
+- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities.
+- Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt.
+- Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- 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."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1574"
+name = "Hijack Execution Flow"
+reference = "https://attack.mitre.org/techniques/T1574/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1574.013"
+name = "KernelCallbackTable"
+reference = "https://attack.mitre.org/techniques/T1574/013/"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1014"
+name = "Rootkit"
+reference = "https://attack.mitre.org/techniques/T1014/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["process.executable"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"

nldcsc_elastic_rules/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2022/08/30"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges
+or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the
+host and access other resources or escalate privileges.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Namespace Manipulation Using Unshare"
+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 Namespace Manipulation Using Unshare
+
+The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare.
+- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised.
+- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls.
+- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts.
+- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables.
+- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts.
+- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives.
+- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query.
+- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution.
+- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted.
+- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected.
+- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised."""
+references = [
+    "https://man7.org/linux/man-pages/man1/unshare.1.html",
+    "https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/",
+]
+risk_score = 47
+rule_id = "d00f33e7-b57d-4023-9952-2db91b1767c4"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action : ("exec", "exec_event", "start") and
+process.executable: "/usr/bin/unshare" and
+not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and
+not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1543"
+name = "Create or Modify System Process"
+reference = "https://attack.mitre.org/techniques/T1543/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_writable_docker_socket.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2023/07/25"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by
+default are only be writable by the root user and docker group. Attackers that have permissions to write to these
+sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto
+the host file system.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Privilege Escalation through Writable Docker Socket"
+references = [
+    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#automatic-enumeration-and-escape",
+]
+risk_score = 47
+rule_id = "7acb2de3-8465-472a-8d9c-ccd7b73d0ed8"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+  "Domain: Endpoint",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Privilege Escalation",
+  "Domain: Container",
+  "Data Source: Elastic Defend",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and
+(
+  (process.name == "docker" and process.args : "run" and process.args : "-it"  and
+   process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or
+  (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock"))
+) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0"
+'''
+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 Privilege Escalation through Writable Docker Socket
+
+Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (either "docker" or "socat") and the associated arguments that triggered the alert, focusing on the use of "unix://*/docker.sock" or "unix://*/dockershim.sock".
+- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being "0".
+- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised.
+- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities.
+- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts.
+- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access.
+
+### False positive analysis
+
+- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities.
+- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives.
+- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule.
+- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets.
+- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access.
+- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts.
+- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected.
+- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities.
+- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/macos/command_and_control_unusual_connection_to_suspicious_top_level_domain.toml

@@ -0,0 +1,104 @@
+[metadata]
+creation_date = "2025/03/25"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/04/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the unusual occurrence of outbound network connections to suspicious top level domains. 
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.network-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Unusual Network Connection to Suspicious Top Level Domain"
+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 Unusual Network Connection to Suspicious Top Level Domain
+
+In macOS environments, network connections are essential for communication and data exchange. Adversaries exploit this by connecting to suspicious top-level domains (TLDs) for command and control activities. The detection rule identifies unusual outbound connections to these TLDs, signaling potential threats. By monitoring specific domains, it helps detect and mitigate malicious activities early.
+
+### Possible investigation steps
+
+- Review the destination domain involved in the alert to determine if it is associated with known malicious activities or if it has been flagged in threat intelligence databases.
+- Analyze the network traffic details related to the connection, including the source IP address and the volume of data transferred, to assess the nature and intent of the communication.
+- Check the host system's recent activity logs for any unusual processes or applications that initiated the network connection, focusing on the event.type "start" to identify the triggering process.
+- Investigate the user account associated with the host to determine if there have been any unauthorized access attempts or anomalies in user behavior.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify potential patterns or coordinated activities.
+- Consult with threat intelligence sources or security forums to gather additional context on the specific top-level domain and its potential use in command and control operations.
+
+### False positive analysis
+
+- Legitimate business domains may use TLDs like .online or .store for marketing purposes. Review the domain's reputation and business context before marking it as a threat.
+- Personal or small business websites might use TLDs such as .fun or .life. Verify the domain ownership and usage to determine if it is a false positive.
+- Some educational or community projects might use TLDs like .club or .space. Check the domain's content and purpose to assess its legitimacy.
+- Exclude known safe domains by adding them to an allowlist in your monitoring tool to prevent repeated false positives.
+- Regularly update the allowlist based on user feedback and network behavior analysis to ensure it remains accurate and effective.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domain.
+- Conduct a thorough review of the network logs to identify any additional devices that may have communicated with the same suspicious domains and isolate them if necessary.
+- Use endpoint security tools to perform a full malware scan on the affected device to identify and remove any malicious software.
+- Reset credentials and review access permissions for any accounts that were active on the affected device to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement network-level blocking of the identified suspicious domains to prevent future connections from any device within the network.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to enhance detection and blocking of similar threats in the future.
+"""
+risk_score = 47
+rule_id = "ffa676dc-09b0-11f0-94ba-b66272739ecb"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category : "network" and host.os.type : "macos" and event.type : "start" and
+destination.domain : (*.team or *.lol or *.kr or *.ke or *.nu or *.space or 
+                          *.capital or *.in or *.cfd or *.online or *.ru or 
+                          *.info or *.top or *.buzz or *.xyz or *.rest or 
+                          *.ml or *.cf or *.gq or *.ga or *.onion or 
+                          *.network or *.monster or *.marketing or *.cyou or 
+                          *.quest or *.cc or *.bar or *.click or *.cam or 
+                          *.surf or *.tk or *.shop or *.club or *.icu or 
+                          *.pw or *.ws or *.hair or *.mom or 
+                          *.beauty or *.boats or *.fun or *.life or 
+                          *.store)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1071"
+name = "Application Layer Protocol"
+reference = "https://attack.mitre.org/techniques/T1071/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1071.001"
+name = "Web Protocols"
+reference = "https://attack.mitre.org/techniques/T1071/001/"
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["host.id", "process.executable", "destination.domain"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"