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

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

@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-28-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-pfsense.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: Fortinet
+* Data Source: PAN-OS
+* Data Source: pfSense
+* Data Source: SonicWall
+* Data Source: Suricata
+* Resources: Investigation Guide
+
+*Version*: 116
+
+*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]
+----------------------------------
+(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow
+        or panw.panos or pfsense.log or sonicwall_firewall.log or suricata.eve)
+    or event.category:(network or network_traffic))
+    and event.type:(connection and not (denied or end))
+    and not event.action:(Reject or client-rst or connection-denied or
+        connection-end or denied or deny or flow_denied or flow_dropped or
+        flow_terminated or network_flow or server-rst or timeout)
+    and not (event.action:netflow_flow and not network.packets > 1)
+    and not network.application:(stretchoid-scanning or traceroute)
+    and destination.port:23
+    and (network.protocol:(telnet or not *) or data_stream.dataset:fortinet_fortigate.log)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Application Layer Protocol
+** ID: T1071
+** Reference URL: https://attack.mitre.org/techniques/T1071/
+* 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: External Remote Services
+** ID: T1133
+** Reference URL: https://attack.mitre.org/techniques/T1133/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/

docs/detections/prebuilt-rules/downloadable-packages/8-19-28/prebuilt-rule-8-19-28-application-added-to-google-workspace-domain.asciidoc

@@ -0,0 +1,154 @@
+[[prebuilt-rule-8-19-28-application-added-to-google-workspace-domain]]
+=== Application Added to Google Workspace Domain
+
+Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-google_workspace.admin-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 10m
+
+*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://support.google.com/a/answer/6328701?hl=en#
+* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one
+* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Google Workspace
+* Use Case: Configuration Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Application Added to Google Workspace Domain*
+
+
+Google Workspace Marketplace applications can request OAuth scopes to read or modify tenant data. When an administrator
+adds an application at the domain level, users may be able to install or authorize it broadly, creating a durable
+third-party access path. Threat actors with admin rights may add an adversary-controlled app to maintain API-based
+persistence and access sensitive resources at scale.
+
+This rule identifies when an administrator adds a Marketplace application via the `ADD_APPLICATION` event in the
+`google_workspace.admin` data stream.
+
+
+*Possible investigation steps*
+
+
+- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `@timestamp`.
+- Identify the application added by reviewing `google_workspace.admin.application.name` and related application metadata in the raw event.
+- Determine whether the change is expected and authorized:
+  - Validate there is an approved change request or vendor onboarding record for the application.
+  - If the actor account is unusual, treat the alert as higher priority until proven benign.
+- Review Marketplace apps in the Google Admin console:
+  - Navigate to Apps > Google Workspace Marketplace apps.
+  - Confirm whether the application is allowed domain-wide or for specific organizational units, and review requested API scopes against least-privilege expectations.
+- Search Kibana for related admin and OAuth activity:
+  - Find other Marketplace changes by the same actor:
+    ```
+    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ADD_APPLICATION" or "REMOVE_APPLICATION")
+    ```
+  - After the add, review OAuth authorizations that may indicate users or admins granting access to the app:
+    ```
+    data_stream.dataset: "google_workspace.token" and event.action: "authorize"
+    ```
+  - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as Marketplace restriction changes, blocklist removals, or role assignments.
+
+
+*False positive analysis*
+
+
+- Verify the application is an approved business tool with documented vendor risk review and scope justification.
+- New application rollouts during migrations or acquisitions can trigger this rule, validate timing against change windows.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on triage findings.
+- If the add is not clearly authorized, remove or block the application under Google Workspace Marketplace apps while the investigation proceeds.
+- Revoke OAuth tokens for the application client if users have already authorized it (`Security` > Access and data control > API controls, or user token review in admin reports).
+- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Assess the criticality of affected services and servers.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
+- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
+- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+
+
+*Important Information Regarding Google Workspace Event Lag Times*
+
+- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
+- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
+- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
+- See the following references for further information:
+  - https://support.google.com/a/answer/7061566
+  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html
+
+==== Setup
+
+
+The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:google_workspace.admin and event.action:ADD_APPLICATION
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Credentials
+** ID: T1098.001
+** Reference URL: https://attack.mitre.org/techniques/T1098/001/