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

nldcsc_elastic_rules/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml

@@ -0,0 +1,122 @@
+[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 to 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 made 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) to the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 47
+rule_id = "3ad49c61-7adc-42c1-b788-732eda2f5abf"
+severity = "medium"
+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
+  source.ip:(
+    10.0.0.0/8 or
+    172.16.0.0/12 or
+    192.168.0.0/16
+  ) 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"
+  )
+'''
+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) to the Internet
+
+VNC is a tool that allows remote control of computers, often used by administrators for maintenance. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out internal IP addresses, flagging potential threats when VNC is accessed from external networks.
+
+### Possible investigation steps
+
+- Review the source IP address to determine if it belongs to a known internal asset or user, and verify if the access was authorized.
+- Check the destination IP address to confirm if it is an external address and investigate its reputation or any known associations with malicious activity.
+- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or volumes of VNC traffic.
+- Correlate the VNC traffic event with other security events or logs to identify any related suspicious activities or anomalies.
+- Investigate the user account associated with the VNC session to ensure it has not been compromised or misused.
+- Assess the system or application logs on the destination machine for any signs of unauthorized access or changes during the time of the VNC connection.
+
+### False positive analysis
+
+- Internal maintenance activities may trigger the rule if VNC is used for legitimate remote administration. To manage this, create exceptions for known internal IP addresses that frequently use VNC for maintenance.
+- Automated scripts or tools that use VNC for legitimate purposes might be flagged. Identify these tools and whitelist their IP addresses to prevent unnecessary alerts.
+- Testing environments that simulate external access to VNC for security assessments can cause false positives. Exclude IP ranges associated with these environments to avoid confusion.
+- Cloud-based services that use VNC for remote management might be misidentified as threats. Verify these services and add their IP addresses to an exception list if they are trusted.
+- Temporary remote access setups for troubleshooting or support can be mistaken for unauthorized access. Document these instances and apply temporary exceptions to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active VNC sessions that are identified as originating from external networks to cut off potential attacker access.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data transfer that may have occurred during the VNC exposure.
+- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
+- Apply necessary patches and updates to the VNC software and any other vulnerable applications on the affected system to mitigate known vulnerabilities.
+- 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 compromised."""
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/network/discovery_potential_network_sweep_detected.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2023/05/17"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/02/28"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies a potential network sweep. A network sweep is a method used by attackers to scan a target network,
+identifying active hosts, open ports, and available services to gather information on vulnerabilities and weaknesses.
+This reconnaissance helps them plan subsequent attacks and exploit potential entry points for unauthorized access, data
+theft, or other malicious activities. This rule defines a threshold-based approach to detect multiple connection
+attempts from a single host to numerous destination hosts over commonly used network services.
+"""
+from = "now-9m"
+index = ["packetbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 5
+name = "Potential Network Sweep Detected"
+risk_score = 21
+rule_id = "781f8746-2180-4691-890c-4c96d11ca91d"
+severity = "low"
+tags = [
+    "Domain: Network",
+    "Tactic: Discovery",
+    "Tactic: Reconnaissance",
+    "Use Case: Network Security Monitoring",
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+query = '''
+event.action:network_flow and destination.port:(21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and
+source.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 Potential Network Sweep Detected
+
+Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies such sweeps by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance activities for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address to determine if it belongs to a known or trusted entity within the network, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
+- Analyze the destination IP addresses to identify any patterns or commonalities, such as specific subnets or devices, that could indicate targeted reconnaissance.
+- Check historical logs for previous connection attempts from the same source IP to see if there is a pattern of repeated scanning behavior or if this is an isolated incident.
+- Investigate the specific ports targeted (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) to determine if they are associated with critical services or known vulnerabilities within the network.
+- Correlate the detected activity with any recent changes or incidents in the network environment that might explain the behavior, such as new device deployments or configuration changes.
+- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Internal network scans by IT teams can trigger the rule. Regularly scheduled scans for security assessments should be documented and their source IPs added to an exception list to prevent false alerts.
+- Automated monitoring tools that check network health might cause false positives. Identify these tools and exclude their IP addresses from the rule to avoid unnecessary alerts.
+- Load balancers or network devices that perform health checks across multiple hosts can be mistaken for network sweeps. Exclude these devices by adding their IPs to a whitelist.
+- Development or testing environments where multiple connections are made for legitimate purposes can trigger the rule. Ensure these environments are recognized and their IP ranges are excluded from monitoring.
+- Misconfigured devices that repeatedly attempt to connect to multiple hosts can appear as network sweeps. Investigate and correct the configuration, then exclude these devices if necessary.
+
+### Response and remediation
+
+- Isolate the source IP: Immediately isolate the source IP address identified in the alert from the network to prevent further reconnaissance or potential exploitation of identified vulnerabilities.
+
+- Block suspicious ports: Implement firewall rules to block incoming and outgoing traffic on the commonly targeted ports (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) from the source IP to mitigate further scanning attempts.
+
+- Conduct a network-wide scan: Perform a comprehensive scan of the network to identify any unauthorized access or changes that may have occurred as a result of the network sweep.
+
+- Review and update access controls: Ensure that access controls and permissions are appropriately configured to limit exposure of critical services and sensitive data.
+
+- Monitor for recurrence: Set up enhanced monitoring and alerting for any future connection attempts from the source IP or similar patterns of network sweep activity.
+
+- Escalate to security operations: Notify the security operations team to conduct a deeper investigation into the source of the network sweep and assess any potential threats or breaches.
+
+- Document and report: Record all findings, actions taken, and lessons learned in an incident report to inform future response strategies and improve network defenses."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1046"
+name = "Network Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1046/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1595"
+name = "Active Scanning"
+reference = "https://attack.mitre.org/techniques/T1595/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1595.001"
+name = "Scanning IP Blocks"
+reference = "https://attack.mitre.org/techniques/T1595/001/"
+
+[rule.threat.tactic]
+id = "TA0043"
+name = "Reconnaissance"
+reference = "https://attack.mitre.org/tactics/TA0043/"
+
+[rule.threshold]
+field = ["source.ip"]
+value = 1
+
+[[rule.threshold.cardinality]]
+field = "destination.ip"
+value = 100

nldcsc_elastic_rules/rules/network/discovery_potential_port_scan_detected.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2023/05/17"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/02/28"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies a potential port scan. A port scan is a method utilized by attackers to systematically scan a
+target system or network for open ports, allowing them to identify available services and potential vulnerabilities. By
+mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining
+unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further
+exploitation of the targeted system or network. This rule defines a threshold-based approach to detect connection
+attempts from a single source to a wide range of destination ports.
+"""
+from = "now-9m"
+index = ["logs-network_traffic.*", "packetbeat-*", "filebeat-*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 5
+name = "Potential Network Scan Detected"
+risk_score = 21
+rule_id = "0171f283-ade7-4f87-9521-ac346c68cc9b"
+severity = "low"
+tags = [
+    "Domain: Network",
+    "Tactic: Discovery",
+    "Tactic: Reconnaissance",
+    "Use Case: Network Security Monitoring",
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.action:network_flow and destination.port:* and source.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 Potential Network Scan Detected
+
+Network scanning is a technique used to identify open ports and services on a network, often exploited by attackers to find vulnerabilities. Adversaries may use this method to map out a network's structure and identify weak points for further exploitation. The detection rule identifies suspicious activity by monitoring for multiple connection attempts from a single source to numerous destination ports, indicating a potential scan. This helps in early detection and mitigation of reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the source IP address involved in the alert to determine if it belongs to a known or trusted entity within the organization. Check if the IP falls within the specified ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
+- Analyze the network flow logs to identify the specific destination ports that were targeted by the source IP. Determine if these ports are associated with critical services or known vulnerabilities.
+- Correlate the detected activity with any recent changes or updates in the network infrastructure that might explain the scanning behavior, such as new devices or services being deployed.
+- Investigate if there are any other alerts or logs indicating similar scanning activities from the same source IP or other IPs within the same subnet, which might suggest a coordinated scanning effort.
+- Check for any historical data or past incidents involving the source IP to assess if this behavior is part of a recurring pattern or a new anomaly.
+- Consult with network administrators to verify if the detected activity aligns with any scheduled network assessments or security tests that might have been conducted without prior notification.
+
+### False positive analysis
+
+- Internal network scanning tools used for legitimate security assessments can trigger this rule. To manage this, create exceptions for known IP addresses of authorized scanning tools.
+- Automated network monitoring systems that check service availability across multiple ports may be flagged. Exclude these systems by identifying their IP addresses and adding them to an exception list.
+- Load balancers and network devices that perform health checks on various services might cause false positives. Identify these devices and configure the rule to ignore their IP addresses.
+- Development and testing environments where frequent port scanning is part of routine operations can be mistakenly flagged. Implement exceptions for these environments by specifying their IP ranges.
+- Regularly scheduled vulnerability assessments conducted by internal security teams can appear as network scans. Document these activities and exclude the associated IPs from triggering the rule.
+
+### Response and remediation
+
+- Isolate the affected host: Immediately disconnect the source IP from the network to prevent further scanning or potential exploitation of identified vulnerabilities.
+- Conduct a thorough investigation: Analyze the source IP's activity logs to determine if any unauthorized access or data exfiltration has occurred. This will help assess the extent of the threat.
+- Update firewall rules: Implement stricter access controls to limit the number of open ports and restrict unnecessary inbound and outbound traffic from the affected IP range.
+- Patch and update systems: Ensure all systems and services identified during the scan are up-to-date with the latest security patches to mitigate known vulnerabilities.
+- Monitor for recurrence: Set up enhanced monitoring for the source IP and similar scanning patterns to quickly detect and respond to any future scanning attempts.
+- Escalate to security operations: If the scan is part of a larger attack or if sensitive data is at risk, escalate the incident to the security operations team for further analysis and response.
+- Review and enhance detection capabilities: Evaluate the effectiveness of current detection mechanisms and consider integrating additional threat intelligence sources to improve early detection of similar threats."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1046"
+name = "Network Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1046/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1595"
+name = "Active Scanning"
+reference = "https://attack.mitre.org/techniques/T1595/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1595.001"
+name = "Scanning IP Blocks"
+reference = "https://attack.mitre.org/techniques/T1595/001/"
+
+[rule.threat.tactic]
+id = "TA0043"
+name = "Reconnaissance"
+reference = "https://attack.mitre.org/tactics/TA0043/"
+
+[rule.threshold]
+field = ["destination.ip", "source.ip"]
+value = 1
+
+[[rule.threshold.cardinality]]
+field = "destination.port"
+value = 250

nldcsc_elastic_rules/rules/network/discovery_potential_syn_port_scan_detected.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2023/05/17"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/02/28"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a
+target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this
+method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch
+targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading
+to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection
+attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port.
+"""
+from = "now-9m"
+index = ["logs-network_traffic.*", "packetbeat-*", "filebeat-*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 5
+name = "Potential SYN-Based Port Scan Detected"
+risk_score = 21
+rule_id = "bbaa96b9-f36c-4898-ace2-581acb00a409"
+severity = "low"
+tags = [
+    "Domain: Network",
+    "Tactic: Discovery",
+    "Tactic: Reconnaissance",
+    "Use Case: Network Security Monitoring",
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+query = '''
+event.action:network_flow and destination.port:* and network.packets <= 2 and source.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 Potential SYN-Based Port Scan Detected
+
+SYN-based port scanning is a reconnaissance technique where attackers send SYN packets to multiple ports to identify open services. This method helps adversaries map network vulnerabilities for potential exploitation. The detection rule identifies such scans by flagging connection attempts from internal IPs to multiple ports with minimal packet exchange, indicating a low-risk reconnaissance activity.
+
+### Possible investigation steps
+
+- Review the source IP address involved in the alert to determine if it belongs to a known or authorized device within the network. Check for any recent changes or unusual activity associated with this IP.
+- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services.
+- Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort.
+- Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts.
+- Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker's intent and urgency.
+- Assess the network's current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports.
+
+### False positive analysis
+
+- Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery.
+- Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives.
+- Software updates or patch management systems that check multiple ports for service availability can be mistaken for a SYN-based port scan. Whitelist these systems to avoid unnecessary alerts.
+- Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection.
+- Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats.
+
+### Response and remediation
+
+- Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports.
+- Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks.
+- Implement rate limiting on SYN packets to reduce the risk of successful port scanning and reconnaissance activities.
+- Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected.
+- Update intrusion detection and prevention systems to enhance detection capabilities for similar SYN-based port scanning activities.
+- Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1046"
+name = "Network Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1046/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1595"
+name = "Active Scanning"
+reference = "https://attack.mitre.org/techniques/T1595/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1595.001"
+name = "Scanning IP Blocks"
+reference = "https://attack.mitre.org/techniques/T1595/001/"
+
+[rule.threat.tactic]
+id = "TA0043"
+name = "Reconnaissance"
+reference = "https://attack.mitre.org/tactics/TA0043/"
+
+[rule.threshold]
+field = ["destination.ip", "source.ip"]
+value = 1
+
+[[rule.threshold.cardinality]]
+field = "destination.port"
+value = 250

nldcsc_elastic_rules/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml

@@ -0,0 +1,113 @@
+[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 RPC traffic from the Internet. RPC 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.
+"""
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "RPC (Remote Procedure Call) from the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 73
+rule_id = "143cb236-0956-4f42-a706-814bcaa0cf5a"
+severity = "high"
+tags = ["Tactic: Initial Access", "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:135 or event.dataset:zeek.dce_rpc) 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 RPC (Remote Procedure Call) from the Internet
+
+RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources.
+
+### Possible investigation steps
+
+- Review the source IP address of the alert to determine if it is from a known malicious actor or if it has been flagged in previous incidents.
+- Check the destination IP address to confirm it belongs to a critical internal system that should not be exposed to the Internet.
+- Analyze network traffic logs to identify any unusual patterns or volumes of traffic associated with the source IP, focusing on TCP port 135.
+- Investigate any related alerts or logs from the same source IP or destination IP to identify potential patterns or repeated attempts.
+- Assess the potential impact on the affected system by determining if any unauthorized access or changes have occurred.
+- Consult threat intelligence sources to gather additional context on the source IP or any related indicators of compromise.
+
+### False positive analysis
+
+- Internal testing or development environments may generate RPC traffic that appears to originate from external sources. To manage this, add the IP addresses of these environments to the exception list in the detection rule.
+- Legitimate remote management activities by trusted third-party vendors could trigger the rule. Verify the IP addresses of these vendors and include them in the exception list if they are known and authorized.
+- Misconfigured network devices or proxies might route internal RPC traffic through external IP addresses. Review network configurations to ensure proper routing and add any necessary exceptions for known devices.
+- Cloud-based services or applications that use RPC for legitimate purposes might be flagged. Identify these services and adjust the rule to exclude their IP ranges if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Conduct a thorough examination of the system logs and network traffic to identify any unauthorized access or data exfiltration attempts.
+- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Change all administrative and user credentials on the affected system and any other systems that may have been accessed using the same credentials.
+- Implement network segmentation to limit the exposure of critical systems and services, ensuring that RPC services are not accessible from the Internet.
+- Monitor the network for any signs of re-infection or further suspicious activity, focusing on traffic patterns similar to those identified in the initial alert.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if additional systems are compromised."""
+
+
+[[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/"
+