[Detection Rules] Adding Documents for v8.19.16 Pre-Built Detection Rules

docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc

@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-accepted-default-telnet-port-connection]]
+=== Accepted Default Telnet Port Connection
+
+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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* auditbeat-*
+* filebeat-*
+* logs-network_traffic.*
+* logs-panw.panos*
+* logs-fortinet_fortigate.log-*
+* logs-sonicwall_firewall.log-*
+* logs-suricata.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Tactic: Lateral Movement
+* Tactic: Initial Access
+* Data Source: PAN-OS
+* Data Source: Fortinet
+* Data Source: SonicWall
+* Data Source: Suricata
+* Resources: Investigation Guide
+
+*Version*: 111
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 query
+
+
+[source, js]
+----------------------------------
+(event.dataset:(fortinet_fortigate.log or network_traffic.flow
+        or sonicwall_firewall.log or suricata.eve or panw.panos)
+    or event.category:(network or network_traffic))
+    and event.type:(connection and not end) 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
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/

docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc

@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address]]
+=== Alerts From Multiple Integrations by Destination Address
+
+This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Alerts From Multiple Integrations by Destination Address*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same destination.ip are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding low severity, threat_match and machine_learning rules 
+| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// group alerts by destination.ip and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.source_ip_values = VALUES(source.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by destination.ip
+
+// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels or presence of high severity alerts
+| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
+| keep destination.ip, Esql.*
+
+----------------------------------

docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc

@@ -0,0 +1,118 @@
+[[prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address]]
+=== Alerts From Multiple Integrations by Source Address
+
+This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Alerts From Multiple Integrations by Source Address*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same source.ip are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding low severity and the noisy ones
+| where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// group alerts by source.ip and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by source.ip
+
+// filter for alerts from same source.ip reported by different integrations with unique categories and with different severity levels
+| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
+| keep source.ip, Esql.*
+
+----------------------------------