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

nldcsc_elastic_rules/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2020/09/03"
+integration = ["auditd_manager", "endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc
+software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run
+exploits or malware activity.
+"""
+false_positives = [
+    """
+    Uncommon compiler activity can be due to an engineer running a local build on a production or staging instance in
+    the course of troubleshooting or fixing a software issue.
+    """,
+]
+from = "now-45m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = ["v3_linux_rare_user_compiler"]
+name = "Anomalous Linux Compiler Activity"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Auditd Manager
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 to your 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/current/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).
+
+### Auditd Manager Integration Setup
+The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
+Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
+- Click “Add Auditd Manager”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
+
+#### Rule Specific Setup Note
+Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
+However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+- For this detection rule no additional audit rules are required.
+"""
+risk_score = 21
+rule_id = "cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Resource Development",
+    "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 Anomalous Linux Compiler Activity
+
+Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations.
+
+### Possible investigation steps
+
+- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers.
+- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization.
+- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns.
+- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications.
+- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage.
+- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts.
+- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal.
+- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training.
+- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules.
+- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations.
+- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts.
+- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise.
+- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise.
+- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1588"
+name = "Obtain Capabilities"
+reference = "https://attack.mitre.org/techniques/T1588/"
+[[rule.threat.technique.subtechnique]]
+id = "T1588.001"
+name = "Malware"
+reference = "https://attack.mitre.org/techniques/T1588/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0042"
+name = "Resource Development"
+reference = "https://attack.mitre.org/tactics/TA0042/"
+

nldcsc_elastic_rules/rules/network/command_and_control_accepted_default_telnet_port_connection.toml

@@ -0,0 +1,121 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system
+administrators to remotely control older or embedded systems using the command line shell. It should almost never be
+directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or
+backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the
+traffic.
+"""
+false_positives = [
+    """
+    IoT (Internet of Things) devices and networks may use telnet and can be excluded if desired. Some business
+    work-flows may use Telnet for administration of older devices. These often have a predictable behavior. Telnet
+    activity involving an unusual source or destination may be more suspicious. Telnet activity involving a production
+    server that has no known associated Telnet work-flow or business requirement is often suspicious.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Accepted Default Telnet Port Connection"
+risk_score = 47
+rule_id = "34fde489-94b0-4500-a76f-b8a157cf9269"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "Use Case: Threat Detection",
+    "Tactic: Command and Control",
+    "Tactic: Lateral Movement",
+    "Tactic: Initial Access",
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
+]
+timeline_id = "300afc76-072d-4261-864d-4149714bf3f1"
+timeline_title = "Comprehensive Network Timeline"
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset:network_traffic.flow or event.category:(network or network_traffic))
+    and event.type:connection and not event.action:(
+        flow_dropped or flow_denied or denied or deny or
+        flow_terminated or timeout or Reject or network_flow)
+    and destination.port:23
+'''
+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 Accepted Default Telnet Port Connection
+
+Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization.
+- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes.
+- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack.
+- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access.
+- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers.
+- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access.
+- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts.
+
+### False positive analysis
+
+- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems.
+- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts.
+- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise.
+- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred.
+- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges.
+- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet.
+- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1021"
+name = "Remote Services"
+reference = "https://attack.mitre.org/techniques/T1021/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+[[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/network/command_and_control_cobalt_strike_beacon.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2020/07/06"
+integration = ["network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and
+exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for
+command and control.
+"""
+false_positives = [
+    """
+    This rule should be tailored to either exclude systems, as sources or destinations, in which this behavior is
+    expected.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
+language = "lucene"
+license = "Elastic License v2"
+name = "Cobalt Strike Command and Control Beacon"
+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 Cobalt Strike Command and Control Beacon
+
+Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\\..* to determine if it matches known malicious domains.
+- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication.
+- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases.
+- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack.
+- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise.
+- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts.
+- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule.
+- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity.
+- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques.
+- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed.
+- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools.
+- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access.
+- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.
+- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks.
+
+## Threat intel
+
+This activity has been observed in FIN7 campaigns."""
+references = [
+    "https://blog.morphisec.com/fin7-attacks-restaurant-industry",
+    "https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html",
+    "https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack",
+]
+risk_score = 73
+rule_id = "cf53f532-9cc9-445a-9ae7-fced307ec53c"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+((event.category: (network OR network_traffic) AND type: (tls OR http))
+    OR event.dataset: (network_traffic.tls OR network_traffic.http)
+) AND destination.domain:/[a-z]{3}.stage.[0-9]{8}\..*/
+'''
+
+
+[[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]]
+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/network/command_and_control_cobalt_strike_default_teamserver_cert.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2020/10/05"
+integration = ["network_traffic"]
+maturity = "production"
+updated_date = "2025/04/22"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the use of the default Cobalt Strike Team Server TLS certificate. Cobalt Strike is software for
+Adversary Simulations and Red Team Operations which are security assessments that replicate the tactics and techniques
+of an advanced adversary in a network. Modifications to the Packetbeat configuration can be made to include MD5 and
+SHA256 hashing algorithms (the default is SHA1). See the References section for additional information on module
+configuration.
+"""
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Default Cobalt Strike Team Server Certificate"
+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 Default Cobalt Strike Team Server Certificate
+
+Cobalt Strike is a tool used for simulating advanced cyber threats, often employed by security teams to test defenses. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized Cobalt Strike activity.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any connections associated with the specific cryptographic hashes: MD5 (950098276A495286EB2A2556FBAB6D83), SHA1 (6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C), or SHA256 (87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C).
+- Identify the source and destination IP addresses involved in the flagged network traffic to determine the potential origin and target of the Cobalt Strike activity.
+- Correlate the identified IP addresses with known assets in the network to assess if any internal systems are potentially compromised.
+- Check for any other suspicious or anomalous network activities around the same time as the alert to identify potential lateral movement or additional command and control channels.
+- Investigate any associated processes or user accounts on the involved systems to determine if there are signs of compromise or unauthorized access.
+- Review historical data to see if there have been previous alerts or similar activities involving the same cryptographic hashes or IP addresses, which might indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate security testing activities by internal teams using Cobalt Strike may trigger the rule. Coordinate with security teams to whitelist known testing IP addresses or certificate hashes.
+- Some commercial penetration testing services may use Cobalt Strike with default certificates. Verify the legitimacy of such services and exclude their traffic from detection by adding their certificate hashes to an exception list.
+- Network appliances or security tools that simulate adversary behavior for training purposes might use similar certificates. Identify these tools and configure exceptions for their specific network traffic patterns.
+- In environments where Cobalt Strike is used for authorized red team exercises, ensure that the default certificate is replaced with a custom one to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with the potential Cobalt Strike server.
+- Conduct a thorough forensic analysis of the isolated system to identify any malicious payloads or additional indicators of compromise.
+- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access.
+- Update and patch all systems to the latest security standards to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement network segmentation to limit the lateral movement of threats within the network.
+- Enhance monitoring and logging to capture detailed network traffic and endpoint activity, focusing on the identified cryptographic hashes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with external threat intelligence sources if necessary.
+
+## Threat intel
+
+While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly."""
+references = [
+    "https://attack.mitre.org/software/S0154/",
+    "https://www.cobaltstrike.com/help-setup-collaboration",
+    "https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html",
+    "https://www.elastic.co/guide/en/beats/filebeat/7.9/filebeat-module-suricata.html",
+    "https://www.elastic.co/guide/en/beats/filebeat/7.9/filebeat-module-zeek.html",
+    "https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack",
+]
+risk_score = 73
+rule_id = "e7075e8d-a966-458e-a183-85cd331af255"
+severity = "high"
+tags = [
+    "Tactic: Command and Control",
+    "Threat: Cobalt Strike",
+    "Use Case: Threat Detection",
+    "Domain: Endpoint",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.tls or event.category: (network or network_traffic))
+  and (tls.server.hash.md5:950098276A495286EB2A2556FBAB6D83
+  or tls.server.hash.sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C
+  or tls.server.hash.sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C)
+'''
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/network/command_and_control_download_rar_powershell_from_internet.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2020/07/02"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects a Roshal Archive (RAR) file or PowerShell script downloaded from the internet by an internal host. Gaining
+initial access to a system and then downloading encoded or encrypted tools to move laterally is a common practice for
+adversaries as a way to protect their more valuable tools and tactics, techniques, and procedures (TTPs). This may be
+atypical behavior for a managed network and can be indicative of malware, exfiltration, or command and control.
+"""
+false_positives = [
+    """
+    Downloading RAR or PowerShell files from the Internet may be expected for certain systems. This rule should be
+    tailored to either exclude systems as sources or destinations in which this behavior is expected.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet"
+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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet
+
+RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
+- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization.
+- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user.
+- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise.
+- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions.
+- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats.
+
+### False positive analysis
+
+- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses.
+- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule.
+- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives.
+- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts.
+- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration.
+- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts.
+- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise.
+- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host.
+- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question.
+- Implement network segmentation to limit the ability of threats to move laterally within the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts.
+
+## Threat intel
+
+This activity has been observed in FIN7 campaigns."""
+references = [
+    "https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html",
+    "https://www.justice.gov/opa/press-release/file/1084361/download",
+    "https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml",
+]
+risk_score = 47
+rule_id = "ff013cb4-274d-434a-96bb-fe15ddd3ae92"
+severity = "medium"
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: (network_traffic.http or network_traffic.tls) or
+  (event.category: (network or network_traffic) and network.protocol: http)) and
+  (url.extension:(ps1 or rar) or url.path:(*.ps1 or *.rar)) and
+    not destination.ip:(
+      10.0.0.0/8 or
+      127.0.0.0/8 or
+      169.254.0.0/16 or
+      172.16.0.0/12 or
+      192.0.0.0/24 or
+      192.0.0.0/29 or
+      192.0.0.8/32 or
+      192.0.0.9/32 or
+      192.0.0.10/32 or
+      192.0.0.170/32 or
+      192.0.0.171/32 or
+      192.0.2.0/24 or
+      192.31.196.0/24 or
+      192.52.193.0/24 or
+      192.168.0.0/16 or
+      192.88.99.0/24 or
+      224.0.0.0/4 or
+      100.64.0.0/10 or
+      192.175.48.0/24 or
+      198.18.0.0/15 or
+      198.51.100.0/24 or
+      203.0.113.0/24 or
+      240.0.0.0/4 or
+      "::1" or
+      "FE80::/10" or
+      "FF00::/8"
+    ) and
+    source.ip:(
+      10.0.0.0/8 or
+      172.16.0.0/12 or
+      192.168.0.0/16
+    )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1105"
+name = "Ingress Tool Transfer"
+reference = "https://attack.mitre.org/techniques/T1105/"
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+