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

nldcsc_elastic_rules/rules/network/command_and_control_fin7_c2_behavior.toml

@@ -0,0 +1,66 @@
+[metadata]
+creation_date = "2020/07/06"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this
+command and control technique, while maintaining persistence in their target's network.
+"""
+false_positives = [
+    """
+    This rule could identify benign domains that are formatted similarly to FIN7's command and control algorithm. Alerts
+    should be investigated by an analyst to assess the validity of the individual observations.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "lucene"
+license = "Elastic License v2"
+name = "Possible FIN7 DGA Command and Control Behavior"
+note = """## Triage and analysis
+
+In the event this rule identifies benign domains in your environment, the `destination.domain` field in the rule can be modified to include those domains. Example: `...AND NOT destination.domain:(zoom.us OR benign.domain1 OR benign.domain2)`."""
+references = [
+    "https://www.fireeye.com/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html",
+]
+risk_score = 73
+rule_id = "4a4e23cf-78a2-449c-bac3-701924c269d3"
+severity = "high"
+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.tls OR network_traffic.http) OR
+    (event.category: (network OR network_traffic) AND type: (tls OR http) AND network.transport: tcp)) AND
+destination.domain:/[a-zA-Z]{4,5}\.(pw|us|club|info|site|top)/ AND NOT destination.domain:zoom.us
+'''
+
+
+[[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_halfbaked_beacon.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2020/07/06"
+integration = ["network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity
+algorithm leveraged by Halfbaked implant beacons for command and control.
+"""
+false_positives = [
+    """
+    This rule should be tailored to exclude systems, either 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 = "Halfbaked 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 Halfbaked Command and Control Beacon
+
+Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious.
+- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse.
+- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity.
+- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic.
+- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names.
+- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names.
+- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list.
+- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges.
+- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses.
+
+### Response and remediation
+
+- Isolate the affected systems from the network immediately to prevent further communication with the command and control server.
+- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware.
+- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures.
+- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts.
+- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware.
+- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach.
+
+## 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://attack.mitre.org/software/S0151/",
+]
+risk_score = 73
+rule_id = "2e580225-2a58-48ef-938b-572933be06fe"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: (network_traffic.tls OR network_traffic.http) OR
+  (event.category: (network OR network_traffic) AND network.protocol: http)) AND
+  network.transport:tcp AND url.full:/http:\/\/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}\/cd/ AND
+  destination.port:(53 OR 80 OR 8080 OR 443)
+'''
+
+
+[[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_nat_traversal_port_activity.toml

@@ -0,0 +1,82 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects events that could be describing IPSEC NAT Traversal traffic. IPSEC is a VPN technology that allows one
+system to talk to another using encrypted tunnels. NAT Traversal enables these tunnels to communicate over the Internet
+where one of the sides is behind a NAT router gateway. This may be common on your network, but this technique is also
+used by threat actors to avoid detection.
+"""
+false_positives = [
+    """
+    Some networks may utilize these protocols but usage that is unfamiliar to local network administrators can be
+    unexpected and suspicious. Because this port is in the ephemeral range, this rule may false under certain
+    conditions, such as when an application server with a public IP address replies to a client which has used a UDP
+    port in the range by coincidence. This is uncommon but such servers can be excluded.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "IPSEC NAT Traversal Port Activity"
+risk_score = 21
+rule_id = "a9cb3641-ff4b-4cdc-a063-b4b8d02a67c7"
+severity = "low"
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500
+'''
+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 IPSEC NAT Traversal Port Activity
+
+IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities, bypassing network defenses. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment.
+- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous.
+- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses.
+- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities.
+- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern.
+- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure.
+
+### False positive analysis
+
+- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives.
+- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts.
+- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening.
+- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy.
+- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement.
+- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500.
+- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500.
+- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

nldcsc_elastic_rules/rules/network/command_and_control_port_26_activity.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects events that may indicate use of SMTP on TCP port 26. This port is commonly used by several popular
+mail transfer agents to deconflict with the default SMTP port 25. This port has also been used by a malware family
+called BadPatch for command and control of Windows systems.
+"""
+false_positives = [
+    """
+    Servers that process email traffic may cause false positives and should be excluded from this rule as this is
+    expected behavior.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "SMTP on Port 26/TCP"
+references = [
+    "https://unit42.paloaltonetworks.com/unit42-badpatch/",
+    "https://isc.sans.edu/forums/diary/Next+up+whats+up+with+TCP+port+26/25564/",
+]
+risk_score = 21
+rule_id = "d7e62693-aab9-4f66-a21a-3d79ecdd603d"
+severity = "low"
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26
+'''
+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 SMTP on Port 26/TCP
+
+SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious SMTP activity on port 26 by analyzing network traffic patterns, helping to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any unusual patterns or anomalies associated with TCP port 26, focusing on the event.dataset fields such as network_traffic.flow or zeek.smtp.
+- Analyze the source and destination IP addresses involved in the alert to determine if they are known or associated with any previous suspicious activities.
+- Check for any additional alerts or logs related to the same source or destination IP addresses to identify potential patterns or repeated attempts of communication on port 26.
+- Investigate the context of the communication by examining the payload data, if available, to identify any indicators of compromise or malicious content.
+- Correlate the findings with threat intelligence sources to determine if the IP addresses or domains are associated with known threat actors or malware, such as BadPatch.
+- Assess the risk and impact on the affected systems by determining if any sensitive data or critical systems are involved in the communication on port 26.
+
+### False positive analysis
+
+- Legitimate mail transfer agents may use port 26 to avoid conflicts with port 25. Identify these agents and create exceptions in the detection rule to prevent unnecessary alerts.
+- Some network configurations might reroute SMTP traffic to port 26 for load balancing or security reasons. Verify these configurations and whitelist known IP addresses or domains to reduce false positives.
+- Internal testing or development environments might use port 26 for non-malicious purposes. Document these environments and exclude their traffic from triggering alerts.
+- Certain email service providers may use port 26 as an alternative to port 25. Confirm these providers and adjust the rule to recognize their traffic as benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command and control communication via port 26.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove the BadPatch malware or any other malicious software.
+- Review and analyze network logs to identify any other systems that may have communicated with the same command and control server, and isolate those systems as well.
+- Change all passwords and credentials that may have been compromised or accessed by the affected system to prevent unauthorized access.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation by similar threats.
+- Monitor network traffic for any further suspicious activity on port 26 and other non-standard ports, adjusting firewall rules to block unauthorized SMTP traffic.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to ensure comprehensive threat eradication."""
+
+
+[[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 = "T1048"
+name = "Exfiltration Over Alternative Protocol"
+reference = "https://attack.mitre.org/techniques/T1048/"
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+

nldcsc_elastic_rules/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml

@@ -0,0 +1,144 @@
+[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 RDP traffic from the Internet. RDP is commonly used by
+system administrators to remotely control a system for maintenance or to use shared resources. 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.
+"""
+false_positives = [
+    """
+    Some network security policies allow RDP directly from the Internet but usage that is unfamiliar to server or
+    network owners can be unexpected and suspicious. RDP services may be exposed directly to the Internet in some
+    networks such as cloud environments. In such cases, only RDP gateways, bastions or jump servers may be expected
+    expose RDP directly to the Internet and can be exempted from this rule. RDP may be required by some work-flows such
+    as remote access and support for specialized software products and servers. Such work-flows are usually known and
+    not unexpected.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "RDP (Remote Desktop Protocol) from the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 47
+rule_id = "8c1bdde8-4204-45c0-9e0c-c85ca3902488"
+severity = "medium"
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "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
+  network.transport:tcp and (destination.port:3389 or event.dataset:zeek.rdp) and
+  not source.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
+  destination.ip:(
+    10.0.0.0/8 or
+    172.16.0.0/12 or
+    192.168.0.0/16
+  )
+'''
+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 RDP (Remote Desktop Protocol) from the Internet
+
+RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior.
+- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection.
+- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access.
+- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet.
+- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation.
+- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network.
+
+### False positive analysis
+
+- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows.
+- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule.
+- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources.
+- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections.
+- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor.
+- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities.
+- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access.
+- 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.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_vnc_virtual_network_computing_from_the_internet.toml

@@ -0,0 +1,133 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects network events that may indicate the use of VNC traffic from the Internet. VNC is commonly used by
+system administrators to remotely control a system for maintenance or to use shared resources. 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.
+"""
+false_positives = [
+    """
+    VNC connections may be received directly to Linux cloud server instances but such connections are usually made only
+    by engineers. VNC is less common than SSH or RDP but may be required by some work-flows such as remote access and
+    support for specialized software products or servers. Such work-flows are usually known and not unexpected. Usage
+    that is unfamiliar to server or network owners can be unexpected and suspicious.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "VNC (Virtual Network Computing) from the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 73
+rule_id = "5700cb81-df44-46aa-a5d7-337798f53eb8"
+severity = "high"
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and
+  network.transport:tcp and destination.port >= 5800 and destination.port <= 5810 and
+  not source.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
+  destination.ip:(
+    10.0.0.0/8 or
+    172.16.0.0/12 or
+    192.168.0.0/16
+  )
+'''
+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 VNC (Virtual Network Computing) from the Internet
+
+VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out trusted IP ranges, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address of the alert to determine if it is from an untrusted or suspicious location, as the rule filters out known trusted IP ranges.
+- Check the destination IP address to confirm it belongs to an internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and verify if the system is authorized to receive VNC traffic.
+- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or repeated access attempts that could indicate malicious activity.
+- Investigate the context of the event by correlating it with other security alerts or logs to determine if there are signs of a broader attack or compromise.
+- Assess the risk and impact of the potential threat by evaluating the criticality of the affected system and any sensitive data it may contain.
+
+### False positive analysis
+
+- Internal testing or maintenance activities may trigger the rule if VNC is used for legitimate purposes within a controlled environment. To manage this, create exceptions for known internal IP addresses that frequently use VNC for authorized tasks.
+- Automated systems or scripts that utilize VNC for routine operations might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent unnecessary alerts.
+- Remote workers using VPNs that route traffic through public IPs could be mistakenly identified as threats. Ensure that VPN IP ranges are included in the trusted IP list to avoid false positives.
+- Misconfigured network devices that inadvertently expose VNC ports to the Internet can cause alerts. Regularly audit network configurations to ensure VNC ports are not exposed and adjust the rule to exclude known safe configurations.
+- Third-party service providers accessing systems via VNC for support purposes might be flagged. Establish a list of trusted IPs for these providers and update the rule to exclude them from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active VNC sessions originating from untrusted IP addresses to cut off potential attacker access.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized changes or data access that may have occurred during the VNC session.
+- Reset credentials for any accounts that were accessed or could have been compromised during the unauthorized VNC session.
+- Apply security patches and updates to the VNC software and any other potentially vulnerable applications on the affected system.
+- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the Internet.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1219"
+name = "Remote Access Tools"
+reference = "https://attack.mitre.org/techniques/T1219/"
+
+
+[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 = "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/"
+