diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..d219127871 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-abnormally-large-dns-response.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-26-abnormally-large-dns-response]] +=== Abnormally Large DNS Response + +Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Impact +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: Zeek + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Abnormally Large DNS Response* + + +Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability[SigRed] during July 2020. + + +*Possible investigation steps* + + +- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment. +- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts. +- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data. +- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning. +- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment. + + +*False positive analysis* + + +- Based on this rule, which looks for a threshold of 65k bytes, activity below this value is expected to be legitimate. In packet capture files received by the https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/[SANS Internet Storm Center], byte responses in observed attacks were all greater than 65k bytes. +- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host. +- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters, as well as Zeek/Corelight connection summary records, record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow or connection records (`event.duration` > 60 seconds) are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection. + + +*Related rules* + + +- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45 +- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Ensure that you have deployed the latest Microsoft https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350[Security Update] (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability[released] a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied. +- Maintain backups of your critical systems to aid in quick recovery. +- Perform routine vulnerability scans of your systems, monitor https://us-cert.cisa.gov/ncas/current-activity[CISA advisories] and patch identified vulnerabilities. +- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior. + + +==== Rule query + + +[source, js] +---------------------------------- +((event.category:(network or network_traffic) and destination.port:53) + or network.protocol:"dns" + or data_stream.dataset:(network_traffic.dns or zeek.dns) + or (event.module:corelight and event.dataset:dns)) + and destination.bytes >= 65000 + and event.type:("allowed" or "end" or "protocol" or "start") +and not ( + event.duration > 60000000000 + and ( + event.action:("flow_terminated" or "network_flow") + or data_stream.dataset:zeek.connection + or (event.module:corelight and event.dataset:conn) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Application or System Exploitation +** ID: T1499.004 +** Reference URL: https://attack.mitre.org/techniques/T1499/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..74ca81e034 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-26-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 <>) + +*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*: 115 + +*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 + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-added-to-google-workspace-domain.asciidoc new file mode 100644 index 0000000000..f81d80b7cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-added-to-google-workspace-domain.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-26-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*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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*: 211 + +*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: "" 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-removed-from-blocklist-in-google-workspace.asciidoc new file mode 100644 index 0000000000..176487b02f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-application-removed-from-blocklist-in-google-workspace.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-26-application-removed-from-blocklist-in-google-workspace]] +=== Application Removed from Blocklist in Google Workspace + +Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*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 +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Application Removed from Blocklist in Google Workspace* + + +Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or Google Apps Script and created by both Google and third-party developers. + +Marketplace applications require access to specific Google Workspace resources. Individual users with the appropriate permissions can install applications in their Google Workspace domain. Administrators have additional permissions that allow them to install applications for an entire Google Workspace domain. Consent screens typically display permissions and privileges the user needs to install an application. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent. + +Google clearly states that they are not responsible for any Marketplace product that originates from a source that isn't Google. + +This rule identifies a Marketplace blocklist update that consists of a Google Workspace account with administrative privileges manually removing a previously blocked application. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the app moved from blocked to allowed and note the affected organizational unit (`google_workspace.admin.org_unit.name`). +- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. +- With access to the Google Workspace admin console, visit the `Security > Investigation` tool with filters for the user email and event is `Assign Role` or `Update Role` to determine if new cloud roles were recently updated. +- After identifying the involved user account, review other potentially related events within the last 48 hours. +- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. +- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace apps > Apps list`. + + +*False positive analysis* + + +- Google Workspace administrators might intentionally remove an application from the blocklist due to a re-assessment or a domain-wide required need for the application. +- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. +- Contact the user to verify that they intentionally removed the application from the blocklist and their reasoning. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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 user 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:"CHANGE_APPLICATION_SETTING" and + google_workspace.admin.application.name:"Google Workspace Marketplace" and + google_workspace.admin.old_value: *allowed*false* and google_workspace.admin.new_value: *allowed*true* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc new file mode 100644 index 0000000000..90745e560b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-agent-created-by-iam-user-or-root]] +=== AWS Bedrock Agent Created by IAM User or Root + +Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent Created by IAM User or Root* + + +AWS Bedrock Agents can autonomously perform complex tasks by combining foundation models with action groups +(Lambda functions) and knowledge bases. A rogue agent could serve as a persistent AI-driven foothold, executing +attacker-controlled instructions via inference requests. + + +*Possible investigation steps* + + +- **Identity**: `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`. This rule fires only + for IAMUser or Root — both are direct human credentials, not automated pipeline roles. Confirm the user is + known and authorized to create agents. + +- **Agent configuration** in `aws.cloudtrail.request_parameters`: + - `agentName` — does the name match known internal projects? + - `foundationModel` — which model was selected? Expensive models (Claude Opus-class) indicate higher cost risk. + - `instruction` — the system prompt. Adversarial, minimal, or exfiltration-oriented instructions are a red flag. + - `actionGroupExecutor.lambda` — Lambda ARN presence means the agent can invoke external code. + +- **Cross-account indicators**: Lambda ARNs in action groups belonging to a different account than + `cloud.account.id` indicate external code execution capability. + +- **Follow-on activity**: Look for `PrepareAgent`, `CreateAgentAlias`, `CreateAgentActionGroup`, or + `AssociateAgentKnowledgeBase` from the same identity within the next hour. + + +*False positive analysis* + +- Developers creating agents interactively with personal IAM user credentials. Confirm the agent is for a known + project and the IAM user is authorized. Production agent deployment should use IAM roles — personal key use + is itself a misconfiguration worth noting. + + +*Response and remediation* + +- Delete the unauthorized agent using `DeleteAgent`. +- Review and remove associated action groups and aliases. +- Audit Lambda functions referenced in action group executors for malicious code. +- Restrict `bedrock:CreateAgent` to specific deployment roles via IAM policy or SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: "CreateAgent" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("IAMUser" or "Root") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-or-action-group-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-or-action-group-manipulation.asciidoc new file mode 100644 index 0000000000..ea45b36897 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-agent-or-action-group-manipulation.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-agent-or-action-group-manipulation]] +=== AWS Bedrock Agent or Action Group Manipulation + +Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateAgent.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgentActionGroup.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_PrepareAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent or Action Group Manipulation* + + +Amazon Bedrock agents orchestrate foundation models with developer-defined instructions and action groups that connect +the agent to Lambda functions or APIs. Because end users and applications repeatedly invoke deployed agents, an attacker +who modifies an existing agent's instructions, action groups, collaborators, or alias can implant durable malicious +behavior into a trusted component without deploying any new infrastructure. The `PrepareAgent` call makes a tampered +configuration live, and updating an alias repoints traffic to the tampered version. + +This rule identifies changes to existing Bedrock agents while intentionally excluding `CreateAgent`, which represents +net-new resource creation rather than tampering with established, trusted agents. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who made the change. + - Inspect `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to establish whether the + change came from an interactive session, automation, or an unfamiliar location. + - Confirm whether a corresponding change request or deployment exists for the affected agent. +- **Examine the change** + - Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.flattened.request_parameters` for the targeted agent + ID, action group definition, Lambda ARN, collaborator, or alias routing configuration. + - For `UpdateAgent`, inspect the modified instruction text for prompt-injection or data-exfiltration intent. + - For action group changes, validate the referenced Lambda function or API schema ownership and intent. + - For alias changes, confirm which agent version the alias now points to. +- **Correlate activity** + - Look for a `PrepareAgent` call following configuration changes, which indicates the tampered config was made live. + - Search for surrounding IAM, Lambda, or STS activity from the same identity that could indicate broader compromise. + + +*False positive analysis* + + +- **Planned development and tuning**: Legitimate developers regularly update agent instructions and action groups. + Validate against change tickets and known engineering activity. +- **Automation**: IaC pipelines and deployment tooling may call these APIs on every release. Exempt known automation + roles if they cause recurring false positives. + + +*Response and remediation* + + +- If the change is unauthorized, revert the agent, action group, collaborator, and alias to a known-good version and + re-run `PrepareAgent` to restore trusted behavior. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review the affected agent's action group Lambda functions and APIs for malicious code or data flows. +- Restrict `bedrock:UpdateAgent`, `bedrock:*AgentActionGroup`, `bedrock:*AgentCollaborator`, `bedrock:*AgentAlias`, and + `bedrock:PrepareAgent` permissions to a small set of administrative roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "UpdateAgent" or + "CreateAgentActionGroup" or + "UpdateAgentActionGroup" or + "AssociateAgentCollaborator" or + "UpdateAgentCollaborator" or + "CreateAgentAlias" or + "UpdateAgentAlias" or + "PrepareAgent" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc new file mode 100644 index 0000000000..64c3d455d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-automated-reasoning-safety-policy-tampering]] +=== AWS Bedrock Automated Reasoning Safety Policy Tampering + +Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/automated-reasoning.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Automated Reasoning Safety Policy Tampering* + + +AWS Bedrock Automated Reasoning policies enforce formal, rule-based validation of model outputs, acting as a +safety control that constrains what a model is permitted to return. Deleting a policy or modifying its +definition or annotations directly weakens this control. Adversaries who have gained access to the Bedrock +control plane may tamper with these policies to evade output-validation defenses, enabling unsafe, manipulated, +or non-compliant model behavior. This detection identifies `DeleteAutomatedReasoningPolicy`, +`UpdateAutomatedReasoningPolicy`, and `UpdateAutomatedReasoningPolicyAnnotations` calls so responders can +confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Determine whether the identity normally administers Bedrock safety policies and whether the action aligns + with an approved change request. +- **Review the specific action** + - For `DeleteAutomatedReasoningPolicy`, identify the deleted policy in + `aws.cloudtrail.flattened.request_parameters` and confirm whether a replacement control exists. + - For `UpdateAutomatedReasoningPolicy` / `UpdateAutomatedReasoningPolicyAnnotations`, inspect + `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to understand what was changed + and whether the change loosens validation constraints. +- **Correlate surrounding activity** + - Look for other Defense Evasion or Bedrock control-plane activity from the same identity in the surrounding + window (model invocation changes, guardrail modifications, logging changes). + - Check `cloud.account.id` and `cloud.region` to scope blast radius across the environment. + + +*False positive analysis* + + +- **Planned policy maintenance**: Governance teams may legitimately tune or retire Automated Reasoning + policies. Validate against change tickets and standard templates. +- **Automation**: IaC or CI/CD pipelines may update policies during deployments. Confirm the actor maps to + known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, restore the prior policy definition or recreate the deleted policy from a + known-good configuration. +- Revoke or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is suspected. +- Review all Bedrock control-plane activity from the same identity in the preceding window for further + defense-impairing actions. +- Restrict `bedrock:DeleteAutomatedReasoningPolicy` and `bedrock:UpdateAutomatedReasoningPolicy*` permissions + to a small set of administrative roles and enforce approval workflows. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "DeleteAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicyAnnotations" + ) and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc new file mode 100644 index 0000000000..25f6cdbb68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted]] +=== AWS Bedrock Foundation Model Access Enabled or Entitlement Granted + +Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*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 AWS Bedrock Foundation Model Access Enabled or Entitlement Granted* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable. + +This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access. +- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved. +- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise. +- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking). +- Contact the resource owner to confirm whether enabling this model access was planned and authorized. + + +*False positive analysis* + + +- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows. +- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected. + + +*Response and remediation* + + +- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model. +- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs. +- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "success" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc new file mode 100644 index 0000000000..066fd593dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key]] +=== AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key + +Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_InvokeModel.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Discovery +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key* + + +This rule fires when the same long-term IAM user access key (AKIA*) calls `ListFoundationModels` and then +invokes a model within 15 minutes. This sequence — enumerate available models, then immediately use one — is +consistent with LLMjacking: an adversary using stolen IAM user credentials to discover and abuse available +AI model capabilities at the account owner's expense. + +Long-term access keys (`AKIA*` prefix) belong to IAM users, not roles. Legitimate Bedrock workloads in +production almost always run under IAM roles with short-lived credentials. A long-term key performing both +model discovery and invocation is unusual and warrants investigation. + + +*Possible investigation steps* + + +- **Identify the key and owner**: Review `aws.cloudtrail.user_identity.arn` and + `aws.cloudtrail.user_identity.access_key_id`. Determine who owns the key and whether it is authorized for + Bedrock usage. +- **Check for credential exposure**: Search for the access key in source code, CI/CD logs, and secret scanning + alerts. A key used from an unexpected source IP is a strong indicator of compromise. +- **Examine the invocation**: Review `aws.cloudtrail.request_parameters` on the `InvokeModel` event to identify + which model was invoked. Cross-reference with Bedrock invocation logs for prompt and response content. +- **Correlate source IP and user agent**: Confirm `source.ip` and `user_agent.original` match the key owner's + expected environment. Residential IPs, VPNs, or unexpected tools are suspicious. +- **Look for volume**: Check whether this is the first invocation or part of a burst of `InvokeModel` calls. + High-volume invocations following enumeration are a strong LLMjacking signal. + + +*False positive analysis* + + +- **Developer testing**: Engineers using long-term IAM user keys for local Bedrock development may trigger this + rule when they first explore available models. Validate against a known developer identity and source IP. + Encourage migration to IAM roles for all Bedrock workloads. + + +*Response and remediation* + + +- Immediately disable or rotate the access key if compromise is suspected. +- Review all Bedrock invocations made by the key before and after this event. +- Check whether the same key accessed other AWS services (S3, EC2, Secrets Manager). +- Enforce IAM roles for all Bedrock workloads and restrict long-term key usage via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by aws.cloudtrail.user_identity.access_key_id with maxspan=15m + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action == "ListFoundationModels" + and event.outcome == "success" + and aws.cloudtrail.user_identity.access_key_id like "AKIA*"] + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action : ("InvokeModel", "InvokeModelWithResponseStream", "Converse", "ConverseStream") + and event.outcome == "success"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-guardrail-deleted-or-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-guardrail-deleted-or-weakened.asciidoc new file mode 100644 index 0000000000..42d5f7e6f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-guardrail-deleted-or-weakened.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-guardrail-deleted-or-weakened]] +=== AWS Bedrock Guardrail Deleted or Weakened + +Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrail Deleted or Weakened* + + +AWS Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model +invocations. Adversaries who gain access to the Bedrock control plane may delete a guardrail (`DeleteGuardrail`), +loosen its policies (`UpdateGuardrail`), remove or overwrite the organization-enforced guardrail +configuration (`DeleteEnforcedGuardrailConfiguration` / `PutEnforcedGuardrailConfiguration`) to then enforce it on +model deployments. This detection identifies those control-plane changes so responders can confirm +intent before accepting the change. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Confirm a related change request exists and that the identity is authorized to manage guardrails. +- **Validate the change** + - For `UpdateGuardrail` / `PutEnforcedGuardrailConfiguration`, inspect + `aws.cloudtrail.flattened.request_parameters` and `aws.cloudtrail.response_elements` to determine + which content, topic, word, or sensitive-information policies were removed or weakened. + - For `DeleteGuardrail` / `DeleteEnforcedGuardrailConfiguration`, identify the targeted guardrail + or org configuration and whether protected workloads still reference it. +- **Correlate activity** + - Look for surrounding Bedrock `InvokeModel` / `Converse` activity and other defense-impairing + actions (e.g., logging or detector changes) from the same identity. + - Check for prior enumeration such as `ListGuardrails` or `GetGuardrail`. + + +*Response and remediation* + + +- If unauthorized, restore the guardrail and/or org-enforced configuration to its approved state and + re-associate it with affected Bedrock workloads. +- Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and review the actor's + recent activity; rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteGuardrail`, `bedrock:UpdateGuardrail`, and the enforced-configuration + permissions to a small set of admin roles, and enforce guardrail state via AWS Config or SCPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "DeleteGuardrail" or + "UpdateGuardrail" or + "DeleteEnforcedGuardrailConfiguration" or + "PutEnforcedGuardrailConfiguration" + ) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc new file mode 100644 index 0000000000..38218700ab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-high-frequency-single-model-inference-api-probing]] +=== AWS Bedrock High-Frequency Single-Model Inference API Probing + +Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0024 +* https://atlas.mitre.org/techniques/AML.T0024.000 +* https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Exfiltration +* Mitre Atlas: T0024 +* Mitre Atlas: T0024.000 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing* + + +Membership inference compares many samples against a model to infer whether +specific records were present in training data. Because prompts and responses often appear benign, the +actionable signal is frequently statistical: unusually high inference rates concentrated on one model from +a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, +`InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by +default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is +disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric. + +This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not +as conclusive membership inference detection. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted + `Esql.model_id`. +- Determine whether the call volume exceeds the principal's historical baseline for the same model. +- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance + responses that may indicate membership testing. +- Inspect `source.ip`, `user_agent.original`, and recent IAM activity for signs of compromised credentials + or unexpected automation. +- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse + campaign. + + +*Response and remediation* + + +- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating. +- Enable model invocation logging for content-level review if not already configured. +- If abuse is confirmed, rotate access keys or disable the compromised principal. + + +*Additional information* + + +- For further details on how Amazon Bedrock integrates with AWS CloudTrail to log control plane and data plane runtime operations, see the https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html[AWS Bedrock User Guide on CloudTrail Logging]. +- To explore the adversarial tactics, techniques, and case studies surrounding machine learning model data leakage, consult the https://atlas.mitre.org/techniques/AML.T0024[MITRE ATLAS Exfiltration via Inferences (AML.T0024)] documentation. + + + +==== Setup + + + +*Setup* + + +This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS +integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management +events by default; no Bedrock model invocation logging is required. + + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +// Bedrock runtime inference APIs (CloudTrail management events, logged by default) used to probe at scale +| where + event.provider == "bedrock.amazonaws.com" + and event.action in ( + "InvokeModel", + "Converse", + "ConverseStream", + "InvokeModelWithResponseStream" + ) + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + and aws.cloudtrail.request_parameters IS NOT NULL + +| grok aws.cloudtrail.request_parameters """modelId=(?[^,}\]]+)""" +| where Esql.model_id IS NOT NULL + +// preserve the grouping keys plus the ECS context fields collected via VALUES() below +| keep + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id, + event.action, + source.ip, + user_agent.original, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + cloud.region, + source.as.organization.name + +// aggregate per principal + account + model, capturing analyst context with VALUES() +| stats + Esql.inference_call_count = count(*), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name) + by + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id + +| where Esql.inference_call_count >= 500 + +| keep + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id, + Esql.inference_call_count, + Esql.event_action_values, + Esql.source_ip_values, + Esql.user_agent_original_values, + Esql.aws_cloudtrail_user_identity_type_values, + Esql.aws_cloudtrail_user_identity_access_key_id_values, + Esql.cloud_region_values, + Esql.source_as_organization_name_values + +| sort Esql.inference_call_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc new file mode 100644 index 0000000000..6b7670bc56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-knowledge-base-or-rag-data-source-tampering]] +=== AWS Bedrock Knowledge Base or RAG Data Source Tampering + +Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Knowledge Base or RAG Data Source Tampering* + + +AWS Bedrock knowledge bases provide Retrieval-Augmented Generation (RAG) by grounding model responses in a stored +corpus that is synchronized from a configured data source. Because RAG-enabled applications present these grounded +answers as authoritative, an adversary who can ingest, delete, or repoint the underlying corpus can poison the answers +returned to downstream users and systems. This rule detects control-plane changes to knowledge bases and data sources +that could enable such corpus poisoning. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id`. + - Examine `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to determine whether the + change came from an approved operator, automation, or an unexpected origin. + - Confirm a related change request exists (content update, data source migration, scheduled ingestion). +- **Validate the specific action** + - Inspect `event.action` and `aws.cloudtrail.flattened.request_parameters` to identify the knowledge base, data + source, and any S3 bucket / ingestion configuration referenced. + - For `CreateDataSource` / `UpdateDataSource`, verify the data source location (e.g., S3 bucket) is org-owned and not + attacker-controlled. + - For `IngestKnowledgeBaseDocuments` / `StartIngestionJob`, review what content was ingested and from where. + - For `DeleteKnowledgeBaseDocuments` / `DeleteDataSource`, determine whether legitimate content was removed. +- **Correlate activity** + - Look for prior enumeration of Bedrock resources or anomalous IAM/STS activity from the same identity. + - Review `cloud.account.id` and `cloud.region` to confirm the change occurred where expected. + + +*False positive analysis* + + +- **Planned content maintenance**: Routine ingestion, document updates, and re-syncs by data teams or MLOps automation + are expected. Validate against change tickets and known automation roles. +- **Infrastructure-as-code**: Pipelines may create or update data sources during deployments. Confirm the source IP and + ARN match expected automation. + + +*Response and remediation* + + +- If unauthorized, suspend or disable the implicated knowledge base and data source to prevent further poisoned + retrieval, and revert the corpus to a known-good state. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Audit recent ingestion jobs and document changes, and validate the integrity of the data source location. +- Restrict Bedrock Agent knowledge base and data source mutation permissions to a small set of trusted roles. + + +==== Setup + + + +*Setup* + + +This rule requires the AWS CloudTrail integration. The data source and knowledge base configuration actions are management +events (captured by default), but the direct document operations (`IngestKnowledgeBaseDocuments`, `DeleteKnowledgeBaseDocuments`) +are Bedrock CloudTrail **data events** that are off by default. Without Bedrock data-event logging enabled on the trail, this rule +provides only **partial coverage** — it will see config changes but not direct document ingestion/deletion, the primary poisoning +vector. Enable Bedrock data-event logging for full coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "IngestKnowledgeBaseDocuments" or + "DeleteKnowledgeBaseDocuments" or + "UpdateKnowledgeBase" or + "CreateDataSource" or + "UpdateDataSource" or + "DeleteDataSource" or + "StartIngestionJob" or + "DeleteKnowledgeBase" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc new file mode 100644 index 0000000000..353a9914f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-model-invocation-logging-disabled-or-modified]] +=== AWS Bedrock Model Invocation Logging Disabled or Modified + +Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Invocation Logging Disabled or Modified* + + +AWS Bedrock model invocation logging captures the prompts and responses processed by foundation models and delivers them +to an S3 bucket or CloudWatch log group. This data feeds the `logs-aws_bedrock.invocation-*` dataset that all data-plane +Bedrock detections depend on. Deleting the configuration stops this telemetry entirely, while overwriting it with `Put` +can silently redirect logs to a destination the defender does not monitor. Either action effectively blinds the +data-plane detection stack, making this a high-priority defense-evasion event. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved Bedrock administrator and whether a change request exists. +- **Determine the exact action** + - For `DeleteModelInvocationLoggingConfiguration`, logging is being turned off entirely — confirm this is intentional. + - For `PutModelInvocationLoggingConfiguration`, inspect `aws.cloudtrail.flattened.request_parameters` for the new + `s3Config` bucket name / key prefix and `cloudWatchConfig` log group, and verify they are owned and monitored by your org. +- **Correlate surrounding activity** + - Pivot on the same identity, `source.ip`, and `cloud.account.id` for prior enumeration + (`GetModelInvocationLoggingConfiguration`) or follow-on Bedrock data-plane activity (model invocations) that would now + be unlogged. + - Check for parallel logging-tampering against CloudTrail, Config, or GuardDuty. + + +*False positive analysis* + + +- **Planned changes**: Logging migrations or compliance updates may legitimately reconfigure or remove the + configuration. Validate against change tickets and infrastructure-as-code pipelines. + + +*Response and remediation* + + +- If unauthorized, restore model invocation logging to the approved destination and verify log delivery resumes into + `logs-aws_bedrock.invocation-*`. +- Review and secure any attacker-specified S3 bucket or CloudWatch log group, and treat data sent there as exposed. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteModelInvocationLoggingConfiguration` and `bedrock:PutModelInvocationLoggingConfiguration` to a + small set of administrative roles and alert on changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("DeleteModelInvocationLoggingConfiguration" or "PutModelInvocationLoggingConfiguration") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-provisioned-model-throughput-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-provisioned-model-throughput-tampering.asciidoc new file mode 100644 index 0000000000..141fb8216d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-provisioned-model-throughput-tampering.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-provisioned-model-throughput-tampering]] +=== AWS Bedrock Provisioned Model Throughput Tampering + +Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateProvisionedModelThroughput.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Provisioned Model Throughput Tampering* + + +Amazon Bedrock Provisioned Throughput reserves dedicated, billed model capacity for foundation models. +Because this capacity is committed and metered, adversaries can abuse it in two ways: scaling capacity up to +incur large, unauthorized cloud spend (resource/bill hijacking), or deleting reserved throughput to deny +service to production workloads that rely on committed capacity. This rule identifies +`CreateProvisionedModelThroughput`, `UpdateProvisionedModelThroughput`, and `DeleteProvisionedModelThroughput` +calls so responders can confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved administrator, ML/platform engineer, or automation role. + - Confirm a corresponding change request or capacity-planning ticket exists. +- **Validate the request details** + - Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` for the model ID, + commitment duration, and requested model units. Unusually large model-unit counts or long commitment + terms on a Create/Update may indicate cost-driven abuse. + - For `DeleteProvisionedModelThroughput`, identify which provisioned model was removed and whether any + production workload depended on it. +- **Correlate activity** + - Review other Bedrock control-plane actions (e.g., model invocation logging changes, guardrail changes) + and IAM/STS activity from the same identity around the same time. + - Check `cloud.account.id` and `cloud.region` for whether the activity occurred in an expected account/region. + + +*False positive analysis* + + +- **Capacity planning**: Platform, ML, or FinOps teams may legitimately create, update, or delete provisioned + throughput. Validate against change tickets and standard capacity-management procedures. +- **Automation**: IaC or deployment pipelines may manage provisioned throughput on bootstrap or teardown. + Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- If unauthorized, immediately disable the offending access key or role and revert the change (delete + unauthorized provisioned throughput, or recreate deleted reserved capacity required by production). +- Review billing and Cost Explorer for unexpected Bedrock provisioned-throughput charges. +- Audit the actor's recent activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:CreateProvisionedModelThroughput`, `bedrock:UpdateProvisionedModelThroughput`, and + `bedrock:DeleteProvisionedModelThroughput` to a small set of administrative roles and enforce approval + workflows and budget alarms. + + +*Additional information* + + +- **https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html[Amazon Bedrock Provisioned Throughput]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "CreateProvisionedModelThroughput" or + "UpdateProvisionedModelThroughput" or + "DeleteProvisionedModelThroughput" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..61cf09606c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-resource-based-policy-modified-or-deleted]] +=== AWS Bedrock Resource-Based Policy Modified or Deleted + +Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Resource-Based Policy Modified or Deleted* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. Adversaries can attach a policy that grants an external principal +access for persistence or cross-account access, or delete a policy to break existing access controls. This +rule detects successful `PutResourcePolicy` and `DeleteResourcePolicy` calls against the Bedrock control +plane. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm the identity is expected to manage Bedrock resource policies and that a related change request + exists. +- **Validate the policy change** + - For `PutResourcePolicy`, inspect `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. + - For `DeleteResourcePolicy`, determine which resource lost its policy and whether that resource should + have remained restricted. +- **Correlate activity** + - Look for related Bedrock actions (model invocation, agent updates, knowledge base access) from the same + identity or the newly granted principal. + - Check for prior enumeration of Bedrock resources or other recent IAM/resource-policy changes. + + +*False positive analysis* + + +- **Planned access management**: Legitimate sharing or onboarding may add or remove resource policies. + Validate against change tickets and standard templates. +- **Automation**: IaC or platform pipelines may set or remove resource policies during deployment. Confirm + the actor matches known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, revert the resource policy to its approved state and remove any external + or overly permissive principals. +- Disable or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for further + access grants or persistence. +- Restrict `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy` to administrative roles and + enforce least-privilege resource policies. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "success" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc new file mode 100644 index 0000000000..3e0574bee9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent]] +=== AWS Bedrock Third-Party or External Knowledge Base Associated to Agent + +Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Third-Party or External Knowledge Base Associated to Agent* + + +Amazon Bedrock agents use knowledge bases to retrieve content that is injected into the model's context as +trusted, authoritative information (Retrieval-Augmented Generation). The `AssociateAgentKnowledgeBase`, and +`UpdateAgentKnowledgeBase` actions change which knowledge base an agent trusts. Because the model consumes this +content as ground truth, redirecting an agent toward an externally controlled or attacker-supplied knowledge base +is a supply-chain and indirect prompt-injection delivery vector — distinct from poisoning the content of a knowledge +base the agent already trusts. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, and `source.ip`. + - Confirm a related change request exists (RAG pipeline change, agent onboarding, model improvement work). +- **Validate the association** + - In `aws.cloudtrail.flattened.request_parameters`, identify the `agentId`, `knowledgeBaseId`, and any third-party + or external endpoint/configuration referenced. + - Confirm the knowledge base and its underlying data source are owned by your organization and not an external account. +- **Assess blast radius** + - Determine which applications or users invoke the affected agent and what sensitivity of decisions it drives. + - Check `aws.cloudtrail.flattened.response_elements` for the resulting association state. +- **Correlate activity** + - Look for preceding enumeration (`ListAgents`, `ListKnowledgeBases`, `GetAgent`) or creation of new knowledge + bases and data sources from the same identity. + + +*False positive analysis* + + +- **Planned RAG changes**: ML/platform teams routinely associate or update knowledge bases. Validate via ticket + and confirm the resource is an approved, organization-owned knowledge base. +- **Automation**: IaC or CI/CD pipelines may manage agent–knowledge base associations during deployment. + + +*Response and remediation* + + +- If unauthorized, dissociate the knowledge base from the agent and restore the approved configuration. +- Review the associated knowledge base and its data source for attacker-controlled or external content; quarantine if suspect. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:AssociateAgentKnowledgeBase`, `bedrock:UpdateAgentKnowledgeBase`, and third-party association + permissions to a small set of trusted roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "AssociateAgentKnowledgeBase" or + "UpdateAgentKnowledgeBase" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc new file mode 100644 index 0000000000..0837419581 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-unauthorized-foundation-model-access-attempt]] +=== AWS Bedrock Unauthorized Foundation Model Access Attempt + +Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*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 AWS Bedrock Unauthorized Foundation Model Access Attempt* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap. +- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted. +- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts. +- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity. + + +*False positive analysis* + + +- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows. +- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "failure" + and aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc new file mode 100644 index 0000000000..5872ac6af6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-unauthorized-resource-based-policy-modification-attempt]] +=== AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt + +Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy +that grants an external principal access for persistence or cross-account access, or delete a policy to break +existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied +(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform — +a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not +take effect. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an + identity that should never touch these APIs is more suspicious than one from an admin with a transient gap. +- **Assess the attempt** + - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason. + - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. +- **Correlate activity** + - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission + enumeration or escalation attempts. + - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related + resources, and review any IAM changes in the surrounding window. + + +*False positive analysis* + + +- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may + generate transient denials. Validate against change tickets and known automation. +- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and + identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in + `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access + grants, permission changes, or other persistence attempts. +- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied + and successful calls. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "failure" and + aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc new file mode 100644 index 0000000000..a6279826a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-26-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered]] +=== AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered + +Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelImportJob.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-import.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered* + + +Amazon Bedrock allows organizations to import custom models, deploy them, and register marketplace model endpoints for inference. Each of these paths introduces a model artifact that did not necessarily originate from the organization's trusted training and approval pipeline. Adversaries who can import a backdoored or poisoned model — or register an untrusted marketplace endpoint — can influence the output of any downstream application that invokes that model, constituting a supply-chain compromise. This detection identifies `CreateModelImportJob`, `CreateCustomModelDeployment`, `CreateMarketplaceModelEndpoint`, and `RegisterMarketplaceModelEndpoint` calls so responders can verify model provenance before the model is trusted for inference. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm whether a related change request or model onboarding ticket exists. + - Determine if the identity is an approved ML/MLOps role or automation principal. +- **Validate the model artifact source** + - In `aws.cloudtrail.flattened.request_parameters`, review the model source location (e.g., the S3 URI for an import job) and confirm the bucket belongs to your organization and is not attacker-controlled. + - For marketplace endpoints, confirm the model package ARN / product corresponds to an approved vendor. +- **Correlate activity** + - Look for subsequent `InvokeModel` / `InvokeModelWithResponseStream` activity targeting the new model or endpoint. + - Check for prior enumeration such as `ListFoundationModels`, `ListCustomModels`, or `ListImportedModels`. + - Review other recent actions by the same identity for signs of broader compromise. + + +*False positive analysis* + +- **Planned model onboarding**: ML teams routinely import models and register endpoints. Validate against a ticket and confirm the artifact source. +- **Automation**: IaC or MLOps pipelines may create these resources during deployment. Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + +- **If unauthorized** + - Delete or disable the imported model, custom model deployment, or marketplace endpoint. + - Prevent downstream applications from invoking the untrusted model until provenance is established. + - Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and rotate credentials if compromise is suspected. + - Audit the S3 source bucket for tampering and review the model artifact for backdoors. +- **Hardening** + - Restrict `bedrock:CreateModelImportJob`, `bedrock:CreateCustomModelDeployment`, and marketplace endpoint creation/registration permissions to approved roles. + - Enforce that model artifacts originate only from organization-owned, controlled S3 locations. + + +*Additional information* + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "CreateModelImportJob" or + "CreateCustomModelDeployment" or + "CreateMarketplaceModelEndpoint" or + "RegisterMarketplaceModelEndpoint" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Implant Internal Image +** ID: T1525 +** Reference URL: https://attack.mitre.org/techniques/T1525/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-event-source-mapping-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-event-source-mapping-creation.asciidoc new file mode 100644 index 0000000000..ffb962256d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-event-source-mapping-creation.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-26-aws-lambda-event-source-mapping-creation]] +=== AWS Lambda Event Source Mapping Creation + +Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html +* https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Event Source Mapping Creation* + + +AWS Lambda event source mappings poll an event source (Amazon SQS, Kinesis or DynamoDB streams, Amazon MSK or self-managed Kafka, or Amazon MQ) and invoke a target function as records arrive. Creating a mapping is a low-frequency, high-impact configuration change: it can establish event-driven persistence and execution, or quietly relay sensitive records from a stream or queue into attacker-controlled code. + +This rule detects successful `CreateEventSourceMapping` calls. Investigate whether the principal, the target function, and the event source are expected for the environment. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine whether the call came from the console, CLI, SDK, or automation. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`/`functionArn` and the `eventSourceArn` to identify the target function and the source queue, stream, topic, or broker. +- Determine whether the target function and the event source belong to the same application and account, and whether the function code, role, and recent changes are trusted (correlate with `CreateFunction`, `UpdateFunctionCode`, and `AddPermission`). +- Review whether the event source contains sensitive data (for example a DynamoDB stream or SQS queue carrying business records) that the mapping could be used to exfiltrate. +- Pivot on the same principal and access key for other recent Lambda, IAM, or data-plane activity. + + +*False positive analysis* + + +- Event source mappings are a normal building block of serverless data pipelines and queue/stream consumers. Mappings created by approved deployment roles, CI/CD pipelines, or application teams are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the mapping is unauthorized, disable or delete it (`DeleteEventSourceMapping`) and review the target function's code, configuration, and execution role. +- Determine whether records were processed by the function while the mapping was active and assess potential data exposure. +- Rotate or restrict credentials for the principal that created the mapping if compromise is suspected, and constrain `lambda:CreateEventSourceMapping` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html[AWS Lambda event source mappings] +- https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html[CreateEventSourceMapping API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: CreateEventSourceMapping* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-deletion.asciidoc new file mode 100644 index 0000000000..60f6afedd9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-deletion.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-26-aws-lambda-function-deletion]] +=== AWS Lambda Function Deletion + +Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Deletion* + + +Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a backdoor function and erase evidence after their objective is met. + +This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are expected, and whether the deletion correlates with other suspicious activity. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and environment (prod, staging, dev). +- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy operation by comparing `@timestamp` against deployment and change-management records. +- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions. +- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a single planned change. + + +*False positive analysis* + + +- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and confirm its code, configuration, and execution role match a known-good state. +- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html[DeleteFunction API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: (DeleteFunction or DeleteFunction20*) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc new file mode 100644 index 0000000000..76a26d7113 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-26-aws-lambda-function-policy-updated-to-allow-cross-account-invocation]] +=== AWS Lambda Function Policy Updated to Allow Cross-Account Invocation + +Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Cross-Account Invocation* + + +AWS Lambda resource policies control which principals may invoke a function. `AddPermission` granting `lambda:InvokeFunction` to a principal in another AWS account creates a cross-account invocation path. Adversaries use this to maintain execution access or to relay function output to infrastructure they control, without changing the function code that defenders typically scrutinize. + +This rule detects grants of invoke permission to a specific external account, excluding public grants (handled by the related public-invocation rule) and AWS service principals used for normal event triggers. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`, the `action` granted, and the `principal` account id receiving access; confirm whether that account is known and trusted. +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the change was made. +- Determine whether the function processes or has access to sensitive data that the external account could now reach. +- Correlate with other activity by the same principal, including function code or configuration changes and additional policy modifications. +- Verify whether the cross-account grant aligns with an approved integration or change request. + + +*False positive analysis* + + +- Multi-account architectures and partner integrations legitimately grant cross-account invoke permissions. Confirm the grant is approved and exclude known trusted account ids or service roles on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the grant is unauthorized, remove the statement from the function's resource policy (`RemovePermission`) and review the function's code, configuration, and execution role. +- Determine whether the external account invoked the function while the grant was in place and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html[Lambda resource-based policies] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html[AddPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and not stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + and not stringContains(aws.cloudtrail.request_parameters, ".amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-url-created-with-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-url-created-with-public-access.asciidoc new file mode 100644 index 0000000000..8a2b7449b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-function-url-created-with-public-access.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-26-aws-lambda-function-url-created-with-public-access]] +=== AWS Lambda Function URL Created with Public Access + +Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html +* https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function URL Created with Public Access* + + +A Lambda function URL is a dedicated HTTPS endpoint for a function. When configured with `authType=NONE`, anyone on the internet can invoke the function without AWS authentication. Adversaries use this to create a public, persistent entry point for command and control, data exfiltration, or running attacker-controlled code without needing AWS credentials. + +This rule detects successful `CreateFunctionUrlConfig` and `UpdateFunctionUrlConfig` calls where the auth type is set to NONE. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and the auth type, and review `aws.cloudtrail.response_elements` for the resulting `functionUrl`. +- Determine whether the function is intended to be public and whether the owning team requested an unauthenticated endpoint. +- Review the function's code, execution role, and recent changes (`UpdateFunctionCode`, `UpdateFunctionConfiguration`, `AddPermission`) for signs of tampering. +- Correlate with other activity by the same principal, and check the function's invocation and access logs for traffic from unexpected sources after the URL was exposed. + + +*False positive analysis* + + +- Public webhooks, simple APIs, and front-end integrations sometimes use unauthenticated function URLs intentionally. Confirm the exposure is approved and exclude known public endpoints on `functionName` or `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the exposure is unauthorized, change the function URL auth type to `AWS_IAM` or delete the function URL configuration, and review the function code and execution role for compromise. +- Examine invocation logs for unauthenticated requests received while the URL was public and assess potential impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:CreateFunctionUrlConfig` and `lambda:UpdateFunctionUrlConfig` to trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html[Lambda function URLs] +- https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html[Security and auth model for Lambda function URLs] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and (event.action : "CreateFunctionUrlConfig*" or event.action : "UpdateFunctionUrlConfig*") + and stringContains(aws.cloudtrail.request_parameters, "authType=NONE") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-layer-shared-externally.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-layer-shared-externally.asciidoc new file mode 100644 index 0000000000..a0368aae7f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-aws-lambda-layer-shared-externally.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-26-aws-lambda-layer-shared-externally]] +=== AWS Lambda Layer Shared Externally + +Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Layer Shared Externally* + + +AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. `AddLayerVersionPermission` modifies a layer version's permission policy to allow another AWS account, an organization, or the public (`principal=*`) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer. + +This rule detects successful `AddLayerVersionPermission` calls. Public grants (`principal=*`) are the highest concern; specific cross-account grants should be validated against approved sharing. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `layerName`, version number, `action`, and the granted `principal` (a specific account id, an organization id, or `*` for public). +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the grant was made. +- Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved. +- Identify which functions reference the layer and whether the grant could influence their runtime. +- Correlate with other activity by the same principal, such as layer publication (`PublishLayerVersion`) or function changes. + + +*False positive analysis* + + +- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on `aws.cloudtrail.user_identity.arn` or the layer name after validation. + + +*Response and remediation* + + +- If the sharing is unauthorized, remove the layer permission (`RemoveLayerVersionPermission`) and rotate any secrets that may have been exposed in the layer. +- Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddLayerVersionPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html[AWS Lambda layers] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html[AddLayerVersionPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: AddLayerVersionPermission* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..acf725e7e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-suspicious-user-agent.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-26-azure-ad-graph-access-with-suspicious-user-agent]] +=== Azure AD Graph Access with Suspicious User-Agent + +Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 9m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools +* https://www.sophos.com/en-us/research/tampering-with-conditional-access-policies-using-azure-ad-graph-api +* https://github.com/gerenios/aadinternals + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Suspicious User-Agent* + + +Azure AD Graph (graph.windows.net) is the legacy directory REST API that Microsoft has been retiring for years. +Legitimate first-party traffic against it is dominated by a small set of recognisable user agents (`Microsoft.OData.Client`, +`Microsoft Azure Graph Client Library`, `Microsoft ADO.NET Data Services`, the Azure portal with a Chrome user agent, +and an empty-UA tail from first-party AppIds). Traffic identifying as Python, aiohttp, curl, Go-http-client, or any +of the `*hound` enumeration families is almost always either a developer prototype or adversary tooling. This rule +flags any such request even at a single event, because tooling samples for AAD Graph are inherently low-volume in +normal tenants. + + +*Possible investigation steps* + + +- Confirm the matching user agent. + - `user_agent.original` (e.g., `aiohttp`, `AADInternals`, `curl`, `bav2ropc`). +- Identify the caller and the calling client. + - `user.id` for the caller, `azure.aadgraphactivitylogs.properties.app_id` for the OAuth client. +- Review which directory object types were touched. + - `url.path` (e.g., `/users`, `/policies`, `/servicePrincipals`). +- Check the success / failure pattern. + - `http.response.status_code`. Many 4xx responses suggest permission probing. +- Cross-reference with the API version. + - `azure.aadgraphactivitylogs.properties.api_version`. A non-Microsoft UA combined with `1.6-internal` or `1.61-internal` is a stronger signal of offensive tooling. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the token was obtained. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration (Azure Event Hub). Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and azure.aadgraphactivitylogs.properties.actor_type == "User" + and user_agent.original is not null +| eval Esql.ua_lower = to_lower(user_agent.original) +| where Esql.ua_lower like "*fasthttp*" + or Esql.ua_lower like "*aiohttp*" + or Esql.ua_lower like "*hound*" + or Esql.ua_lower like "*aadinternals*" + or Esql.ua_lower like "*go-http-client*" + or Esql.ua_lower like "python*" + or Esql.ua_lower like "*curl/*" + or Esql.ua_lower like "*okhttp*" + or Esql.ua_lower like "*axios*" + or Esql.ua_lower like "*node-fetch*" + or Esql.ua_lower like "*go-resty*" + or Esql.ua_lower like "*bav2ropc*" + or Esql.ua_lower like "*undici*" +| keep + _id, + _version, + _index, + @timestamp, + user.id, + source.ip, + source.as.organization.name, + user_agent.original, + azure.aadgraphactivitylogs.properties.app_id, + azure.aadgraphactivitylogs.properties.api_version, + url.path, + http.response.status_code, + azure.tenant_id, + Esql.ua_lower + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-unusual-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-unusual-client-and-user.asciidoc new file mode 100644 index 0000000000..8976a4c88b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-access-with-unusual-client-and-user.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-26-azure-ad-graph-access-with-unusual-client-and-user]] +=== Azure AD Graph Access with Unusual Client and User + +Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.aadgraphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/secureworks/family-of-client-ids-research +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Unusual Client and User* + + +A (client, user) pair appearing on AAD Graph for the first time in 14 days is a high-signal indicator. Legacy +AAD Graph traffic is dominated by a small set of recognised first-party callers per user; new combinations +suggest one of: + +- A FOCI refresh-token swap landed under a new client identity. +- The user newly consented to (or was phished into consenting to) an OAuth application. +- An adversary is using stolen tokens / credentials under a client identity the user does not normally use. + + +*Possible investigation steps* + + +- Identify the calling client and confirm whether the app is sanctioned. + - `azure.aadgraphactivitylogs.properties.app_id`. Pivot to Azure portal → Enterprise Applications to check whether it is first-party, sanctioned third-party, or unfamiliar. +- Identify the user and check the surrounding auth context. + - `user.id`, then pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user around the same time. Look for unusual sign-in geography, MFA bypass, or risky session signals. +- Review source posture. + - `user_agent.original`, `source.ip`, `source.as.organization.name`. Residential / VPS / anonymising-network egress raises priority. +- Review what was queried. + - `url.path`. Bulk recon or User-collection access via internal API versions raises triage priority. +- Check tenant-wide blast radius for the client. + - Is the same client ID hitting AAD Graph for many other users? That pattern points to large-scale consent abuse rather than a single account compromise. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the client is not a sanctioned application, revoke its OAuth consent. + - `GET /v1.0/oauth2PermissionGrants?$filter=clientId eq '{servicePrincipalId}'`, then `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.aadgraphactivitylogs" and + azure.aadgraphactivitylogs.properties.actor_type : "User" and + azure.aadgraphactivitylogs.properties.app_id: (* and not ( + "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "bb8f18b0-9c38-48c9-a847-e1ef3af0602d" or + "00000006-0000-0ff1-ce00-000000000000" or + "18ed3507-a475-4ccb-b669-d66bc9f2a36e") + ) and user.id:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc new file mode 100644 index 0000000000..3afe5249a2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-26-azure-ad-graph-high-4xx-error-ratio-from-user]] +=== Azure AD Graph High 4xx Error Ratio from User + +Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://aadinternals.com/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph High 4xx Error Ratio from User* + + +A high 4xx rate on AAD Graph from a single calling identity is consistent with automated permission probing, +recon against endpoints the caller is not authorized for, or a token whose client has been blocked from AAD +Graph. The pattern is structurally distinct from sparse 4xx in first-party traffic. + + +*Possible investigation steps* + + +- Confirm the surge volume and ratio. + - Review `Esql.error_rate` (4xx as a fraction of total) and `Esql.total_calls` to assess the magnitude. +- Identify the caller and calling client. + - `user.id` for the calling identity, `source.ip` for the egress, and `Esql.app_ids` (from `azure.aadgraphactivitylogs.properties.app_id`) for the OAuth client. +- Review which endpoints produced the errors. + - `Esql.sample_paths` captures the distinct `url.path` values that 4xx'd. +- Correlate with successful calls from the same user / source to understand what reached AAD Graph. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source for token-mint context. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user if the surge indicates unauthorized recon. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" +| eval Esql.is_4xx = case( + http.response.status_code >= 400 and + http.response.status_code < 500, 1, 0 + ) +| eval Esql.time_window = date_trunc(2 minutes, @timestamp) +| stats + Esql.total_calls = count(*), + Esql.azure_tenants = values(azure.tenant_id), + Esql.errors = sum(Esql.is_4xx), + Esql.url_path_count = count_distinct(url.path), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.source_ips = values(source.ip), + Esql.source_asn_name = values(source.as.organization.name), + Esql.user_agents = values(user_agent.original), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + source.as.number, + Esql.time_window +| eval Esql.error_rate = round(Esql.errors * 1.0 / Esql.total_calls, 2) +| where + Esql.total_calls > 20 and Esql.errors >= 10 and + Esql.error_rate >= 0.4 and Esql.url_path_count >= 15 +| keep + user.id, + source.as.number, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-potential-enumeration-roadrecon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-potential-enumeration-roadrecon.asciidoc new file mode 100644 index 0000000000..002c860b3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-ad-graph-potential-enumeration-roadrecon.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-26-azure-ad-graph-potential-enumeration-roadrecon]] +=== Azure AD Graph Potential Enumeration (ROADrecon) + +Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/dirkjanm/ROADtools/blob/master/roadrecon/roadtools/roadrecon/gather.py +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Potential Enumeration (ROADrecon)* + + +This is an ES|QL aggregation rule. Alert documents contain summarized fields per burst window: the calling identity, the tenant, and a one-minute bucket. The alert itself is the signal that something resembling ROADrecon's `gather` walk happened against AAD Graph; the actual investigation happens against the raw `logs-azure.aadgraphactivitylogs-*` events for the same identity and window. + + +*Possible investigation steps* + + +- Confirm the burst by filtering raw AAD Graph activity for the alerting user, tenant, and time window. + - Filter `logs-azure.aadgraphactivitylogs-*` on the alerting user, tenant, and burst window. + - ROADrecon's full `gather` walks ~16 directory collections; five or more in a single minute is the structural fingerprint. +- Tool fingerprint: aiohttp UA plus the hardcoded internal API version. + - `user_agent.original` contains `aiohttp`. + - `api_version = 1.61-internal` (hardcoded in `gather.py`, returns internal-only fields like `strongAuthenticationDetail`). + - No first-party Microsoft component identifies as aiohttp or pins `1.61-internal`. +- Calling client + auth method: the typical device-code-flow ROADrecon entrypoint. + - ROADrecon is usually pointed at the Azure CLI client (`04b07795-…`) via the `-c` flag. + - Uses a public-client auth method (no client secret or certificate). +- HTTP shape distinguishes enumeration from operator follow-on. + - `gather` reads only, so GETs dominate. + - A 403/404 tail indicates the identity probing endpoints it lacks permission for. + - PATCH / POST / DELETE in the same burst means the operator did more than enumerate. +- Source posture: residential ISP, generic VPS, or anonymising-network egress raises triage priority. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) via the sign-in correlation ID on each AAD Graph event to land on the originating token-mint. +- Pivot to audit logs (`logs-azure.auditlogs-*`) for any directory writes by the same user near the burst that suggest persistence or modification activity. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + - Check for red team engagement, penetration test, or internal tooling validation. + - Validate against the engagement window and the operator's known source range. + + +*Response and remediation* + + +- Enumerate device registrations created by the user during or around the burst window. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`. + - De-register anything not attributable to a known endpoint via `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Audit OAuth grants and app role assignments the user holds; revoke anything minted from a kit-egress or otherwise suspicious source. + - `GET /v1.0/oauth2PermissionGrants?$filter=principalId eq '{id}'`, revoke via `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. + - `GET /v1.0/users/{id}/appRoleAssignments`, revoke via `DELETE /v1.0/servicePrincipals/{spId}/appRoleAssignedTo/{assignmentId}`. +- Reset the user's password and audit authentication methods added during the window. + - `GET /v1.0/users/{id}/authentication/methods` to list. + - Remove anything unexpected via the method-type-specific endpoint. +- Audit directory writes by the user near the burst and roll back unauthorized changes. + - Query `logs-azure.auditlogs-*` for `Register device`, `Update user`, `User registered security info`, role assignment activity by the same user in the window. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and to_lower(user_agent.original) like "*aiohttp*" + +| eval Esql.target_endpoints = case( + url.path like "*/eligibleRoleAssignments*", "eligibleRoleAssignments", + url.path like "*/roleAssignments*", "roleAssignments", + url.path like "*/users*", "users", + url.path like "*/groups*", "groups", + url.path like "*/servicePrincipals*", "servicePrincipals", + url.path like "*/applications*", "applications", + url.path like "*/devices*", "devices", + url.path like "*/directoryRoles*", "directoryRoles", + url.path like "*/roleDefinitions*", "roleDefinitions", + url.path like "*/administrativeUnits*", "administrativeUnits", + url.path like "*/contacts*", "contacts", + url.path like "*/oauth2PermissionGrants*", "oauth2PermissionGrants", + url.path like "*/authorizationPolicy*", "authorizationPolicy", + url.path like "*/settings*", "settings", + url.path like "*/policies*", "policies", + url.path like "*/tenantDetails*", "tenantDetails", + "other" + ) +| where Esql.target_endpoints != "other" + +| eval Esql.time_window = date_trunc(1 minutes, @timestamp) + +| stats + Esql.request_count = count(*), + Esql.distinct_endpoints = count_distinct(Esql.target_endpoints), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.user_agent = values(user_agent.original), + Esql.http_methods = values(http.request.method), + Esql.status_codes = values(http.response.status_code), + Esql.source_ips = values(source.ip), + Esql.source_asn_orgs = values(source.`as`.organization.name), + Esql.source_countries = values(source.geo.country_name), + Esql.actor_types = values(azure.aadgraphactivitylogs.properties.actor_type), + Esql.client_auth_methods = values(azure.aadgraphactivitylogs.properties.client_auth_method), + Esql.session_ids = values(azure.aadgraphactivitylogs.properties.session_id), + Esql.sign_in_activity_ids = values(azure.aadgraphactivitylogs.properties.sign_in_activity_id), + Esql.scopes = values(azure.aadgraphactivitylogs.properties.scopes), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + azure.tenant_id, + Esql.time_window + +| where Esql.distinct_endpoints >= 5 + +| keep + user.id, + azure.tenant_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-compute-vm-command-executed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-compute-vm-command-executed.asciidoc new file mode 100644 index 0000000000..165a5ae813 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-compute-vm-command-executed.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-26-azure-compute-vm-command-executed]] +=== Azure Compute VM Command Executed + +Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://adsecurity.org/?p=4277 +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute VM Command Executed* + + +Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name values "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" and "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Identify the VM in question via the `azure.resource.name` field. This can aid with pivoting into endpoint analysis of the commands executed. +- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed. +- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM. +- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies. +- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement. +- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations. + + +*False positive analysis* + + +- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed. +- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts. +- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection. +- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. +- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes. + + +*Response and remediation* + + +- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern. +- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles. +- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary. +- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised. +- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION" + ) and event.outcome:(Success or success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * and + source.as.number: * and + azure.resource.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-boot-diagnostics-retrieved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-boot-diagnostics-retrieved.asciidoc new file mode 100644 index 0000000000..bd62df437e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-boot-diagnostics-retrieved.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-26-azure-vm-boot-diagnostics-retrieved]] +=== Azure VM Boot Diagnostics Retrieved + +Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.microsoft.com/en-us/msrc/blog/2023/08/azure-serial-console-attack-and-defense-part-1 +* https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Boot Diagnostics Retrieved* + + +Retrieving boot diagnostics (`retrieveBootDiagnosticsData/action`) returns SAS URIs to the VM serial console log and a +console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and +sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no +guest footprint, and bypasses NSG/JIT. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. Service principal or + managed identity retrieval is more suspicious than a known support user. +- Review the source: `source.ip`, `source.as.number`, `source.as.organization.name`, `source.geo.country_name`. + Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress. +- Inspect `azure.resource.id` / `azure.resource.name` to identify the target VM. Was the same principal recently granted + access to it, or is this their first interaction? +- Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the + VM or subscription? + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or + other secrets that now require rotation. +- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence. + + +*Response and remediation* + + +- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke + the principal's access if compromised. +- Collect activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION" and + event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..a300c16867 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-26-azure-vm-extension-crud-operation-with-unusual-source-asn]] +=== Azure VM Extension CRUD Operation with Unusual Source ASN + +Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension CRUD Operation with Unusual Source ASN* + + +Azure VM and VM scale set extensions (for example CustomScript, DSC, and AADSSHLoginForLinux) execute on the guest with +high privilege. Creating or updating an extension (`EXTENSIONS/WRITE`) can run attacker-supplied code as SYSTEM or root, +while deleting one (`EXTENSIONS/DELETE`) can remove security tooling or clean up after execution. This rule uses a new +terms approach keyed on the pair (`azure.resource.name`, `source.as.number`), so it fires when a given extension resource +is operated on from a source network that has not been seen managing it within the history window. Well-known Microsoft +AS numbers used by first-party automation are excluded in the query. + + +*Triage checklist* + + +- Identify the source via `source.ip`, `source.as.number`, and `source.as.organization.name`. Operations from cloud + hosting, VPS, or anonymizing networks are more suspicious than known corporate egress. +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. +- Inspect `azure.resource.id` for the target VM/VMSS and `azure.resource.name` for the extension. CustomScript/DSC + extensions and randomly named extensions warrant closer review. +- Determine the operation: WRITE (create/update — code execution) vs DELETE (removal — possible defense evasion or + cleanup). +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the operation timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the extension settings/protected settings from the VM (the activity log does not contain the script body) to + assess intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following the operation. + + +*Response and remediation* + + +- If unauthorized, remove the malicious extension, isolate the VM, rotate credentials reachable from it, and review RBAC + on the affected scope. +- Block or investigate the source AS/network if it is not an expected management path. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/WRITE" + ) and event.outcome:(Success or success) and + azure.resource.name:* and + source.as.number:(* and not (3598 or 8068 or 8069 or 8070 or 8071 or 8072 or 8073 or 8074 or 8075 or 12076)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc new file mode 100644 index 0000000000..6683dcf47f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-26-azure-vm-managed-run-command-created-or-updated-with-unusual-principal]] +=== Azure VM Managed Run Command Created or Updated with Unusual Principal + +Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Managed Run Command Created or Updated with Unusual Principal* + + +The managed Run Command (`runCommands/write`) creates or updates a persistent run command resource on a VM or VM scale +set. Creating the resource executes the supplied script as SYSTEM (Windows) or root (Linux). This rule uses a new terms +approach keyed on the acting principal, so it fires the first time a given identity performs this operation within the +history window. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal or + managed identity activity is more suspicious than a known admin user. +- Is the source IP/ASN consistent with corporate infrastructure or a known VPN? +- Inspect `azure.resource.id` for the target VM/VMSS and the run command resource name. Attacker-created names are often + random or descriptive of intent. +- Did the same principal recently perform reconnaissance, role assignments, or other VM operations + (`runCommand/action`, `extensions/write`, serial console connect)? +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the write timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the run command script content from the VM (the activity log does not contain the script body) to assess + intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following execution. + + +*Response and remediation* + + +- If unauthorized, delete the managed run command resource, isolate the VM, rotate credentials reachable from it, and + review RBAC on the affected scope. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMANDS/WRITE" + ) and event.outcome:(success or Success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..0a5fba54fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-26-azure-vm-serial-console-connection-with-unusual-user-and-asn]] +=== Azure VM Serial Console Connection with Unusual User and ASN + +Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-overview +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Serial Console Connection with Unusual User and ASN* + + +The Azure Serial Console gives text-based console access to a VM over the boot diagnostics serial port. It works even +when the VM has no inbound network connectivity, so a session bypasses NSGs, JIT, and other network controls. This rule +flags successful `MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION` operations where the combination of acting +principal and source ASN has not been seen in the history window. + +This rule uses a new terms approach keyed on the acting principal and source ASN, so it surfaces a +known identity connecting from an unusual network as well as any new identity using the Serial Console. + + +*Triage checklist* + + +- Identify the caller via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal + Serial Console access is unusual and warrants scrutiny. +- Review `source.as.organization.name`, `source.as.number`, and `source.geo.country_name` - is the network a known + corporate/VPN ASN or an unexpected hosting/residential provider? +- Was the connect preceded by reconnaissance, role assignment changes, or Run Command / extension activity on the same VM? +- Were there preceding failed Serial Console connect attempts (`event.outcome:failure`) suggesting access probing? +- Does the target VM normally require Serial Console access, or is it a production system that should be reachable over + the network? + + +*Possible investigation steps* + + +- Review `azure.resource.id` to identify the VM and confirm boot diagnostics is enabled. +- Correlate with Entra ID sign-in logs for the caller and review MFA / conditional access posture. +- Pivot on the VM for endpoint telemetry around the connect timestamp (interactive shell, new local accounts, credential + access) since Serial Console sessions execute as SYSTEM/root. +- Review the principal's RBAC role assignments on the subscription, resource group, and VM. + + +*Response and remediation* + + +- If unauthorized, terminate the session, rotate credentials reachable from the VM, and review RBAC on the affected scope. +- Consider disabling the subscription-level Serial Console where it is not operationally required. +- Isolate the VM and collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:"MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION" and + event.outcome:("success" or "Success") and + azure.activitylogs.identity.authorization.evidence.principal_id:* and + source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Sub-technique: +** Name: Direct Cloud VM Connections +** ID: T1021.008 +** Reference URL: https://attack.mitre.org/techniques/T1021/008/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc new file mode 100644 index 0000000000..09eee39a1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc @@ -0,0 +1,254 @@ +[[prebuilt-rule-8-19-26-deprecated-linux-restricted-shell-breakout-via-linux-binary-s]] +=== Deprecated - Linux Restricted Shell Breakout via Linux Binary(s) + +Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/apt/ +* https://gtfobins.github.io/gtfobins/apt-get/ +* https://gtfobins.github.io/gtfobins/nawk/ +* https://gtfobins.github.io/gtfobins/mawk/ +* https://gtfobins.github.io/gtfobins/awk/ +* https://gtfobins.github.io/gtfobins/gawk/ +* https://gtfobins.github.io/gtfobins/busybox/ +* https://gtfobins.github.io/gtfobins/c89/ +* https://gtfobins.github.io/gtfobins/c99/ +* https://gtfobins.github.io/gtfobins/cpulimit/ +* https://gtfobins.github.io/gtfobins/crash/ +* https://gtfobins.github.io/gtfobins/env/ +* https://gtfobins.github.io/gtfobins/expect/ +* https://gtfobins.github.io/gtfobins/find/ +* https://gtfobins.github.io/gtfobins/flock/ +* https://gtfobins.github.io/gtfobins/gcc/ +* https://gtfobins.github.io/gtfobins/mysql/ +* https://gtfobins.github.io/gtfobins/nice/ +* https://gtfobins.github.io/gtfobins/ssh/ +* https://gtfobins.github.io/gtfobins/vi/ +* https://gtfobins.github.io/gtfobins/vim/ +* https://gtfobins.github.io/gtfobins/capsh/ +* https://gtfobins.github.io/gtfobins/byebug/ +* https://gtfobins.github.io/gtfobins/git/ +* https://gtfobins.github.io/gtfobins/ftp/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - Linux Restricted Shell Breakout via Linux Binary(s)* + +Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or +environments by spawning an interactive system shell. +Here are some possible avenues of investigation: +- Examine the entry point to the host and user in action via the Analyse View. + - Identify the session entry leader and session user +- Examine the contents of session leading to the abuse via the Session View. + - Examine the command execution pattern in the session, which may lead to suspricous activities +- Examine the execution of commands in the spawned shell. + - Identify imment threat to the system from the executed commands + - Take necessary incident response actions to contain any malicious behviour caused via this execution. + + +*Related rules* + + +- A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences. +- Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment + + +*Response and remediation* + + +Initiate the incident response process based on the outcome of the triage. + +- If the triage releaved suspicious netwrok activity from the malicious spawned shell, + - Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware execution via the maliciously spawned shell, + - Search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- If the triage revelaed defence evasion for imparing defenses + - Isolate the involved host to prevent further post-compromise behavior. + - Identified the disabled security guard components on the host and take necessary steps in renebaling the same. + - If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same. +- If the triage revelaed addition of persistence mechanism exploit like auto start scripts + - Isolate further login to the systems that can initae auto start scripts. + - Identify the auto start scripts and disable and remove the same from the systems +- If the triage revealed data crawling or data export via remote copy + - Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling + - Intiate compromised credential deactivation and credential rotation process for all exposed crednetials. + - Investiagte if any IPR data was accessed during the data crawling and take appropriate actions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. + +*To confirm that Session View data is enabled:* + +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and process.executable != null and +( + /* launching shell from capsh */ + (process.name == "capsh" and process.args == "--" and not process.parent.executable == "/usr/bin/log4j-cve-2021-44228-hotpatch") or + + /* launching shells from unusual parents or parent+arg combos */ + (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or + (process.parent.name == "git" and process.parent.args : ("!*sh", "exec *sh") and not process.name == "ssh" ) or + (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and + ( + process.parent.args : "BEGIN {system(*)}" or + ( + (process.parent.args : "exec=*sh" or (process.parent.args : "-I" and process.parent.args : "*sh")) or + (process.args : "exec=*sh" or (process.args : "-I" and process.args : "*sh")) + ) + ) + ) or + + /* shells specified in parent args */ + /* nice rule is broken in 8.2 */ + (process.parent.args : "*sh" and + ( + (process.parent.name == "nice") or + (process.parent.name == "cpulimit" and process.parent.args == "-f") or + (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and + process.parent.args == ";" and process.parent.args : "/bin/*sh") or + (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/") + ) + ) + )) or + + /* shells specified in args */ + (process.args : "*sh" and ( + (process.parent.name == "crash" and process.parent.args == "-h") or + (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog") + /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */ + + )) or + (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not + process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and + process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs" and + not process.parent.executable == "/bin/busybox") or + (process.name == "env" and process.args_count == 2 and process.args : "*sh") or + (process.parent.name in ("vi", "vim") and process.parent.args == "-c" and process.parent.args : ":!*sh") or + (process.parent.name in ("c89", "c99", "gcc") and process.parent.args : "*sh,-s" and process.parent.args == "-wrapper") or + (process.parent.name == "expect" and process.parent.args == "-c" and process.parent.args : "spawn *sh;interact") or + (process.parent.name == "mysql" and process.parent.args == "-e" and process.parent.args : "\\!*sh") or + (process.parent.name == "ssh" and process.parent.args == "-o" and process.parent.args : "ProxyCommand=;*sh 0<&2 1>&2") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc new file mode 100644 index 0000000000..4e43959049 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-26-deprecated-mfa-disabled-for-google-workspace-organization]] +=== Deprecated - MFA Disabled for Google Workspace Organization + +Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/7061566 +* 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: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - MFA Disabled for Google Workspace Organization* + + +Multi-factor authentication (MFA) is a process in which users are prompted for an additional form of identification, such as a code on their cell phone or a fingerprint scan, during the sign-in process. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the users's password is weak or has been exposed elsewhere, an attacker could use it to gain access. Requiring a second form of authentication increases security because attackers cannot easily obtain or duplicate the additional authentication factor. + +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197[official documentation]. + +This rule identifies when MFA enforcement is turned off in Google Workspace. This modification weakens account security and can lead to accounts and other assets being compromised. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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. +- Reactivate the multi-factor authentication enforcement. +- Review the permissions assigned to the implicated user 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.provider:admin and event.category:iam and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-domain-added-to-google-workspace-trusted-domains.asciidoc new file mode 100644 index 0000000000..151fc3a1c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-domain-added-to-google-workspace-trusted-domains.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-26-domain-added-to-google-workspace-trusted-domains]] +=== Domain Added to Google Workspace Trusted Domains + +Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6160020?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: Defense Evasion +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Domain Added to Google Workspace Trusted Domains* + + +Google Workspace allowlisted domains define which external organizations users may collaborate with across services such +as Drive, Chat, and Classroom. Adding a domain to this list expands who can receive shared content under the tenant's +trust policies. Threat actors with administrative access may add a domain they operate to bypass out-of-domain sharing +controls and establish a durable path for collection or exfiltration. + +This rule identifies when an administrator adds a domain via the `ADD_TRUSTED_DOMAINS` 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 `source.ip` and `event.ingested` if present in the alert. +- Identify the domain added by reviewing `google_workspace.admin.domain.name`. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or partner onboarding record for the new domain. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Review allowlisted domains in the Google Admin console: + - Navigate to Account > Domains > Allowlisted domains. + - Confirm the domain from `google_workspace.admin.domain.name` appears on the list and whether it is appropriate for your organization's sharing model. +- Assess domain reputation and ownership using external intelligence (for example, VirusTotal or WHOIS) to determine whether the domain is associated with your organization or a known partner. +- Search Kibana for related admin and sharing activity: + - Find other trust or sharing policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ADD_TRUSTED_DOMAINS" or "REMOVE_TRUSTED_DOMAINS") + ``` + - After the add, review Drive events for files shared to users outside your domain: + ``` + data_stream.dataset: "google_workspace.drive" and event.action: ("change_user_access" or "change_document_visibility") + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours. + + +*False positive analysis* + + +- Verify the domain belongs to an approved partner or subsidiary with a documented business need for cross-organization collaboration. +- Adding test or lab domains during migrations is possible — 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 the domain from Allowlisted domains while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Review recent Drive and Chat sharing to external users for sensitive data exposure tied to the newly trusted domain. +- 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_TRUSTED_DOMAINS + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-guest-account-promoted-to-member.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-guest-account-promoted-to-member.asciidoc new file mode 100644 index 0000000000..998ed38ad1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-guest-account-promoted-to-member.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-26-entra-id-guest-account-promoted-to-member]] +=== Entra ID Guest Account Promoted to Member + +Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/external-id/user-properties +* https://learn.microsoft.com/en-us/entra/identity/users/convert-external-users-internal + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Guest Account Promoted to Member* + + +A Guest-to-Member UserType conversion is a rarely needed, high-impact operation that removes all +guest account restrictions. In most tenants it occurs fewer than once per month. + + +*Possible investigation steps* + + +- Identify the administrator who performed the conversion (`azure.auditlogs.properties.initiated_by`) + and verify whether the action was authorized. +- Check when the guest account was originally invited: look for "Invite external user" in AuditLogs + with the same target object ID. +- Review post-conversion sign-in activity in `azure.signinlogs.*` for the target account -- look for + directory enumeration patterns (access to Graph API `/users`, `/groups`, `/applications`). +- Check whether the converting actor's role was recently granted and whether other high-privilege + operations were performed around the same time. + + +*False positive analysis* + + +- Planned B2B-to-member migrations coordinated by HR or IT should be documented in change records. + Confirm via ticket correlation before closing. + + +*Response and remediation* + + +- Revert the UserType to Guest if unauthorized: Entra ID > Users > Edit properties. +- Revoke all sessions for the affected account. +- Review all directory objects the account accessed after the conversion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update user" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "UserType" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value: *Guest* and +azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: *Member* and +event.outcome: (Success or success) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc new file mode 100644 index 0000000000..0ebda750a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-26-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn]] +=== Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN + +Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.app_display_name`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, +`source.as.number`, `source.as.organization.name`, and `user_agent.original`. + +Confirm whether the user intentionally registered or joined a device and whether the source ASN is expected for your +enrollment or remote-access programs. + + +*Possible investigation steps* + + +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins for the same user, especially multi-IP OAuth + flows or follow-on primary refresh token usage. +- Review Entra ID audit logs for device registration activity around the same timestamp. +- Compare `source.as.organization.name` against approved VPN, MDM, and automation egress in your environment. +- Hunt for additional users signing in from the same ASN with the same application pair in a short window. + + +*False positive analysis* + + +- Corporate or consumer VPN exit nodes that use ASNs in the rule list are a common source of benign matches during + standard Windows or mobile device join. +- Cloud hosting or ISP NAT pools may intermittently map to listed ASNs without indicating compromise. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, disable suspicious registered devices, and reset credentials per + policy. +- Review conditional access for the Microsoft Authentication Broker and device registration requirements. +- Escalate per incident procedures when paired with identity protection alerts or impossible travel. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and +source.as.number:( + 399629 or 14061 or 136787 or 9009 or 45102 or 215540 or 29802 or 62240 or 204957 or 395092 or 393406 or 400940 or + 59711 or 132203 +) and +azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" and +azure.signinlogs.properties.resource_display_name:"Device Registration Service" + +---------------------------------- + +*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: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-application-redirect-uri-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-application-redirect-uri-modified.asciidoc new file mode 100644 index 0000000000..4ca1d3de51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-application-redirect-uri-modified.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-26-entra-id-oauth-application-redirect-uri-modified]] +=== Entra ID OAuth Application Redirect URI Modified + +Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity-platform/reply-url +* https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Application Redirect URI Modified* + + +A redirect URI addition to an existing trusted application does not generate a consent event and does +not require registering a new application -- both of which are commonly monitored. The modified +application retains all existing user consents. + + +*Possible investigation steps* + + +- Identify the actor who modified the application (`azure.auditlogs.properties.initiated_by`) and + verify whether the change was authorized by the application owner or a change management ticket. +- Review the specific URIs added by comparing `modifiedProperties.oldValue` and `newValue` for the + `ReplyUrls` field in the audit event's `target_resources`. +- Geolocate and WHOIS the domain of any newly added URI -- hosting providers, recently registered + domains, or URL shorteners are strong indicators of compromise. +- Check whether the actor recently became an owner of this application: look for + "Add owner to application" events in AuditLogs for the same application object ID. +- Review the application's Graph API permissions -- applications with Mail, Files, or directory + scopes are the highest-value targets for redirect URI hijacking. + + +*False positive analysis* + + +- Localhost and loopback URIs (`http://localhost:*`, `http://127.0.0.1:*`) added by developers are + expected in non-production applications. Verify the application's sensitivity before closing. +- CI/CD-driven URI updates typically originate from service principal actors, not human users. + + +*Response and remediation* + + +- Remove the unauthorized redirect URI via Entra ID > App registrations > Authentication. +- Revoke all tokens issued to the application since the modification timestamp. +- Review sign-in logs for the application for any sign-ins from unexpected sources after the change. +- If the URI was externally controlled, treat as a full OAuth token compromise for all users of + the application and initiate token revocation and user notification. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update application" and +event.outcome: ("Success" or "success") and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "AppAddress" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc new file mode 100644 index 0000000000..d8cd18552f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-26-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration]] +=== Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration + +Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.aadgraphactivitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/Gerenios/AADInternals +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration* + + +Device-code phishing redeems an OAuth access token directly into the adversary's hands without +ever touching the victim's password or MFA factor. When the redemption targets the legacy AAD +Graph audience from an unmanaged device, the resulting token is overwhelmingly used to drive +directory recon under the compromised identity. ROADrecon / ROADtools, AADInternals +(`Get-AADIntTenantDetails`, `Get-AADIntUsers`), and manual `roadtx` flows all match this shape. + + +*Possible investigation steps* + + +- Confirm the sign-in shape. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - `azure.signinlogs.properties.resource_id` is `00000002-0000-0000-c000-000000000000` (legacy AAD Graph audience). + - `azure.signinlogs.properties.device_detail.is_managed` is `false`. +- Identify the calling client used to drive the device-code grant. + - `azure.signinlogs.properties.app_id`, `azure.signinlogs.properties.app_display_name`. + - FOCI / pre-consented Microsoft clients (Teams, Office, Azure CLI, Azure PowerShell) are the canonical ride-along clients for device-code phishing because they bypass app consent. +- Review source posture for the redemption and the Graph follow-on independently. + - `source.ip`, `source.as.organization.name`, `source.geo.country_name`. Residential / VPS / anonymising-network egress raises priority. + - A code redeemed from one IP and Graph driven from another is a strong adversary-in-the-middle signal: the user clicked, the attacker is now driving the session. +- Review what was queried on the Graph side. + - `url.path` on the second event. `applicationRefs`, `eligibleRoleAssignments`, and `directoryObjects` casts (`$/Microsoft.DirectoryServices.ServicePrincipal`) are the textbook ROADrecon signature; `tenantDetails` from an `AADInternals` user-agent is the AADInternals signature. +- Check the API version on the Graph call. + - `azure.aadgraphactivitylogs.properties.api_version`. `1.61-internal` is a strong tooling indicator and returns data the public surface withholds (Conditional Access policies, MFA configuration on user objects). +- Pivot to surrounding sign-ins for the same user. Other device-code redemptions to Microsoft Graph, Azure Resource Manager, or Exchange in the same window suggest the attacker is multi-homing the token harvest. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the compromised user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the device-code grant: require a managed / compliant device or block the device-code grant outside of explicitly approved app + user populations. + + +==== Setup + + + +*Microsoft Entra ID Sign-in Logs and Azure AD Graph Activity Logs* + +Requires both data streams ingested via the Elastic Azure integration: +- Microsoft Entra ID sign-in logs into `logs-azure.signinlogs-*` (enable the `SignInLogs` diagnostic-settings category on Entra ID). +- Azure AD Graph Activity Logs into `logs-azure.aadgraphactivitylogs-*` (enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.id, azure.tenant_id with maxspan=5m +[authentication where + data_stream.dataset == "azure.signinlogs" and + event.outcome == "success" and + azure.signinlogs.properties.authentication_protocol == "deviceCode" and + azure.signinlogs.properties.device_detail.is_managed == false and + azure.signinlogs.properties.resource_id == "00000002-0000-0000-c000-000000000000"] +[web where + data_stream.dataset == "azure.aadgraphactivitylogs" and + url.path : ( + "*/users*", + "*/groups*", + "*/servicePrincipals*", + "*/applications*", + "*/applicationRefs*", + "*/devices*", + "*/directoryRoles*", + "*/roleAssignments*", + "*/eligibleRoleAssignments*", + "*/roleDefinitions*", + "*/directoryObjects*", + "*/policies*", + "*/oauth2PermissionGrants*", + "*/administrativeUnits*", + "*/tenantDetails*", + "*/directorySettingTemplates*", + "*/me*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-temporary-access-pass-created-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-temporary-access-pass-created-for-user.asciidoc new file mode 100644 index 0000000000..90376f66e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-entra-id-temporary-access-pass-created-for-user.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-26-entra-id-temporary-access-pass-created-for-user]] +=== Entra ID Temporary Access Pass Created for User + +Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass +* https://dirkjanm.io/lateral-movement-and-hash-dumping-with-temporary-access-passes-microsoft-entra/ +* https://specterops.io/blog/2023/03/29/id-tap-that-pass/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Temporary Access Pass Created for User* + + +A Temporary Access Pass is a time-limited credential that bypasses all existing MFA factors for the +target account. In a steady-state tenant, TAP creation is rare and should be correlated against help +desk records or onboarding workflows. + + +*Possible investigation steps* + + +- Identify the administrator who created the TAP (`azure.auditlogs.properties.initiated_by`) and verify + whether the action was authorized by a help desk ticket or change management record. +- Identify the target account and assess its privilege level -- TAPs issued for Global Administrators, + Application Administrators, or accounts with high-value data access are highest risk. +- Check for sign-ins by the target account using the TAP credential: look for sign-ins where + `azure.signinlogs.properties.authentication_details` contains "Temporary Access Pass" shortly after + the TAP creation event. +- If the TAP was used to sign in, review what authentication methods were registered during or after + the session -- an attacker will use the TAP window to add a persistent authenticator. +- Check whether the creating administrator's account shows anomalous activity in the preceding 24 hours. + + +*False positive analysis* + + +- TAP creation by your identity team for locked-out users is a legitimate workflow. Confirm via help + desk ticket correlation. +- New employee onboarding that provisions TAPs as part of passwordless enrollment is expected behavior. + + +*Response and remediation* + + +- Revoke the TAP immediately if unauthorized: Entra ID > Users > Authentication methods. +- Audit all authentication methods registered by the target account after TAP creation and remove any + that were not previously present. +- Reset the target account's password and revoke all active sessions. +- Review the creating administrator's recent actions for signs of compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +( + ( + azure.auditlogs.operation_name: "User registered security info" and + azure.auditlogs.properties.result_reason: "User registered temporary access pass method" + ) or ( + azure.auditlogs.operation_name: "Create Temporary Access Pass method for user" + ) or ( + azure.auditlogs.operation_name: "Admin registered security info" and + azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: *TemporaryAccessPass* + ) +) and +event.outcome: ("Success" or "success") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc new file mode 100644 index 0000000000..c48ad8d4d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-26-first-time-seen-google-workspace-oauth-login-from-third-party-application]] +=== First Time Seen Google Workspace OAuth Login from Third-Party Application + +Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.token-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two +* https://developers.google.com/apps-script/guides/bound +* https://developers.google.com/identity/protocols/oauth2 + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Tactic: Defense Evasion +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Google Workspace OAuth Login from Third-Party Application* + + +Threat actors may trick users into authorizing adversary-controlled OAuth applications after credential theft, AiTM +relay, or spearphishing. A successful `authorize` grant issues tokens the application can reuse to act on behalf of the +user. Novel third-party client IDs are a strong signal as malicious consent often appears as a first-time application in the tenant. + +This rule uses `new_terms` to flag the first appearance of a `google_workspace.token.client.id` when +a user grants at least one identity or sign-in scope in `google_workspace.token.scope.value` (for example `openid`, +`userinfo.email`, `userinfo.profile`, or `OAuthLogin`). + + +*Possible investigation steps* + + +- Identify the user who authorized the application by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert. +- Identify the application by reviewing `google_workspace.token.app_name` and `google_workspace.token.client.id`. +- Review granted scopes in `google_workspace.token.scope.value` to determine whether the app received identity-only access or additional permissions (for example calendar, drive, or mail scopes on the same grant). +- Determine whether the authorization is expected and authorized: + - If `source.ip` or timing is unusual for the user, treat the alert as higher priority until proven benign.' + +- Search Kibana for related activity: + - Find prior authorizations for the same client in the org: + ``` + data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "" + ``` + - Correlate with sign-in anomalies for the same user: + ``` + data_stream.dataset: "google_workspace.login" and user.email: "" + ``` + - Scope for other OAuth or admin changes from the same `user.email` within the last 48 hours. + + +*False positive analysis* + + +- Internal development or QA OAuth clients may appear as new `client.id` values during testing; coordinate with engineering teams and exclude known test clients if needed. +- Some vendors rotate OAuth client IDs during major upgrades, which can look like a new application, confirm with the vendor or IT owner before closing as benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the authorization is not clearly authorized, revoke the application's access for the affected user under Security > Access and data control > API controls (or remove the user token via admin OAuth reports). +- If the user account is suspected compromised, reset credentials, revoke active sessions, and review all OAuth grants for that user. +- Review activity performed with the new token (Drive, Gmail, Calendar, or other services implied by `google_workspace.token.scope.value`). +- 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 user 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. +- 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 + +==== 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.token" + and event.action: "authorize" + and google_workspace.token.scope.value: (*openid* or *userinfo.email* or *userinfo.profile* or *Login*) + and google_workspace.token.client.id: *apps.googleusercontent.com + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-2sv-policy-disabled-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-2sv-policy-disabled-by-user.asciidoc new file mode 100644 index 0000000000..b80b3a9821 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-2sv-policy-disabled-by-user.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-26-google-workspace-2sv-policy-disabled-by-user]] +=== Google Workspace 2SV Policy Disabled By User + +Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.login-* +* logs-google_workspace.user_accounts-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-190m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?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*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace 2SV Policy Disabled By User* + + +Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove +the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can +support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is +especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions. + +In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user +notices, making it easier to re-enter the account later using stolen credentials alone. + +This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in +both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by +`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested. + + +*Possible investigation steps* + + +- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources. +- Determine whether the disable is expected or unauthorized: + - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement). + - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign. +- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert: + - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts` + - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login` + - OAuth activity in `google_workspace.token` if token abuse is suspected +- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled. + + +*False positive analysis* + + +- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds. +- 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. +- Review the permissions assigned to the implicated user 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 190 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. +- 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) for Filebeat and 3 hours for the Fleet Integration `login` datastream. 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.login" or "google_workspace.user_accounts") and event.action:"2sv_disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc new file mode 100644 index 0000000000..b8deab96fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-26-google-workspace-admin-role-assigned-to-a-user-or-group]] +=== Google Workspace Admin Role Assigned to a User or Group + +Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/172176?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: Identity and Access Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Assigned to a User or Group* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups. Because these roles can +grant broad administrative control over identity, devices, and security settings, role assignments should follow the +principle of least privilege (PoLP) and be carefully controlled. Threat actors may assign high-privilege roles (for +example, Super Admin or other *_ADMIN_ROLE roles) to establish persistence, expand access, and perform follow-on actions +such as creating OAuth tokens, modifying security controls, changing mail routing, or altering SSO settings. Unexpected +admin privileges can also lead to operational impact if changes are made unintentionally. + +This rule identifies when a Google Workspace administrative role is assigned to a user or a group. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that performed the change by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the target principal that received the role assignment: + - For assignments, review `user.target.email` and `user.target.name`. + - For group assignments, determine which users are members of that group at the time of assignment. +- Identify the role assigned by reviewing `google_workspace.admin.role.name`. +- Determine whether the assignment is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to grant this level of access. + - If the role is high privilege (for example, Super Admin), treat as urgent until proven benign. +- Scope for additional role assignments by searching for `event.action: ASSIGN_ROLE` over an expanded time window and filtering on: + - The same `user.email` (actor) to find other role changes performed by the same account. + - The same `google_workspace.admin.role.name` to identify other principals granted the role. + - The same target (`user.target.email`) to identify multiple roles granted to the same principal. +- Evaluate whether the target user (or group members) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + - If available, correlate with sign-in events for unusual geolocation, impossible travel, unfamiliar devices, or sign-ins from the `source.ip`. +- Determine whether the target user account was recently created by searching for `event.action: CREATE_USER` and filtering for `user.target.email`. + + +*False positive analysis* + + +- Verify the role assignment aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not performing role assignments from unusual IPs, devices, or locations. +- For group assignments, verify the group is intended for administrative delegation and validate recent membership changes that could expand who effectively received the privilege. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the assignment is not clearly authorized, remove the role assignment from the user/group and/or place the target account(s) under administrative restriction while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review the permissions assigned to the implicated user/group to ensure PoLP is being followed, and consider replacing broad roles with narrower delegated roles where feasible. +- 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:"ASSIGN_ROLE" + and google_workspace.admin.role.name : *_ADMIN_ROLE + +---------------------------------- + +*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 Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-deletion.asciidoc new file mode 100644 index 0000000000..dd348b6f9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-admin-role-deletion.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-26-google-workspace-admin-role-deletion]] +=== Google Workspace Admin Role Deletion + +Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?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: Identity and Access Audit +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Deletion* + + +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated +privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations, +remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the +Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing +historical audit logs. + +This rule identifies when a custom administrative role is deleted in the Google Admin console. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that deleted the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role deleted by reviewing `google_workspace.admin.role.name`. +- Determine whether the deletion is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Confirm the role is deleted in the Google Admin console: + - Navigate to Account > Admin roles. + - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list. +- Search Kibana for principals previously assigned the role to determine blast radius: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion. +- Search Kibana for privileges the deleted role contained: + - Use the following KQL example to review any privileges that were granted to the role before deletion: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "" + ``` + - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals. +- Scope for related role activity by searching for the same `user.email` (actor) performing other IAM actions such as `DELETE_ROLE`, `ADD_PRIVILEGE`, `ASSIGN_ROLE`, or security policy changes within the last 48 hours. +- Evaluate whether the deletion coincides with other suspicious activity: + - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments. + + +*False positive analysis* + + +- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations. +- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds. +- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether the deleted role contained security-relevant privileges (for example, audit log access or security settings management) that could impair detection or response if removed. +- 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:DELETE_ROLE + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc new file mode 100644 index 0000000000..9a26c45c61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-26-google-workspace-api-access-granted-via-domain-wide-delegation]] +=== Google Workspace API Access Granted via Domain-Wide Delegation + +Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.google.com/admin-sdk/directory/v1/guides/delegation +* 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: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace API Access Granted via Domain-Wide Delegation* + + +Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on +behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes +that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD +grants create durable third-party access paths that survive individual user password resets. + +This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and + `event.ingested` if present in the alert. +- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant + with `google_workspace.admin.domain.name`. +- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes + (for example full mail or drive access) warrant higher urgency. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the client and scopes. + - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign. +- Review DWD configuration in the Google Admin console: + - Sign in to https://admin.google.com[admin.google.com] with an authorized administrator account. + - Navigate to Security > Access and data control > API controls > Domain-wide delegation. + - Confirm the client ID, client name, and scopes match the alert fields. +- Search Kibana for related admin activity: + - Find other DWD grants or revocations by the same administrator: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS") + ``` + - Scope for all grants to the same API client: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "" + ``` + - Correlate with other high-risk admin actions from the same actor in the last 48 hours: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE") + ``` +- If GCP audit logs are ingested, pivot on the service account or client: + - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine + how the service account is being used after authorization. + + +*False positive analysis* + + +- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against + known service accounts and documented scope requirements. +- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data + control > API controls > Domain-wide delegation while the investigation proceeds. +- Rotate or disable the associated GCP service account keys if the client is suspected malicious. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review + delegated admin roles assigned to that account. +- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`. +- 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:AUTHORIZE_API_CLIENT_ACCESS + +---------------------------------- + +*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/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-bitlocker-setting-disabled.asciidoc new file mode 100644 index 0000000000..7d9ac63998 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-bitlocker-setting-disabled.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-26-google-workspace-bitlocker-setting-disabled]] +=== Google Workspace Bitlocker Setting Disabled + +Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?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: Defense Evasion +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Bitlocker Setting Disabled* + + +BitLocker Drive Encryption is a data protection feature that integrates with the Windows operating system to address the data theft or exposure threats from lost, stolen, or inappropriately decommissioned computers. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, such as data encryption and rendering data inaccessible. Google Workspace can sync with Windows endpoints that are registered in inventory, where BitLocker can be enabled and disabled. + +Disabling Bitlocker on an endpoint decrypts data at rest and makes it accessible, which raises the risk of exposing sensitive endpoint data. + +This rule identifies a user with administrative privileges and access to the admin console, disabling BitLocker for Windows endpoints. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.org_unit.name`, `google_workspace.admin.setting.name`, and `google_workspace.admin.old_value` / `new_value` to confirm BitLocker was disabled and for which OU. +- After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints. +- Review Admin and Device logs, filtering on the user email identified from the alert. +- Confirm the policy change under `Devices` (Windows device management) or the relevant Chrome/Windows endpoint settings area for the affected OU. + + +*False positive analysis* + + +- An administrator may have intentionally disabled BitLocker for routine maintenance or endpoint updates. + - Verify with the user that they intended to disable BitLocker on Windows endpoints. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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 user 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:"CHANGE_APPLICATION_SETTING" + and google_workspace.admin.new_value:"Disabled" and google_workspace.admin.setting.name:BitLocker* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-custom-admin-role-created.asciidoc new file mode 100644 index 0000000000..18464043ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-custom-admin-role-created.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-26-google-workspace-custom-admin-role-created]] +=== Google Workspace Custom Admin Role Created + +Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?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: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Custom Admin Role Created* + + +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also +be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to +a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant +access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage. + +This rule identifies when a custom administrative role is created in the Google Admin console. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that created the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role created by reviewing `google_workspace.admin.role.name`. +- Determine whether the role creation is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which administrative permissions were granted. + - Review the Admins tab to see which users or groups are currently assigned the role. +- Search Kibana for role assignments to identify principals that received the new role: + - Search Google Workspace admin logs with a time range starting at the role creation timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step. +- Scope for related role activity by searching for: + - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation. + - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes. +- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + + +*False positive analysis* + + +- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations. +- Compare the custom role’s privileges against the stated business need; overly broad privileges (for example, Super Admin–equivalent access) warrant closer review even if the creation was authorized. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible. +- 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:CREATE_ROLE + +---------------------------------- + +*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 Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc new file mode 100644 index 0000000000..bc86c19c3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-26-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user]] +=== Google Workspace Drive Encryption Key(s) Accessed from Anonymous User + +Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.drive-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/drive/answer/2494822 +* 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: Credential Access +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User* + + +Threat actors and opportunistic scanners frequently abuse Google Drive links set to "Anyone with the link" to access +sensitive files without authenticating. Private keys, keystores, and token files stored in user drives are high-value +targets. Possession of these files can enable decryption of protected data, signing or impersonation, and lateral +movement into systems that trust the exposed material. + +This rule uses EQL to detect `view`, `copy`, or `download` activity in `google_workspace.drive` where +`google_workspace.drive.visibility` is `people_with_link`, `source.user.email` is empty (anonymous access), and +`file.extension` matches common key or credential file types. + + +*Possible investigation steps* + + +- Identify the file accessed by reviewing `file.name` and `google_workspace.drive.file.type`, and note `event.action` (`view`, `copy`, or `download`) and `event.ingested`. +- Identify the file owner by reviewing `google_workspace.drive.file.owner.email` and determine whether that user should store key material in Drive. +- Review `source.user.id` and any available IP or user-agent context in the raw event to characterize the anonymous accessor. +- Confirm sharing posture in Google Drive: + - Open the file in Drive as an administrator or the owner and review Share settings. + - Verify whether access is "Anyone with the link" and whether the link was intentionally published or may have been exposed after account compromise. +- Search Kibana for related Drive activity for the same file or owner: + ``` + data_stream.dataset: "google_workspace.drive" and google_workspace.drive.file.owner.email: "" and file.name: "" + ``` + - Look for earlier `change_user_access`, `change_document_visibility`, or `rename` events that may indicate when the link was opened. + - Search for other key-like files owned by the same user with `people_with_link` visibility. +- Determine blast radius — identify which systems, applications, or cloud resources the key protects (VPN, TLS, code signing, service accounts, encrypted archives). +- Contact the file owner and security stakeholders to confirm whether anonymous access was expected (for example, a documented external audit). Treat unexpected access as high priority. + + +*False positive analysis* + + +- Legitimate use of link-based sharing for key files is rare; validate business justification before closing as benign. +- Automated scanners or DLP tools may touch public links — correlate with known security tooling and owner intent. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- Revoke the open link or restrict sharing to specific users; move key material out of broadly link-shared locations. +- If access is unauthorized, rotate or replace the exposed keys and review dependent systems for abuse. +- Review the file owner's account for signs of compromise (unusual logins, OAuth grants, or mass sharing changes). + + + + +*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] +---------------------------------- +file where data_stream.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and + google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and + file.extension: ( + "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key", + "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt", + "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..9ccc1079db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-26-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified]] +=== Google Workspace Gmail Routing or Forwarding Rule Created or Modified + +Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2685650?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 +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Gmail Routing or Forwarding Rule Created or Modified* + + +Gmail administrators can change where mail is delivered using several Admin console areas under Apps > Google Workspace > Gmail: + +- Routing — specialized rules (modify message, change route, also deliver to, change envelope recipient). Audit: `UNIFIED_MAIL_ROUTING` or `MESSAGE_SECURITY_RULE` (legacy); `google_workspace.admin.setting.metadata.rule.type` may repeat the legacy type on `RuleState` rows. +- Email forwarding using recipient address map — rewrite or forward by address mapping. Audit: `ALIAS_TABLE`. +- Hosts / Outbound gateway — custom SMTP routes. Audit: `EMAIL_ROUTE`. + +Google may emit multiple admin audit events per single save (legacy `CREATE_GMAIL_SETTING`, new `CREATE_APPLICATION_SETTING`, rule body, and rule enabled state). Expect duplicate documents at the same `@timestamp`; correlate on `user.name`, `google_workspace.admin.USER_DEFINED_SETTING_NAME` (rule id), and `event.id`. + + +*Possible investigation steps* + + +- Identify the administrator (`user.name`, `user.email`) and confirm the change was authorized. +- In Admin console, review the rule matching `google_workspace.admin.USER_DEFINED_SETTING_NAME`: + - Routing (`UNIFIED_MAIL_ROUTING`, `MESSAGE_SECURITY_RULE`): Apps > Gmail > Routing + - Recipient address map (`ALIAS_TABLE`): Apps > Gmail > Default routing > Email forwarding using recipient address map + - Mail hosts / outbound gateway (`EMAIL_ROUTE`): Apps > Gmail > Hosts +- Map the alert to the admin area using `google_workspace.admin.setting.name` and `google_workspace.admin.setting.metadata.rule.type` +- Review whether the rule adds also deliver to, change envelope recipient, or routes to an external mail host or domain. +- Review related `event.action` values for the same administrator in the last 48 hours. +- If licensed for Gmail log events (BigQuery / Enterprise Plus), use Reporting > Audit and investigation > Gmail log events to confirm messages were delivered per the rule (`message_info.flattened_destinations`, `triggered_rule_info`). +- Submit suspicious URLs or attachments from affected mail to reputational services as needed. + + +*False positive analysis* + + +- Legitimate mail migrations, journaling, compliance archiving, and internal dual-delivery are common. +- Tune with exceptions for known administrator accounts, rule ids (`USER_DEFINED_SETTING_NAME`), or approved external domains. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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 user 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 uses `timestamp_override = event.ingested` and is configured to run every 10 minutes with a lookback of 20 minutes, aligned with the integration's default Admin poll interval (`interval`: 15m) and lag time (`lag_time`: 3m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/docs/reference/integrations/google_workspace + +==== Setup + + +The Google Workspace Fleet integration with the Admin data stream (`logs-google_workspace.admin-*`) is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:( + "CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING" + or "CREATE_APPLICATION_SETTING" or "CHANGE_APPLICATION_SETTING" +) +and ( + google_workspace.admin.setting.name:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + or "MESSAGE_SECURITY_RULE" + ) + or google_workspace.admin.setting.metadata.rule.type:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc new file mode 100644 index 0000000000..a786c72f6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-26-google-workspace-mfa-enforcement-disabled-for-organization]] +=== Google Workspace MFA Enforcement Disabled For Organization + +Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?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: Impact +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace MFA Enforcement Disabled For Organization* + + +Threat actors with Google Workspace administrative access may disable organization-wide 2-step verification (2SV) +controls to weaken authentication for many users at once. Unlike a single user turning off 2SV on their own account, +this change affects tenant policy and can allow password-only sign-ins across an organizational unit or the entire +domain. This supports large-scale credential abuse, reduces MFA friction for follow-on compromise, and can blind +security teams if paired with other admin tampering. + +This rule identifies when an administrator sets `google_workspace.admin.new_value` to `false` for either +`ENFORCE_STRONG_AUTHENTICATION` (2SV enforcement turned off) or `ALLOW_STRONG_AUTHENTICATION` (users can no longer turn +on 2SV). + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed by reviewing `event.action`: + - `ENFORCE_STRONG_AUTHENTICATION` — 2SV enforcement was disabled for the affected scope. + - `ALLOW_STRONG_AUTHENTICATION` — users were prevented from turning on 2SV. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the prior and updated policy state. +- Determine the scope of impact by reviewing `google_workspace.admin.org_unit.name` (if present) and identifying which users or groups inherit the weakened policy. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request/ticket and that the actor is authorized to modify authentication policy. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for related authentication and admin activity: + - Use the following KQL example to find other MFA policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ENFORCE_STRONG_AUTHENTICATION" or "ALLOW_STRONG_AUTHENTICATION") + ``` + - Search for user-level 2SV disables that follow this change: + ``` + data_stream.dataset: ("google_workspace.login" or "google_workspace.user_accounts") and event.action: "2sv_disable" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as password policy changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the MFA policy change aligns with an approved change window, migration, or troubleshooting activity. +- Confirm the initiating administrator is legitimate and not acting from unusual IPs, devices, or locations. +- Even authorized changes materially weaken tenant security, validate business justification and time-bound rollback plans. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the change is not clearly authorized, restore 2SV enforcement and re-enable Allow users to turn on 2-Step Verification for the affected scope while the investigation proceeds. +- 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:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) + and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-password-policy-modified.asciidoc new file mode 100644 index 0000000000..74ffa59cc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-password-policy-modified.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-26-google-workspace-password-policy-modified]] +=== Google Workspace Password Policy Modified + +Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/7061566 +* 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: Identity and Access Audit +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Password Policy Modified* + + +Threat actors with Google Workspace administrative access may modify tenant password policies to weaken authentication +controls across an organizational unit or domain. Relaxing password complexity, reuse, or rotation requirements increases +the likelihood of successful password spraying, credential stuffing, and reuse of passwords exposed in third-party +breaches. Because policy changes apply to all users in scope, a single modification can materially expand the attack +surface for the entire unit. + +Saving changes in the Admin console can update multiple password settings at once. Google logs each setting change as a +separate `CHANGE_APPLICATION_SETTING` or `CREATE_APPLICATION_SETTING` event (for example, minimum length, maximum +length, reset frequency, strong password enforcement, and password reuse). Alert suppression groups by `user.email`, +`google_workspace.admin.org_unit.name`, and `source.ip` within the rule lookback so analysts receive one alert per +password policy modification session instead of one alert per setting. + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed in the alert by reviewing `google_workspace.admin.setting.name`. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to determine whether the change weakened policy. Examples of high-risk changes include: + - `Password Management - Enforce strong password` set to disabled + - `Password Management - Enable password reuse` set to enabled + - `Password Management - Minimum password length` reduced + - `Password Management - Password reset frequency` increased (less frequent rotation) +- Identify the scope of impact by reviewing `google_workspace.admin.org_unit.name` and determining which users inherit the updated policy. +- Determine whether the modification is expected and authorized: + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for all password settings changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` and `` as needed: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("CHANGE_APPLICATION_SETTING" or "CREATE_APPLICATION_SETTING") and user.email: "" and google_workspace.admin.setting.name: Password Management - * + ``` + - Optionally filter on `google_workspace.admin.org_unit.name: ""` to isolate changes for the same organizational unit. + - Review all `google_workspace.admin.setting.name`, `google_workspace.admin.old_value`, and `google_workspace.admin.new_value` fields returned to understand the full scope of the modification. +- Scope for related activity by searching for the same `user.email` performing other security-weakening admin actions within the last 48 hours, such as MFA enforcement changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the password policy change aligns with an approved change window, compliance exception, or migration activity. +- Policy hardening can also generate alerts for this rule — use `old_value` and `new_value` to distinguish benign hardening from weakening changes. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, restore password policy settings to their prior values for the affected organizational unit while the investigation proceeds. +- 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. +- 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 might observe lag times ranging from several minutes to 3 days between the event occurrence time 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, the Filebeat module, or data that's similarly structured is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and + event.action:(CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING) and + google_workspace.admin.setting.name:( + "Password Management - Enforce strong password" or + "Password Management - Password reset frequency" or + "Password Management - Enable password reuse" or + "Password Management - Enforce password policy at next login" or + "Password Management - Minimum password length" or + "Password Management - Maximum password length" + ) + +---------------------------------- + +*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/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc new file mode 100644 index 0000000000..ca33eca0a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-26-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app]] +=== Google Workspace Restrictions for Marketplace Modified to Allow Any App + +Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6089179?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: Defense Evasion +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Restrictions for Marketplace Modified to Allow Any App* + + +Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or Google Apps Script and created by both Google and third-party developers. + +Marketplace applications require access to specific Google Workspace resources. Applications can be installed by individual users, if they have permission, or can be installed for an entire Google Workspace domain by administrators. Consent screens typically display what permissions and privileges the application requires during installation. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent. + +Google clearly states that they are not responsible for any product on the Marketplace that originates from a source other than Google. + +This rule identifies when the global allow-all setting is enabled for Google Workspace Marketplace applications. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Confirm `google_workspace.admin.new_value` is `ALLOW_ALL` and review `google_workspace.admin.old_value` for the prior restriction. +- In the admin console, verify the change under `Apps > Google Workspace Marketplace apps` (global allowlist access setting). +- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. +- Search for `event.action` is `ADD_APPLICATION` to identify applications installed after these changes were made. + - The `google_workspace.admin.application.name` field will help identify what applications were added. +- With the user account, review other potentially related events within the last 48 hours. +- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. +- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace Apps`. + + +*False positive analysis* + + +- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. +- Google Workspace administrators may intentionally enable allow-all marketplace access based on organizational needs. + - Follow up with the administrator who made the change to ensure this was intended. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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 user 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. +- 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:"CHANGE_APPLICATION_SETTING" + and google_workspace.event.type:"APPLICATION_SETTINGS" and google_workspace.admin.application.name:"Google Workspace Marketplace" + and google_workspace.admin.setting.name:"Apps Access Setting Allowlist access" and google_workspace.admin.new_value:"ALLOW_ALL" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-role-modified.asciidoc new file mode 100644 index 0000000000..34b262e76a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-google-workspace-role-modified.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-26-google-workspace-role-modified]] +=== Google Workspace Role Modified + +Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?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: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Role Modified* + + +Google Workspace allows administrators to modify custom admin roles by adding, removing, or updating privileges across +services such as Users, Groups, Gmail, Drive, and Security. Threat actors may expand privileges on an existing role to +establish persistence or escalate access for accounts already assigned that role, without triggering role assignment +alerts. Selecting a privilege category in the Admin console (for example, Organization Units) can add multiple related +privilege groups in a single action, each logged as a separate `ADD_PRIVILEGE` event. + +This rule identifies when a Google Workspace role is modified via `ADD_PRIVILEGE` or `UPDATE_ROLE` events. Alert +suppression groups alerts by `user.email`, `google_workspace.admin.role.name`, and `source.ip` within a 130-minute window +(matching the rule lookback) so analysts receive one alert per role modification session instead of one alert per privilege. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that modified the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role modified by reviewing `google_workspace.admin.role.name`. +- Identify the privilege changed by reviewing `google_workspace.admin.privilege.name`. Because suppression may group multiple events, search for all related changes in the same session (see Kibana steps below). +- Determine whether the modification is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to modify admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which permissions were added or removed and whether they align with the organization's delegation model. + - Review the Admins tab to identify which users or groups currently hold the role and will inherit the modified privileges. +- Search Kibana for all privileges changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("ADD_PRIVILEGE" or "UPDATE_ROLE") and google_workspace.admin.role.name: "" + ``` + - Optionally filter on the actor with `user.email` to isolate changes from the same administrator. + - Review all `google_workspace.admin.privilege.name` values returned to understand the full scope of the modification. +- Search Kibana for principals recently assigned the role to determine blast radius: + - Use the following KQL example: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. +- Scope for related activity by searching for the same `user.email` (actor) performing other IAM or security actions such as `ASSIGN_ROLE`, `CREATE_ROLE`, `CREATE_USER`, or security policy changes within the last 48 hours. +- Evaluate whether principals assigned the modified role performed suspicious activity after the change: + - Review admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + + +*False positive analysis* + + +- Verify the role modification aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not modifying roles from unusual IPs, devices, or locations. +- Selecting a privilege category in the Admin console can add multiple related privileges in one action; alert suppression should consolidate these into a single alert. +- Compare the modified role's privileges against the stated business need; overly broad privileges warrant closer review even if the change was authorized. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, revert the role privileges to their prior state and/or remove the role assignment from affected users or groups while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether principals assigned the modified role require the new privileges, and replace broad custom roles with narrower delegated roles where feasible. +- 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.provider:admin and event.category:iam and event.action:(ADD_PRIVILEGE or UPDATE_ROLE) + +---------------------------------- + +*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/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..17518b0f83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-26-host-file-system-changes-via-windows-subsystem-for-linux]] +=== Host File System Changes via Windows Subsystem for Linux + +Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable and use WSL to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/microsoft/WSL +* https://detect.fyi/the-interesting-case-of-wsl-for-payload-staging-bfaa0f69329a + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne + +*Version*: 115 + +*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 Host File System Changes via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, facilitating seamless file access between systems. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, particularly those involving the Plan9FileSystem, to flag potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}". +- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories. +- Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern. +- Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access. + + +*False positive analysis* + + +- Routine file operations by legitimate applications using WSL may trigger alerts. Identify and whitelist these applications to prevent unnecessary alerts. +- Development activities involving WSL, such as compiling code or running scripts, can generate false positives. Exclude specific development directories or processes from monitoring. +- Automated backup or synchronization tools that interact with WSL might be flagged. Configure exceptions for these tools by specifying their process names or file paths. +- System maintenance tasks that involve WSL, like updates or system checks, could be mistaken for suspicious activity. Schedule these tasks during known maintenance windows and adjust monitoring rules accordingly. +- Frequent downloads or file transfers to directories outside the typical user download paths may appear suspicious. Define clear policies for acceptable file paths and exclude them from alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with "dllhost.exe" that are linked to the Plan9FileSystem CLSID to stop ongoing malicious activities. +- Conduct a thorough review of recent file changes on the host system to identify and restore any unauthorized modifications or deletions. +- Revoke any unauthorized access or permissions granted to WSL that may have been exploited by the adversary. +- Update and patch the Windows Subsystem for Linux and related components to mitigate any known vulnerabilities that could be exploited. +- Monitor for any recurrence of similar activities by setting up alerts for processes and file operations involving "dllhost.exe" and the Plan9FileSystem. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=5m +[process where host.os.type == "windows" and event.type == "start" and + process.name : "dllhost.exe" and + /* Plan9FileSystem CLSID - WSL Host File System Worker */ + process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"] +[file where host.os.type == "windows" and process.name : "dllhost.exe" and + not file.path : "?:\\Windows\\Prefetch\\DLLHOST.exe-????????.pf"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-ipsec-nat-traversal-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-ipsec-nat-traversal-port-activity.asciidoc new file mode 100644 index 0000000000..c800cc2d1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-ipsec-nat-traversal-port-activity.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-26-ipsec-nat-traversal-port-activity]] +=== IPSEC NAT Traversal Port Activity + +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. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.* +* logs-pfsense.log-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Tactic: Command and Control +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: pfSense +* 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 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 query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-java-dropped-and-executed-with-dns-lookup.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-java-dropped-and-executed-with-dns-lookup.asciidoc new file mode 100644 index 0000000000..994f664962 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-java-dropped-and-executed-with-dns-lookup.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-26-java-dropped-and-executed-with-dns-lookup]] +=== Java Dropped and Executed With DNS Lookup + +Identifies a recently dropped or modified javaw.exe process started from a user-writable path to run a JAR or Java classpath application, followed by a DNS lookup. Adversaries may drop Java payloads into user directories and execute them immediately to establish command and control while evading application control focused on native Windows binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Java Dropped and Executed With DNS Lookup* + + +This rule correlates a recently created or modified `javaw.exe` launch from `Users`, `ProgramData`, or `Windows\Temp` with an immediate +DNS lookup from the same process. Attackers often drop JAR-based payloads to user-writable locations and invoke them +with `-jar` or `-cp`/`-classpath` to blend in with legitimate Java usage while reaching out to command and control +infrastructure. + + +*Possible investigation steps* + + +- Review `process.executable`, `process.command_line`, and `process.args` to identify the JAR or classpath target and + whether the path is user-writable or unexpected for the host role. +- Inspect `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` to confirm the + binary or payload was staged immediately before execution. +- Examine the parent process tree for download, archive extraction, or script activity that may have dropped the JAR + or `javaw.exe`. +- Pivot on the DNS event for `dns.question.name`, `dns.resolved_ip`, and any follow-on connection attempts from the + same `process.entity_id`. +- Check code signature details for `javaw.exe` and any referenced JAR files when file telemetry is available. +- Hunt for the same JAR hash, command line, or queried domain on other hosts. + + +*False positive analysis* + + +- Developer workflows, local Java applications, and enterprise tools may run freshly updated JARs from user profiles or + `ProgramData`. Validate the JAR path, signer, parent process, and queried domain against known software before + closing as benign. +- Some installers or updaters drop a private JRE under `ProgramData` and launch JAR utilities during setup. Confirm the + activity aligns with a known deployment or update window. + + +*Response and remediation* + + +- Isolate the host if the JAR, domain, or parent activity appears malicious. +- Quarantine the dropped JAR, related Java runtime files, and any staging artifacts identified in the process tree. +- Block malicious domains or IPs at DNS and network enforcement points. +- Reset credentials for accounts active on the host during the suspicious session if follow-on activity is observed. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and + (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) and + (process.name : "javaw.exe" or process.pe.original_file_name == "javaw.exe") and process.executable : ("?:\\Users\\*", "?:\\ProgramData\\*", "?:\\Windows\\Temp\\*") and user.id != "S-1-5-18" and + ( + (process.args_count == 3 and process.args : "-jar") or + (process.args_count == 4 and process.args : ("-cp", "-classpath") and process.command_line : " *.* ") + )] + [network where host.os.type == "windows" and event.action: "lookup_requested"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-kernel-module-load-via-built-in-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-kernel-module-load-via-built-in-utility.asciidoc new file mode 100644 index 0000000000..1a64323a10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-kernel-module-load-via-built-in-utility.asciidoc @@ -0,0 +1,234 @@ +[[prebuilt-rule-8-19-26-kernel-module-load-via-built-in-utility]] +=== Kernel Module Load via Built-in Utility + +Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Threat: Rootkit +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kernel Module Load via Built-in Utility* + + +Threat actors with root privileges may abuse pre-installed binaries to load loadable kernel modules (LKMs), which are object files that extend the functionality of the kernel. + +Threat actors can abuse this utility to load rootkits, granting them full control over the system and the ability to evade security products. + +The detection rule 'Kernel Module Load via Built-in Utility' is designed to identify instances where these binaries are used to load a kernel object file (with a .ko extension) on a Linux system. This activity is uncommon and may indicate suspicious or malicious behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the kernel object file that was loaded. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} +- Investigate the kernel ring buffer for any warnings or messages, such as tainted or out-of-tree kernel module loads through `dmesg`. +- Investigate syslog for any unusual segfaults or other messages. Rootkits may be installed on targets with different architecture as expected, and could potentially cause segmentation faults. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - $osquery_6 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Kernel Driver Load - 3e12a439-d002-4944-bc42-171c0dcb9b96 +- Tainted Out-Of-Tree Kernel Module Load - 51a09737-80f7-4551-a3be-dac8ef5d181a +- Tainted Kernel Module Load - 05cad2fb-200c-407f-b472-02ea8c9e5e4a +- Attempt to Clear Kernel Ring Buffer - 2724808c-ba5d-48b2-86d2-0002103df753 +- Enumeration of Kernel Modules via Proc - 80084fa9-8677-4453-8680-b891d3c0c778 +- Suspicious Modprobe File Event - 40ddbcc8-6561-44d9-afc8-eefdbfe0cccd +- Kernel Module Removal - cd66a5af-e34b-4bb0-8931-57d0a043f2ef +- Enumeration of Kernel Modules - 2d8043ed-5bda-4caf-801c-c1feb7410504 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and ( + (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or + (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or + (process.name == "insmod" and process.args like~ "*.ko*") or + (process.name == "modprobe" and not process.args in ("-r", "--remove")) +) and +not ( + ?process.parent.executable like ("/opt/ds_agent/*", "/opt/TrendMicro/vls_agent/*", "/opt/intel/oneapi/*") or + ?process.working_directory in ("/opt/vinchin/agent", "/var/opt/ds_agent/am", "/opt/ds_agent", "/var/opt/TrendMicro/vls_agent/am") or + ?process.parent.executable in ( + "/usr/lib/uptrack/ksplice-apply", "/opt/commvault/commvault/Base/linux_drv", "/opt/cisco/amp/bin/cisco-amp-helper", + "/usr/bin/kcarectl", "/usr/share/ksplice/ksplice-apply", "/opt/commvault/Base/linux_drv", "/usr/sbin/veeamsnap-loader", + "/bin/falcoctl" + ) or + (?process.parent.name like ("python*", "platform-python*") and ?process.parent.args in ("--smart-update", "--auto-update")) or + ( + process.name == "modprobe" and process.args == "-q" and process.args == "--" and process.args in ("net-pf-10", "netdev-", "binfmt-464c") + ) or + ( + process.name == "modprobe" and process.args == "-n" and process.args == "-v" and process.args in ("usb-storage", "dccp", "squashfs", "udf", "sctp", "cramfs", "hfsplus") + ) or + ?process.parent.executable like ("/sbin/iptables-multi*", "/var/ossec/bin/wazuh-modulesd", "/usr/sbin/mkinitramfs", "/usr/share/initramfs-tools/hooks/lvm2") or + ?process.parent.args like "/usr/share/initramfs-tools/hooks/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-linux-user-added-to-privileged-group.asciidoc new file mode 100644 index 0000000000..eacb04d221 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-linux-user-added-to-privileged-group.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-26-linux-user-added-to-privileged-group]] +=== Linux User Added to Privileged Group + +Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux User Added to Privileged Group* + + +The `usermod`, `adduser`, and `gpasswd` commands can be used to assign user accounts to new groups in Linux-based operating systems. + +Attackers may add users to a privileged group in order to escalate privileges or establish persistence on a system or domain. + +This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign user accounts to a privileged group. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate whether the user was successfully added to the privileged group. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Retrieve information about the privileged group to which the user was added. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Adding accounts to a group is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the account that seems to be involved in malicious activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable != null and process.args in ( + "root", "admin", "wheel", "staff", "sudo","disk", "video", "shadow", "lxc", "lxd" +) and +( + process.name in ("usermod", "adduser") or + (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) +) and +not ( + ?process.parent.executable like ( + "/usr/lib/google/guest_agent/core_plugin", "/usr/libexec/platform-python*", "/usr/lib/google/guest_agent/GuestAgentCorePlugin/core_plugin", + "/usr/bin/google_guest_agent" + ) or + ( + ?process.entry_leader.executable == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.entry_leader.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*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 Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc new file mode 100644 index 0000000000..8e5f1d7f36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-26-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device]] +=== M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device) + +Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) from a device reported as non-compliant in the Microsoft 365 unified audit log for the first time within the rule's historical window (defined by the new terms history setting), independent of the requesting application or target resource. A match means the user has not been seen in this flow during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token, typically completed from a personal or attacker-controlled device that is not enrolled or compliant. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Examine `o365.audit.DeviceProperties` to understand the device posture (compliance, management state, OS, browser) and whether the device is recognized for this user. +- Confirm `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the application and resource the grant was for. Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and developer tooling (Azure CLI, PowerShell) are commonly abused. +- Inspect `source.as.number`, `source.as.organization.name`, `source.ip`, and `source.geo.*` and compare with the user's normal sign-in origins. Hosting, VPN, or datacenter providers are unusual for interactive user authentication. +- Examine `user_agent.original` for automation or headless-browser patterns. +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration). +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in on a personal or non-compliant device. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows using the device code flow on an unmanaged device. +- If a user or device combination is confirmed benign and recurring, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it, and require compliant or hybrid-joined devices, via Conditional Access policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..2d56d8b1ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-26-m365-identity-device-code-grant-with-unusual-user-and-asn]] +=== M365 Identity Device Code Grant with Unusual User and ASN + +Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant with Unusual User and ASN* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) to the Microsoft Authentication Broker for Microsoft Graph from a source ASN not seen for that user within the rule's historical window (defined by the new terms history setting). A match means the user has not authenticated via this flow from that ASN during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token. The grant therefore frequently appears from residential proxy or hosting/datacenter infrastructure the user has not authenticated from during the window. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Inspect `source.as.number` and `source.as.organization.name` for the source ASN. Hosting, VPN, or datacenter providers (for example Tencent, Alibaba, DigitalOcean) are unusual for interactive user authentication. +- Review `source.ip`, `source.geo.country_name`, and `source.geo.city_name` and compare with the user's normal sign-in locations. +- Examine `o365.audit.DeviceProperties` and `user_agent.original` for non-managed devices and automation or headless-browser patterns. +- Confirm `o365.audit.ApplicationId` is the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and `o365.audit.Target.ID` is Microsoft Graph (`00000003-0000-0000-c000-000000000000`). +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, including `is_interactive`, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration) from the same or related ASNs. +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in from a new ISP, mobile carrier, corporate VPN, or while traveling. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows that use the device code flow against the Authentication Broker. +- If a source ASN is confirmed benign and recurring for the environment, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it via Conditional Access authentication flow policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.ApplicationId: "29d9ed98-a469-4536-ade2-f981bc1d605e" + and o365.audit.Target.ID: "00000003-0000-0000-c000-000000000000" + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-teams-rogue-help-desk-chat-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-teams-rogue-help-desk-chat-created.asciidoc new file mode 100644 index 0000000000..98ea32a6dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-m365-teams-rogue-help-desk-chat-created.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-26-m365-teams-rogue-help-desk-chat-created]] +=== M365 Teams Rogue Help Desk Chat Created + +Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/ +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Teams Rogue Help Desk Chat Created* + + +Threat actors create external Microsoft 365 tenants and initiate unsolicited one-on-one Teams chats while impersonating +IT help desk or Microsoft security personnel. These chats often precede vishing, Quick Assist abuse, or malicious link +delivery. + +Review `user.email`, `user.domain`, `o365.audit.Members.DisplayName`, `o365.audit.ChatThreadId`, and +`o365.audit.ParticipantInfo`. Correlate follow-on `MessageSent` events for `source.ip` and `source.geo`, and +`CallParticipantDetail` events sharing the same `o365.audit.CallId` or chat thread for vishing activity. + + +*Possible investigation steps* + + +- Identify the external sender from `user.email`, `user.domain`, and `o365.audit.Members` and determine whether the + tenant or domain is known and trusted. +- Compare `user.name` to `o365.audit.Members.DisplayName` — actors often use a lowercase mailbox alias such as + `helpdesk` while presenting as `Help Desk` in Teams. +- Confirm `o365.audit.ParticipantInfo.HasForeignTenantUsers` is true and that no guest users are involved. +- Pivot on `o365.audit.ChatThreadId` for `MessageSent` and `CallParticipantDetail` events in the same session. +- Review `MessageSent` `source.ip` and `source.geo` for unexpected origin countries relative to the sender profile. +- Correlate with mail-flood, MFA fatigue, or URL click alerts for the targeted user in the same time window. +- Review whether the victim accepted the chat or responded, and hunt for follow-on remote support tool execution on + their endpoint. +- Check whether the sender tenant appears newly created, trial-based, or otherwise anomalous for your environment. + + +*False positive analysis* + + +- Approved external support vendors may use help desk-style display names. Maintain an allowlist of trusted external + tenants or sender domains when recurring benign matches occur. +- The `user.email` and `user.name` impersonation clauses target external mailbox aliases such as `helpdesk@`. Prefer + exceptions anchored on verified tenant IDs or sender domains rather than broad name-based exclusions. + + +*Response and remediation* + + +- Warn the targeted user not to engage and confirm whether they accepted the chat or shared credentials. +- Block or restrict the external tenant via Teams federation policy if malicious. +- Hunt for additional `ChatCreated` events from the same external tenant across the organization. +- Review Teams external access settings and consider blocking trial tenants or restricting federation to an allowlist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider:"MicrosoftTeams" and event.outcome:"success" and + o365.audit.ParticipantInfo.HasOtherGuestUsers:false and o365.audit.ParticipantInfo.HasGuestUsers:false and + o365.audit.ParticipantInfo.HasForeignTenantUsers:true and o365.audit.CommunicationType:"OneOnOne" and + ( + o365.audit.Members:( + "Help Desk" or "Help Desk Team" or "Help Desk IT" or "IT Help Desk" or + "Microsoft Security" or "Microsoft Security" or "Microsoft Support" + ) or + user.email:( + *helpdesk* or *help.desk* or *help-desk* or *help_desk* or + *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support* + ) or + user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport*) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc new file mode 100644 index 0000000000..e46ba03052 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-26-multiple-dhcp-servers-responding-to-the-same-transaction]] +=== Multiple DHCP Servers Responding to the Same Transaction + +Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-44815 +* https://nvd.nist.gov/vuln/detail/CVE-2024-3661 +* https://www.leviathansecurity.com/blog/tunnelvision +* https://nvd.nist.gov/vuln/detail/CVE-2018-5732 +* https://msrc.microsoft.com/update-guide + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*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 Multiple DHCP Servers Responding to the Same Transaction* + + +DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response +on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining +precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly +that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second +window, and is operating-system agnostic, since it keys only on server behavior observed on the wire. + + +*Possible investigation steps* + + +- Identify the server source IPs in `Esql.values_server_ips` and `Esql.values_server_identifiers`. Determine which is + the sanctioned DHCP server and which is unexpected. +- Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the + victim by definition. +- Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile + configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy + auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass). +- Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their + endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution. + Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g. + CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient). + + +*False positive analysis* + + +- DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two + peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or + load-balancing architecture genuinely does this, add its server IPs to an exception. +- DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each + transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known + architectural fact, which can be excepted by those IPs. + + +*Response and remediation* + + +- Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch + Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix). +- Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a + compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire/renew leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. A +sensor not on the same L2 broadcast domain (or not behind the relevant DHCP relay) will not observe competing OFFER/ACK +packets. + +Zeek is intentionally not supported: the zeek.dhcp data stream does not expose a transaction ID and aggregates a full +DORA exchange into one record, so the per-transaction server-count comparison cannot be expressed on it. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.transaction_id = COALESCE(network_traffic.dhcpv4.transaction_id, dhcpv4.transaction_id), + server_identifier = COALESCE(network_traffic.dhcpv4.option.server_identifier, dhcpv4.option.server_identifier) +| where message_type in ("offer", "ack") and Esql.transaction_id is not null and source.ip is not null +| eval Esql.time_window = DATE_TRUNC(30 seconds, @timestamp) +| stats + Esql.count_distinct_servers = COUNT_DISTINCT(source.ip), + Esql.values_server_ips = VALUES(source.ip), + Esql.values_server_identifiers = VALUES(server_identifier), + Esql.count_replies = COUNT(*) + by Esql.time_window, Esql.transaction_id +| where Esql.count_distinct_servers >= 2 +| keep Esql.transaction_id, Esql.time_window, Esql.count_distinct_servers, Esql.values_server_ips, Esql.values_server_identifiers, Esql.count_replies + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: DHCP Spoofing +** ID: T1557.003 +** Reference URL: https://attack.mitre.org/techniques/T1557/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-pluggable-authentication-module-pam-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-pluggable-authentication-module-pam-version-discovery.asciidoc new file mode 100644 index 0000000000..bb1453da03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-pluggable-authentication-module-pam-version-discovery.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-26-pluggable-authentication-module-pam-version-discovery]] +=== Pluggable Authentication Module (PAM) Version Discovery + +This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.group-ib.com/blog/pluggable-authentication-module/ +* https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 108 + +*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 Pluggable Authentication Module (PAM) Version Discovery* + + +Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". +- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. +- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. +- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. +- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. +- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. +- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. +- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. +- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ?process.parent.name != null and + ( + (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or + (process.name == "rpm" and process.args == "pam") + ) and +not ( + ?process.parent.name in ("dcservice", "inspectorssmplugin") or + ?process.working_directory in ("/var/ossec", "/opt/msp-agent") or + ?process.entry_leader.executable in("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/usr/sbin/ScanAssistant") or + ?process.parent.executable in ( + "/opt/CyberCNSAgent/cybercnsagent_linux", "/usr/local/manageengine/uems_agent/bin/dcpatchscan", + "/usr/local/manageengine/uems_agent/bin/dcconfig", "/usr/share/vicarius/topiad", + "/etc/rc.d/init.d/sshd-chroot", "/var/ossec/bin/wazuh-modulesd", + "/usr/lib/venv-salt-minion/bin/python.original" + ) or + ( + process.executable == "/usr/bin/rpm" and + ?process.parent.name == "systemd" and + ?process.env_vars == "LD_LIBRARY_PATH=/usr/lib/venv-salt-minion/lib" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-polkit-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-polkit-version-discovery.asciidoc new file mode 100644 index 0000000000..a049c23d2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-polkit-version-discovery.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-26-polkit-version-discovery]] +=== Polkit Version Discovery + +This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 8 + +*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 Polkit Version Discovery* + + +Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. +- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. +- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. +- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. +- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. +- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. +- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. +- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and ( + (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or + (process.name == "rpm" and process.args == "polkit") or + (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or + (process.name == "pkaction" and process.args == "--version") +) and +not ( + ?process.working_directory in ("/opt/msp-agent", "/opt/CyberCNSAgent") or + ?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") or + ?process.entry_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/sf/edr/agent/bin/edr_monitor") or + ( + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc new file mode 100644 index 0000000000..fed21d29f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-26-potential-amsi-bypass-via-rpc-runtime-hooking]] +=== Potential AMSI Bypass via RPC Runtime Hooking + +Identifies PowerShell script block content associated with an Antimalware Scan Interface (AMSI) bypass that hooks the RPC runtime marshaling stub NdrClientCall3 (or NdrClientCall2) in rpcrt4.dll. Unlike bypasses that patch AmsiScanBuffer or set amsiInitFailed, this technique operates at the RPC layer used by AMSI to delegate scan requests to the antivirus provider, tampering with the request before it reaches the engine and leaving AMSI itself unmodified. The loader allocates an executable trampoline and marshals a delegate to the native stub; these primitives appear in PowerShell Script Block Logging before the hook takes effect. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/andreisss/Ghosting-AMSI + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AMSI Bypass via RPC Runtime Hooking* + + +The Antimalware Scan Interface (AMSI) delegates scan requests to the registered antivirus provider over RPC. By hooking +the RPC runtime marshaling stub `NdrClientCall3`/`NdrClientCall2` in `rpcrt4.dll`, an adversary can tamper with these +requests so that malicious content is reported as clean, without modifying `amsi.dll` or patching `AmsiScanBuffer`. +This makes the bypass harder to catch via AMSI buffer or memory-write telemetry; the most reliable host artifact is the +loader's own PowerShell script content, captured by Script Block Logging. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` for references to `NdrClientCall3`/`NdrClientCall2`, resolution of + functions in `rpcrt4.dll`, allocation of executable (`PAGE_EXECUTE_READWRITE`) memory, and delegate marshaling via + `GetDelegateForFunctionPointer`. +- PowerShell logs each statement as a separate event; pivot on `host.id` and the PowerShell process id to reconstruct + the full loader sequence and confirm intent. +- Identify how PowerShell was launched (interactive, encoded command, remote session) and review the parent process + tree for download or staging activity. +- Correlate with Elastic Defend endpoint telemetry on the same host around the same time. Note that this RPC-layer hook + may not surface as a memory modification of `rpcrt4.dll`, which is expected for this technique. +- Hunt for the same script content, user, or host pattern across the environment. + + +*False positive analysis* + + +- Security research, detection engineering, and red-team development that legitimately references the RPC runtime + marshaling functions or allocates executable memory from PowerShell can match. Validate the user, host, parent + process, and surrounding script blocks against authorized testing before closing as benign, and add exceptions for + known testing identities or hosts. + + +*Response and remediation* + + +- Isolate the host if the activity is confirmed malicious and review for follow-on payload execution that the bypass + was intended to conceal. +- Terminate the offending PowerShell session and preserve the Script Block Logging events for analysis. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, or WDAC. +- Reset credentials for accounts active on the host during the session if follow-on activity is observed. + + +*Limitations* + + +This rule detects the technique only when it is delivered as logged PowerShell script-block text. In-memory delivery, a +PowerShell v2 downgrade, or implementing the hook outside PowerShell (compiled binary) can evade Script Block Logging +and therefore this rule. For customers running Elastic Defend, prefer the companion Endpoint Rule which detects the +VirtualProtect call targeting rpcrt4.dll!NdrClientCall* directly via API telemetry and is not dependent on Script +Block Logging. + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (event ID 4104). The +`Microsoft-Windows-PowerShell/Operational` channel must be collected by the Windows integration or Winlogbeat. + +Setup instructions: https://ela.st/powershell-logging-setup + +==== Rule query + + +[source, js] +---------------------------------- +event.code: "4104" and host.os.type: "windows" and + powershell.file.script_block_text : ( + "NdrClientCall" or + "NdrClientCall2" or + "NdrClientCall3" + ) and + powershell.file.script_block_text : ( + "GetProcAddress" or + "GetDelegateForFunctionPointer" or + "VirtualProtect" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc new file mode 100644 index 0000000000..ecbb4558db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-26-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940]] +=== Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940) + +Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* logs-network_traffic.http* +* logs-zeek.http* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.unfold.ai/blog/cpanel-exploit-cve-2026-41940 +* https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/ +* https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers +* https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026 +* https://nvd.nist.gov/vuln/detail/CVE-2026-41940 +* https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-log-files +* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 2 + +*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 Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)* + + +CVE-2026-41940 is a critical (CVSS 9.8) authentication bypass in cPanel & WHM that gives an unauthenticated attacker +a root-privileged session on the host. The exploit chains a CRLF injection in the session writer with an +encryption-skip triggered by a malformed cookie, then uses how cPanel caches sessions to promote the injected data +into a privileged login. Around 1.5M cPanel instances were exposed at disclosure and exploitation has been observed in +the wild since 2026-02-23, two months before the patch. + +This rule fires on the Stage 2 request/response shape: a `GET /` to a cPanel admin port that carries an +`Authorization: Basic` header and receives a 3xx redirect whose `Location` points at a freshly minted +`/cpsessNNNNNNNNNN` path. Per the watchTowr and Unfold writeups, this is the only request shape that lets the +exploit retrieve the security token needed for Stage 4 (privileged use of the session). + + +*Detection logic* + + +The rule requires all of the following on a single decoded HTTP transaction matched from +`data_stream.dataset:network_traffic.http` (or `event.category:network_traffic` with `network.protocol:http`): + +- `http.request.method:GET` and `url.path:"/"` — request targets the root path exactly. The CRLF vulnerability is only + reachable on `GET /`; the same payload on other paths does not return the redirect that leaks the token, so the + match is intentionally exact (a request like `GET /index.html` will not fire). +- `destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096)` — cPanel/WHM admin and webmail ports. These are + not in the default Network Packet Capture HTTP port list and must be added explicitly (see Setup). +- `http.response.status_code:[300 TO 399]` — a redirect response. Normal `GET /` to WHM returns 200 with the login + screen; only the exploit produces a 3xx here. +- `http.request.headers.authorization:Basic*` — HTTP Basic credentials sent on `GET /`. This is the network-layer + equivalent of the `auth_method=b` flag the Unfold and watchTowr writeups identify as the first bulletproof artifact + in cPanel's `access_log`. `GET /` is an unauthenticated endpoint in normal cPanel operation and never legitimately + carries Basic auth. +- `http.response.headers.location:/cpsess*` — the response redirects to a `/cpsess`-prefixed path, leaking the CSRF + token the attacker needs for Stage 4. This is what makes the exploit succeed and is not produced by any benign flow. + + +*Possible investigation steps* + + +- Capture the alert evidence. Record `source.ip` (attacker), `destination.ip` (cPanel host), `destination.port`, + `user_agent.original`, `http.response.status_code`, the exact `http.response.headers.location` value (which contains + the leaked `cpsess` token), and the captured `http.request.headers.authorization` value. +- Decode the Authorization header to confirm the CRLF payload. Strip the leading `Basic ` from + `http.request.headers.authorization` and base64-decode the remainder. A legitimate Basic credential decodes to + `username:password`; the exploit's payload decodes to a multi-line block delimited by `\r\n` containing fields like + `successful_internal_auth_with_timestamp=`, `tfa_verified=1`, and `hasroot=1`. CRLF bytes in the decoded value + distinguish exploitation from a misconfigured Basic-auth client. +- Confirm the destination host runs cPanel/WHM. Identify the installed version and whether the 2026-04-28 emergency + patch is applied. +- Pivot on the source IP across the host's `/usr/local/cpanel/logs/access_log`. The exploit-inherent log artifact is a + request line of the form `"GET / HTTP/1.1" 3xx 0 "-" "" "b" "-" ` — `auth_method=b` on `GET /` should never + occur in normal operation and corresponds 1:1 to the `http.request.headers.authorization:Basic*` clause in this rule. +- Look for the Stage 4 follow-on from the same source IP: a request to the leaked `cpsess` path + (`/cpsessNNNNNNNNNN/...`) with `auth_method=s` (session) and HTTP 200, without a preceding successful login + (form POST `/login`, `/openid_connect/`, or reseller `?session=`). This is the post-exploitation artifact. +- Identify whether privileged WHM API actions were invoked under the leaked `cpsess` token (account creation, package + install, file manager writes, terminal API). +- Review egress from the host for outbound connections initiated after the alert that could indicate web shell or + implant install. + + +*False positive analysis* + + +- Legitimate WHM administration never produces `GET /` with HTTP Basic authentication and a 3xx redirect leaking a + fresh `cpsess` token. This combination is exploit-inherent. +- Authorized vulnerability scans running CVE-2026-41940 plugins will reproduce the request shape. + + +*Response and remediation* + + +- Apply the cPanel emergency patch released 2026-04-28 (or the WP Squared equivalent). Verify by checking the + installed cPanel version against the advisory. +- If the alert is paired with an `auth_method=s` `cpsess` request (post-exploitation), assume host compromise: + rotate root credentials, audit `/var/cpanel/sessions/`, look for newly created accounts, scheduled tasks, SSH keys, + and `authorized_keys` modifications. +- Restrict access to cPanel admin ports (2087/2086/2083/2082/2095/2096) to known administrator source IPs at the + perimeter or via host firewall. +- Block the source IP at the WAF or perimeter if exploitation is confirmed. + + +==== Setup + + + +*Setup* + + +This rule supports two data sources: + +1. **Network Packet Capture / Packetbeat (preferred):** Requires the Network Packet Capture integration (or legacy + Packetbeat) with cPanel admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that + `http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports + (2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. +2. **Zeek HTTP logs (`zeek.http`):** Zeek records only the names of HTTP request and response headers in + `zeek.http.client_header_names` and `zeek.http.server_header_names`, not their values. The Zeek branch of this rule + therefore matches on the presence of `AUTHORIZATION` and `LOCATION` headers on a `GET /` to a cPanel admin port, + which is a less precise but still exploit-shaped signal. Confirm exploitation by retrieving the raw header values + from the upstream Zeek sensor or correlated packet capture. + + The Zeek branch has non-default sensor prerequisites that must be met or it will never match: + - **Header-name logging is not enabled by default.** `client_header_names` and `server_header_names` are produced by + the policy script `policy/protocols/http/header-names.zeek`, which is not loaded by `base/protocols/http` or the + default `site/local.zeek`. Add `@load policy/protocols/http/header-names.zeek` to the Zeek configuration. Without + it, neither field is emitted and the Zeek branch cannot fire. + - **Server header-name logging defaults to off.** Even with the script loaded, `HTTP::log_server_header_names` + defaults to `F`, so the `server_header_names:LOCATION` condition is unsatisfiable. Set + `redef HTTP::log_server_header_names = T;` (client header-name logging is on by default). + - **Non-standard ports are handled by DPD, not a port list.** Zeek ships port-independent HTTP DPD signatures + (`base/protocols/http/dpd.sig`) that detect HTTP by payload regardless of port, so plaintext `GET /` on cPanel + admin ports (2086/2082/2095) is parsed into `zeek.http` without registering those ports. The TLS ports + (2087/2083/2096) are encrypted and yield `zeek.ssl`, not `zeek.http`, unless the sensor sits upstream of TLS + termination (see decryption note below). + +cPanel/WHM exposes paired TLS and plaintext ports: 2087 (WHM HTTPS), 2083 (cPanel HTTPS), and 2096 (Webmail HTTPS) +require decryption visibility (TLS interception, sidecar on the host, or a sensor upstream of TLS termination) for +either data source to observe HTTP headers. The plaintext counterparts — 2086 (WHM HTTP), 2082 (cPanel HTTP), and 2095 +(Webmail HTTP) — carry headers in the clear and are observable without decryption. An attacker can exploit the +vulnerability over either variant, so both sets of ports are included in this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +( + ( + (data_stream.dataset:network_traffic.http OR (event.category:network_traffic AND network.protocol:http)) AND + http.response.status_code:[300 TO 399] AND + http.request.headers.authorization:Basic* AND + http.response.headers.location:\/cpsess* + ) + OR + ( + data_stream.dataset:zeek.http AND + zeek.http.client_header_names:AUTHORIZATION AND + zeek.http.server_header_names:LOCATION + ) +) AND +http.request.method:GET AND +url.path:"/" AND +destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..f6215d0087 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-26-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://everything.curl.dev/usingcurl/uploads +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Windows Security Event Logs + +*Version*: 8 + +*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 Potential Data Exfiltration Through Curl* + + +Curl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of suspicious arguments such as "-F", "-T", "-d", or "--data*" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server. +- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose. +- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity. +- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration. +- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt. + + +*False positive analysis* + + +- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly. +- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors. +- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints. +- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations. +- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data. +- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers. +- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name : ("curl", "curl.exe") and +( + process.args in ("-T", "--upload-file") or + ( + (process.args in ("-F", "-d", "--form") or process.args like "--data*") and process.command_line like "*@*" + ) +) and +( + process.command_line like ("*http:*", "*https:*", "*ftp:*", "*ftps:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) and +not ( + process.args : ( + "https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", + "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", + "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*" + ) or + process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ( + process.working_directory == "/home/oracle" and + process.args == "--trace" and + process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" + ) or + ( + process.working_directory == "/home/service/common/system.check" and + process.parent.command_line == "/bin/bash ./check.sh" + ) or + ( + process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ) or + ( + process.parent.executable == "/opt/rudder/share/commands/agent-run" and + process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + process.args like "/var/rudder/reports/ready/*" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Symmetric Encrypted Non-C2 Protocol +** ID: T1048.001 +** Reference URL: https://attack.mitre.org/techniques/T1048/001/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-masquerading-as-system32-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-masquerading-as-system32-dll.asciidoc new file mode 100644 index 0000000000..58d1b2036b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-masquerading-as-system32-dll.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-26-potential-masquerading-as-system32-dll]] +=== Potential Masquerading as System32 DLL + +Identifies suspicious instances of default system32 DLLs either unsigned or signed with non-MS certificates. This can potentially indicate the attempt to masquerade as system DLLs, perform DLL Search Order Hijacking or backdoor and resign legitimate DLLs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Masquerading as System32 DLL* + + +This rule fires when a DLL with a name matching a known Windows System32 library is loaded from an unexpected path, is unsigned or signed by a non-Microsoft certificate, and was recently created or modified (within the last hour). This pattern is consistent with DLL Search Order Hijacking, DLL planting, or backdooring/resigning of legitimate system DLLs — all common defense evasion and persistence techniques used by both commodity malware and sophisticated threat actors. + + +*Possible investigation steps* + + +- Examine the full `dll.path` to determine where the suspicious DLL was loaded from. Paths under user-writable directories (`AppData`, `Temp`, `Downloads`, `ProgramData`) or application directories are high-fidelity indicators. +- Review `dll.code_signature` fields — check whether the DLL is unsigned, self-signed, or signed by an unexpected publisher. A trusted signature from a legitimate vendor may indicate a false positive; an invalid or absent signature warrants deeper investigation. +- Check `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` — a DLL dropped and loaded within seconds or minutes of each other strongly suggests staged execution. +- Identify the loading process (`process.name`, `process.executable`, `process.pid`) and examine its parent chain for unusual ancestry (e.g. Office spawning a loader, or a browser dropping a DLL). +- Retrieve the DLL and hash it with `Get-FileHash -Algorithm SHA256`. Search the hash across VirusTotal, Hybrid-Analysis, MalwareBazaar, and CISCO Talos. +- Check whether other hosts in the environment have loaded the same DLL path or hash — a single host is likely targeted or hands-on, widespread hits may indicate a worm or supply chain issue. +- Correlate with process creation events around the same timestamp to identify what dropped the DLL (downloaders, document macros, installers, etc.). +- Inspect the directory containing the DLL for other recently created files, scripts, or executables that may be part of the same drop. + + +*False positive analysis* + + +- Legitimate third-party software occasionally ships DLLs with names that collide with System32 libraries (e.g. security vendors, game engines, virtualization software, and enterprise tooling). Validate the publisher via `dll.code_signature.subject_name` and cross-reference against known software installed on the host. +- Installer and update workflows may briefly stage DLLs in temp paths before moving them to their final location — check whether the loading process is a known installer (`msiexec.exe`, `setup.exe`, vendor updaters) and whether the DLL path disappears after a short window. +- DismHost.exe staging certain DLLs under `C:\Windows\Temp\` during servicing operations is a known benign pattern already excluded in the query. + + +*Related rules* + + +- Suspicious DLL Loaded for Persistence via Desktop File - c4818812-d44f-47be-aaef-4cfb2f9cc799 +- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26 +- Potential DLL Side-Loading via Trusted Microsoft Programs - 1160dcdb-0a0a-4a79-91d8-9b84af7e0240 + + +*Response and remediation* + + +- Initiate the incident response process based on triage outcome. If the DLL is confirmed malicious, treat the host as compromised. +- Isolate the affected host and preserve a memory dump and disk image before remediation to retain forensic evidence. +- Delete the malicious DLL and any associated files identified during investigation. +- If DLL Search Order Hijacking is confirmed, identify the vulnerable application and remediate by patching, applying a safe DLL search mode (`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode`), or restricting write permissions on directories in the application's search path. +- If a legitimate binary was backdoored and resigned, treat all binaries delivered via the same channel as suspect and investigate the supply chain. +- Block identified file hashes and signer certificates as appropriate at the endpoint and perimeter. +- Hunt for lateral movement or persistence mechanisms established after the DLL was loaded — check scheduled tasks, services, registry run keys, and WMI subscriptions created around the same timeframe. +- Determine the initial access vector and remediate to prevent reinfection. + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and event.action == "load" and +(dll.Ext.relative_file_creation_time <= 3600 or dll.Ext.relative_file_name_modify_time <= 3600) and + not ( + dll.path : ( + "?:\\Windows\\System32\\*", + "?:\\Windows\\SysWOW64\\*", + "?:\\Windows\\SystemTemp\\*", + "?:\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*", + "?:\\$WINDOWS.~BT\\NewOS\\Windows\\System32\\*", + "?:\\$WINDOWS.~BT\\Sources\\*", + "?:\\$WINDOWS.~BT\\Work\\*", + "?:\\Windows\\WinSxS\\*", + "?:\\Windows\\SoftwareDistribution\\Download\\*", + "?:\\Windows\\assembly\\NativeImages_v*" + ) + ) and + not ( + dll.code_signature.subject_name in ( + "Microsoft Windows", + "Microsoft Corporation", + "Microsoft Windows Hardware Abstraction Layer Publisher", + "Microsoft Windows Publisher", + "Microsoft Windows 3rd party Component", + "Microsoft 3rd Party Application Component" + ) and dll.code_signature.trusted == true + ) and not dll.code_signature.status : ("errorCode_endpoint*", "errorUntrustedRoot", "errorChaining") and + dll.name : ( + "aadauthhelper.dll", "aadcloudap.dll", "aadjcsp.dll", "aadtb.dll", "aadwamextension.dll", "aarsvc.dll", "abovelockapphost.dll", "accessibilitycpl.dll", "accountaccessor.dll", "accountsrt.dll", "acgenral.dll", "aclayers.dll", "acledit.dll", "aclui.dll", "acmigration.dll", "acppage.dll", "acproxy.dll", "acspecfc.dll", "actioncenter.dll", "actioncentercpl.dll", "actionqueue.dll", "activationclient.dll", "activeds.dll", "activesynccsp.dll", "actxprxy.dll", "acwinrt.dll", "acxtrnal.dll", "adaptivecards.dll", "addressparser.dll", "adhapi.dll", "adhsvc.dll", "admtmpl.dll", "adprovider.dll", "adrclient.dll", "adsldp.dll", "adsldpc.dll", "adsmsext.dll", "adsnt.dll", "adtschema.dll", "advancedemojids.dll", "advapi32.dll", "advapi32res.dll", "advpack.dll", "aeevts.dll", "aeinv.dll", "aepic.dll", "ajrouter.dll", "altspace.dll", "amsi.dll", "amsiproxy.dll", "amstream.dll", "apds.dll", "aphostclient.dll", "aphostres.dll", "aphostservice.dll", "apisampling.dll", "apisetschema.dll", "apmon.dll", "apmonui.dll", "appcontracts.dll", "appextension.dll", "apphelp.dll", "apphlpdm.dll", "appidapi.dll", "appidsvc.dll", "appinfo.dll", "appinfoext.dll", "applicationframe.dll", "applockercsp.dll", "appmgmts.dll", "appmgr.dll", "appmon.dll", "appointmentapis.dll", "appraiser.dll", "appreadiness.dll", "apprepapi.dll", "appresolver.dll", "appsruprov.dll", "appvcatalog.dll", "appvclientps.dll", "appvetwclientres.dll", "appvintegration.dll", "appvmanifest.dll", "appvpolicy.dll", "appvpublishing.dll", "appvreporting.dll", "appvscripting.dll", "appvsentinel.dll", "appvstreamingux.dll", "appvstreammap.dll", "appvterminator.dll", "appxalluserstore.dll", "appxpackaging.dll", "appxsip.dll", "appxsysprep.dll", "archiveint.dll", "asferror.dll", "aspnet_counters.dll", "asycfilt.dll", "atl.dll", "atlthunk.dll", "atmlib.dll", "audioeng.dll", "audiohandlers.dll", "audiokse.dll", "audioses.dll", "audiosrv.dll", "auditcse.dll", "auditpolcore.dll", "auditpolmsg.dll", "authbroker.dll", "authbrokerui.dll", "authentication.dll", "authext.dll", "authfwcfg.dll", "authfwgp.dll", "authfwsnapin.dll", "authfwwizfwk.dll", "authhostproxy.dll", "authui.dll", "authz.dll", "autopilot.dll", "autopilotdiag.dll", "autoplay.dll", "autotimesvc.dll", "avicap32.dll", "avifil32.dll", "avrt.dll", "axinstsv.dll", "azroles.dll", "azroleui.dll", "azsqlext.dll", "basecsp.dll", "basesrv.dll", "batmeter.dll", "bcastdvrbroker.dll", "bcastdvrclient.dll", "bcastdvrcommon.dll", "bcd.dll", "bcdprov.dll", "bcdsrv.dll", "bcp47langs.dll", "bcp47mrm.dll", "bcrypt.dll", "bcryptprimitives.dll", "bdehdcfglib.dll", "bderepair.dll", "bdesvc.dll", "bdesysprep.dll", "bdeui.dll", "bfe.dll", "bi.dll", "bidispl.dll", "bindfltapi.dll", "bingasds.dll", "bingfilterds.dll", "bingmaps.dll", "biocredprov.dll", "bisrv.dll", "bitlockercsp.dll", "bitsigd.dll", "bitsperf.dll", "bitsproxy.dll", "biwinrt.dll", "blbevents.dll", "blbres.dll", "blb_ps.dll", "bluetoothapis.dll", "bnmanager.dll", "bootmenuux.dll", "bootstr.dll", "bootux.dll", "bootvid.dll", "bridgeres.dll", "brokerlib.dll", "browcli.dll", "browserbroker.dll", "browseui.dll", "btagservice.dll", "bthavctpsvc.dll", "bthavrcp.dll", "bthavrcpappsvc.dll", "bthci.dll", "bthpanapi.dll", "bthradiomedia.dll", "bthserv.dll", "bthtelemetry.dll", "btpanui.dll", "bwcontexthandler.dll", "cabapi.dll", "cabinet.dll", "cabview.dll", "callbuttons.dll", "cameracaptureui.dll", "capauthz.dll", "capiprovider.dll", "capisp.dll", "captureservice.dll", "castingshellext.dll", "castlaunch.dll", "catsrv.dll", "catsrvps.dll", "catsrvut.dll", "cbdhsvc.dll", "cca.dll", "cdd.dll", "cdosys.dll", "cdp.dll", "cdprt.dll", "cdpsvc.dll", "cdpusersvc.dll", "cemapi.dll", "certca.dll", "certcli.dll", "certcredprovider.dll", "certenc.dll", "certenroll.dll", "certenrollui.dll", "certmgr.dll", "certpkicmdlet.dll", "certpoleng.dll", "certprop.dll", "cewmdm.dll", "cfgbkend.dll", "cfgmgr32.dll", "cfgspcellular.dll", "cfgsppolicy.dll", "cflapi.dll", "cfmifs.dll", "cfmifsproxy.dll", "chakra.dll", "chakradiag.dll", "chakrathunk.dll", "chartv.dll", "chatapis.dll", "chkwudrv.dll", "chsstrokeds.dll", "chtbopomofods.dll", "chtcangjieds.dll", "chthkstrokeds.dll", "chtquickds.dll", "chxapds.dll", "chxdecoder.dll", "chxhapds.dll", "chxinputrouter.dll", "chxranker.dll", "ci.dll", "cic.dll", "cimfs.dll", "circoinst.dll", "ciwmi.dll", "clb.dll", "clbcatq.dll", "cldapi.dll", "cleanpccsp.dll", "clfsw32.dll", "cliconfg.dll", "clipboardserver.dll", "clipc.dll", "clipsvc.dll", "clipwinrt.dll", "cloudap.dll", "cloudidsvc.dll", "clrhost.dll", "clusapi.dll", "cmcfg32.dll", "cmdext.dll", "cmdial32.dll", "cmgrcspps.dll", "cmifw.dll", "cmintegrator.dll", "cmlua.dll", "cmpbk32.dll", "cmstplua.dll", "cmutil.dll", "cngcredui.dll", "cngprovider.dll", "cnvfat.dll", "cofiredm.dll", "colbact.dll", "colorcnv.dll", "colorui.dll", "combase.dll", "comcat.dll", "comctl32.dll", "comdlg32.dll", "coml2.dll", "comppkgsup.dll", "compstui.dll", "computecore.dll", "computenetwork.dll", "computestorage.dll", "comrepl.dll", "comres.dll", "comsnap.dll", "comsvcs.dll", "comuid.dll", "configmanager2.dll", "conhostv1.dll", "connect.dll", "consentux.dll", "consentuxclient.dll", "console.dll", "consolelogon.dll", "contactapis.dll", "container.dll", "coredpus.dll", "coreglobconfig.dll", "coremas.dll", "coremessaging.dll", "coremmres.dll", "coreshell.dll", "coreshellapi.dll", "coreuicomponents.dll", "correngine.dll", "courtesyengine.dll", "cpfilters.dll", "creddialogbroker.dll", "credprovhelper.dll", "credprovhost.dll", "credprovs.dll", "credprovslegacy.dll", "credssp.dll", "credui.dll", "crypt32.dll", "cryptbase.dll", "cryptcatsvc.dll", "cryptdlg.dll", "cryptdll.dll", "cryptext.dll", "cryptnet.dll", "cryptngc.dll", "cryptowinrt.dll", "cryptsp.dll", "cryptsvc.dll", "crypttpmeksvc.dll", "cryptui.dll", "cryptuiwizard.dll", "cryptxml.dll", "cscapi.dll", "cscdll.dll", "cscmig.dll", "cscobj.dll", "cscsvc.dll", "cscui.dll", "csplte.dll", "cspproxy.dll", "csrsrv.dll", "cxcredprov.dll", "c_g18030.dll", "c_gsm7.dll", "c_is2022.dll", "c_iscii.dll", "d2d1.dll", "d3d10.dll", "d3d10core.dll", "d3d10level9.dll", "d3d10warp.dll", "d3d10_1.dll", "d3d10_1core.dll", "d3d11.dll", "d3d11on12.dll", "d3d12.dll", "d3d12core.dll", "d3d8thk.dll", "d3d9.dll", "d3d9on12.dll", "d3dscache.dll", "dab.dll", "dabapi.dll", "daconn.dll", "dafbth.dll", "dafdnssd.dll", "dafescl.dll", "dafgip.dll", "dafiot.dll", "dafipp.dll", "dafmcp.dll", "dafpos.dll", "dafprintprovider.dll", "dafupnp.dll", "dafwcn.dll", "dafwfdprovider.dll", "dafwiprov.dll", "dafwsd.dll", "damediamanager.dll", "damm.dll", "das.dll", "dataclen.dll", "datusage.dll", "davclnt.dll", "davhlpr.dll", "davsyncprovider.dll", "daxexec.dll", "dbgcore.dll", "dbgeng.dll", "dbghelp.dll", "dbgmodel.dll", "dbnetlib.dll", "dbnmpntw.dll", "dciman32.dll", "dcntel.dll", "dcomp.dll", "ddaclsys.dll", "ddcclaimsapi.dll", "ddds.dll", "ddisplay.dll", "ddoiproxy.dll", "ddores.dll", "ddpchunk.dll", "ddptrace.dll", "ddputils.dll", "ddp_ps.dll", "ddraw.dll", "ddrawex.dll", "defragproxy.dll", "defragres.dll", "defragsvc.dll", "deploymentcsps.dll", "deskadp.dll", "deskmon.dll", "desktopshellext.dll", "devenum.dll", "deviceaccess.dll", "devicecenter.dll", "devicecredential.dll", "devicepairing.dll", "deviceuxres.dll", "devinv.dll", "devmgr.dll", "devobj.dll", "devpropmgr.dll", "devquerybroker.dll", "devrtl.dll", "dfdts.dll", "dfscli.dll", "dfshim.dll", "dfsshlex.dll", "dggpext.dll", "dhcpcmonitor.dll", "dhcpcore.dll", "dhcpcore6.dll", "dhcpcsvc.dll", "dhcpcsvc6.dll", "dhcpsapi.dll", "diagcpl.dll", "diagnosticlogcsp.dll", "diagperf.dll", "diagsvc.dll", "diagtrack.dll", "dialclient.dll", "dialserver.dll", "dictationmanager.dll", "difxapi.dll", "dimsjob.dll", "dimsroam.dll", "dinput.dll", "dinput8.dll", "direct2ddesktop.dll", "directml.dll", "discan.dll", "dismapi.dll", "dispbroker.dll", "dispex.dll", "display.dll", "displaymanager.dll", "dlnashext.dll", "dmappsres.dll", "dmcfgutils.dll", "dmcmnutils.dll", "dmcsps.dll", "dmdlgs.dll", "dmdskmgr.dll", "dmdskres.dll", "dmdskres2.dll", "dmenrollengine.dll", "dmintf.dll", "dmiso8601utils.dll", "dmloader.dll", "dmocx.dll", "dmoleaututils.dll", "dmpushproxy.dll", "dmpushroutercore.dll", "dmrcdecoder.dll", "dmrserver.dll", "dmsynth.dll", "dmusic.dll", "dmutil.dll", "dmvdsitf.dll", "dmwappushsvc.dll", "dmwmicsp.dll", "dmxmlhelputils.dll", "dnsapi.dll", "dnscmmc.dll", "dnsext.dll", "dnshc.dll", "dnsrslvr.dll", "docprop.dll", "dolbydecmft.dll", "domgmt.dll", "dosettings.dll", "dosvc.dll", "dot3api.dll", "dot3cfg.dll", "dot3conn.dll", "dot3dlg.dll", "dot3gpclnt.dll", "dot3gpui.dll", "dot3hc.dll", "dot3mm.dll", "dot3msm.dll", "dot3svc.dll", "dot3ui.dll", "dpapi.dll", "dpapiprovider.dll", "dpapisrv.dll", "dpnaddr.dll", "dpnathlp.dll", "dpnet.dll", "dpnhpast.dll", "dpnhupnp.dll", "dpnlobby.dll", "dps.dll", "dpx.dll", "drprov.dll", "drt.dll", "drtprov.dll", "drttransport.dll", "drvsetup.dll", "drvstore.dll", "dsauth.dll", "dsccore.dll", "dsccoreconfprov.dll", "dsclient.dll", "dscproxy.dll", "dsctimer.dll", "dsdmo.dll", "dskquota.dll", "dskquoui.dll", "dsound.dll", "dsparse.dll", "dsprop.dll", "dsquery.dll", "dsreg.dll", "dsregtask.dll", "dsrole.dll", "dssec.dll", "dssenh.dll", "dssvc.dll", "dsui.dll", "dsuiext.dll", "dswave.dll", "dtsh.dll", "ducsps.dll", "dui70.dll", "duser.dll", "dusmapi.dll", "dusmsvc.dll", "dwmapi.dll", "dwmcore.dll", "dwmghost.dll", "dwminit.dll", "dwmredir.dll", "dwmscene.dll", "dwrite.dll", "dxcore.dll", "dxdiagn.dll", "dxgi.dll", "dxgwdi.dll", "dxilconv.dll", "dxmasf.dll", "dxp.dll", "dxpps.dll", "dxptasksync.dll", "dxtmsft.dll", "dxtrans.dll", "dxva2.dll", "dynamoapi.dll", "eapp3hst.dll", "eappcfg.dll", "eappcfgui.dll", "eappgnui.dll", "eapphost.dll", "eappprxy.dll", "eapprovp.dll", "eapputil.dll", "eapsimextdesktop.dll", "eapsvc.dll", "eapteapauth.dll", "eapteapconfig.dll", "eapteapext.dll", "easconsent.dll", "easwrt.dll", "edgeangle.dll", "edgecontent.dll", "edgehtml.dll", "edgeiso.dll", "edgemanager.dll", "edpauditapi.dll", "edpcsp.dll", "edptask.dll", "edputil.dll", "eeprov.dll", "eeutil.dll", "efsadu.dll", "efscore.dll", "efsext.dll", "efslsaext.dll", "efssvc.dll", "efsutil.dll", "efswrt.dll", "ehstorapi.dll", "ehstorpwdmgr.dll", "ehstorshell.dll", "els.dll", "elscore.dll", "elshyph.dll", "elslad.dll", "elstrans.dll", "emailapis.dll", "embeddedmodesvc.dll", "emojids.dll", "encapi.dll", "energy.dll", "energyprov.dll", "energytask.dll", "enrollmentapi.dll", "enterpriseapncsp.dll", "enterprisecsps.dll", "enterpriseetw.dll", "eqossnap.dll", "errordetails.dll", "errordetailscore.dll", "es.dll", "esclprotocol.dll", "esclscan.dll", "esclwiadriver.dll", "esdsip.dll", "esent.dll", "esentprf.dll", "esevss.dll", "eshims.dll", "etwrundown.dll", "euiccscsp.dll", "eventaggregation.dll", "eventcls.dll", "evr.dll", "execmodelclient.dll", "execmodelproxy.dll", "explorerframe.dll", "exsmime.dll", "extrasxmlparser.dll", "f3ahvoas.dll", "facilitator.dll", "familysafetyext.dll", "faultrep.dll", "fcon.dll", "fdbth.dll", "fdbthproxy.dll", "fddevquery.dll", "fde.dll", "fdeploy.dll", "fdphost.dll", "fdpnp.dll", "fdprint.dll", "fdproxy.dll", "fdrespub.dll", "fdssdp.dll", "fdwcn.dll", "fdwnet.dll", "fdwsd.dll", "feclient.dll", "ffbroker.dll", "fhcat.dll", "fhcfg.dll", "fhcleanup.dll", "fhcpl.dll", "fhengine.dll", "fhevents.dll", "fhshl.dll", "fhsrchapi.dll", "fhsrchph.dll", "fhsvc.dll", "fhsvcctl.dll", "fhtask.dll", "fhuxadapter.dll", "fhuxapi.dll", "fhuxcommon.dll", "fhuxgraphics.dll", "fhuxpresentation.dll", "fidocredprov.dll", "filemgmt.dll", "filterds.dll", "findnetprinters.dll", "firewallapi.dll", "flightsettings.dll", "fltlib.dll", "fluencyds.dll", "fmapi.dll", "fmifs.dll", "fms.dll", "fntcache.dll", "fontext.dll", "fontprovider.dll", "fontsub.dll", "fphc.dll", "framedyn.dll", "framedynos.dll", "frameserver.dll", "frprov.dll", "fsutilext.dll", "fthsvc.dll", "fundisc.dll", "fveapi.dll", "fveapibase.dll", "fvecerts.dll", "fvecpl.dll", "fveskybackup.dll", "fveui.dll", "fvewiz.dll", "fwbase.dll", "fwcfg.dll", "fwmdmcsp.dll", "fwpolicyiomgr.dll", "fwpuclnt.dll", "fwremotesvr.dll", "gameinput.dll", "gamemode.dll", "gamestreamingext.dll", "gameux.dll", "gamingtcui.dll", "gcdef.dll", "gdi32.dll", "gdi32full.dll", "gdiplus.dll", "generaltel.dll", "geocommon.dll", "geolocation.dll", "getuname.dll", "glmf32.dll", "globinputhost.dll", "glu32.dll", "gmsaclient.dll", "gpapi.dll", "gpcsewrappercsp.dll", "gpedit.dll", "gpprefcl.dll", "gpprnext.dll", "gpscript.dll", "gpsvc.dll", "gptext.dll", "graphicscapture.dll", "graphicsperfsvc.dll", "groupinghc.dll", "hal.dll", "halextpl080.dll", "hascsp.dll", "hashtagds.dll", "hbaapi.dll", "hcproviders.dll", "hdcphandler.dll", "heatcore.dll", "helppaneproxy.dll", "hgcpl.dll", "hhsetup.dll", "hid.dll", "hidcfu.dll", "hidserv.dll", "hlink.dll", "hmkd.dll", "hnetcfg.dll", "hnetcfgclient.dll", "hnetmon.dll", "hologramworld.dll", "holoshellruntime.dll", "holoshextensions.dll", "hotplug.dll", "hrtfapo.dll", "httpapi.dll", "httpprxc.dll", "httpprxm.dll", "httpprxp.dll", "httpsdatasource.dll", "htui.dll", "hvhostsvc.dll", "hvloader.dll", "hvsigpext.dll", "hvsocket.dll", "hydrogen.dll", "ia2comproxy.dll", "ias.dll", "iasacct.dll", "iasads.dll", "iasdatastore.dll", "iashlpr.dll", "iasmigplugin.dll", "iasnap.dll", "iaspolcy.dll", "iasrad.dll", "iasrecst.dll", "iassam.dll", "iassdo.dll", "iassvcs.dll", "icfupgd.dll", "icm32.dll", "icmp.dll", "icmui.dll", "iconcodecservice.dll", "icsigd.dll", "icsvc.dll", "icsvcext.dll", "icu.dll", "icuin.dll", "icuuc.dll", "idctrls.dll", "idlisten.dll", "idndl.dll", "idstore.dll", "ieadvpack.dll", "ieapfltr.dll", "iedkcs32.dll", "ieframe.dll", "iemigplugin.dll", "iepeers.dll", "ieproxy.dll", "iernonce.dll", "iertutil.dll", "iesetup.dll", "iesysprep.dll", "ieui.dll", "ifmon.dll", "ifsutil.dll", "ifsutilx.dll", "igddiag.dll", "ihds.dll", "ikeext.dll", "imagehlp.dll", "imageres.dll", "imagesp1.dll", "imapi.dll", "imapi2.dll", "imapi2fs.dll", "imgutil.dll", "imm32.dll", "implatsetup.dll", "indexeddblegacy.dll", "inetcomm.dll", "inetmib1.dll", "inetpp.dll", "inetppui.dll", "inetres.dll", "inked.dll", "inkobjcore.dll", "inproclogger.dll", "input.dll", "inputcloudstore.dll", "inputcontroller.dll", "inputhost.dll", "inputservice.dll", "inputswitch.dll", "inseng.dll", "installservice.dll", "internetmail.dll", "internetmailcsp.dll", "invagent.dll", "iologmsg.dll", "iphlpapi.dll", "iphlpsvc.dll", "ipnathlp.dll", "ipnathlpclient.dll", "ippcommon.dll", "ippcommonproxy.dll", "iprtprio.dll", "iprtrmgr.dll", "ipsecsnp.dll", "ipsecsvc.dll", "ipsmsnap.dll", "ipxlatcfg.dll", "iri.dll", "iscsicpl.dll", "iscsidsc.dll", "iscsied.dll", "iscsiexe.dll", "iscsilog.dll", "iscsium.dll", "iscsiwmi.dll", "iscsiwmiv2.dll", "ism.dll", "itircl.dll", "itss.dll", "iuilp.dll", "iumbase.dll", "iumcrypt.dll", "iumdll.dll", "iumsdk.dll", "iyuv_32.dll", "joinproviderol.dll", "joinutil.dll", "jpmapcontrol.dll", "jpndecoder.dll", "jpninputrouter.dll", "jpnranker.dll", "jpnserviceds.dll", "jscript.dll", "jscript9.dll", "jscript9diag.dll", "jsproxy.dll", "kbd101.dll", "kbd101a.dll", "kbd101b.dll", "kbd101c.dll", "kbd103.dll", "kbd106.dll", "kbd106n.dll", "kbda1.dll", "kbda2.dll", "kbda3.dll", "kbdadlm.dll", "kbdal.dll", "kbdarme.dll", "kbdarmph.dll", "kbdarmty.dll", "kbdarmw.dll", "kbdax2.dll", "kbdaze.dll", "kbdazel.dll", "kbdazst.dll", "kbdbash.dll", "kbdbe.dll", "kbdbene.dll", "kbdbgph.dll", "kbdbgph1.dll", "kbdbhc.dll", "kbdblr.dll", "kbdbr.dll", "kbdbu.dll", "kbdbug.dll", "kbdbulg.dll", "kbdca.dll", "kbdcan.dll", "kbdcher.dll", "kbdcherp.dll", "kbdcr.dll", "kbdcz.dll", "kbdcz1.dll", "kbdcz2.dll", "kbdda.dll", "kbddiv1.dll", "kbddiv2.dll", "kbddv.dll", "kbddzo.dll", "kbdes.dll", "kbdest.dll", "kbdfa.dll", "kbdfar.dll", "kbdfc.dll", "kbdfi.dll", "kbdfi1.dll", "kbdfo.dll", "kbdfr.dll", "kbdfthrk.dll", "kbdgae.dll", "kbdgeo.dll", "kbdgeoer.dll", "kbdgeome.dll", "kbdgeooa.dll", "kbdgeoqw.dll", "kbdgkl.dll", "kbdgn.dll", "kbdgr.dll", "kbdgr1.dll", "kbdgrlnd.dll", "kbdgthc.dll", "kbdhau.dll", "kbdhaw.dll", "kbdhe.dll", "kbdhe220.dll", "kbdhe319.dll", "kbdheb.dll", "kbdhebl3.dll", "kbdhela2.dll", "kbdhela3.dll", "kbdhept.dll", "kbdhu.dll", "kbdhu1.dll", "kbdibm02.dll", "kbdibo.dll", "kbdic.dll", "kbdinasa.dll", "kbdinbe1.dll", "kbdinbe2.dll", "kbdinben.dll", "kbdindev.dll", "kbdinen.dll", "kbdinguj.dll", "kbdinhin.dll", "kbdinkan.dll", "kbdinmal.dll", "kbdinmar.dll", "kbdinori.dll", "kbdinpun.dll", "kbdintam.dll", "kbdintel.dll", "kbdinuk2.dll", "kbdir.dll", "kbdit.dll", "kbdit142.dll", "kbdiulat.dll", "kbdjav.dll", "kbdjpn.dll", "kbdkaz.dll", "kbdkhmr.dll", "kbdkni.dll", "kbdkor.dll", "kbdkurd.dll", "kbdkyr.dll", "kbdla.dll", "kbdlao.dll", "kbdlisub.dll", "kbdlisus.dll", "kbdlk41a.dll", "kbdlt.dll", "kbdlt1.dll", "kbdlt2.dll", "kbdlv.dll", "kbdlv1.dll", "kbdlvst.dll", "kbdmac.dll", "kbdmacst.dll", "kbdmaori.dll", "kbdmlt47.dll", "kbdmlt48.dll", "kbdmon.dll", "kbdmonmo.dll", "kbdmonst.dll", "kbdmyan.dll", "kbdne.dll", "kbdnec.dll", "kbdnec95.dll", "kbdnecat.dll", "kbdnecnt.dll", "kbdnepr.dll", "kbdnko.dll", "kbdno.dll", "kbdno1.dll", "kbdnso.dll", "kbdntl.dll", "kbdogham.dll", "kbdolch.dll", "kbdoldit.dll", "kbdosa.dll", "kbdosm.dll", "kbdpash.dll", "kbdphags.dll", "kbdpl.dll", "kbdpl1.dll", "kbdpo.dll", "kbdro.dll", "kbdropr.dll", "kbdrost.dll", "kbdru.dll", "kbdru1.dll", "kbdrum.dll", "kbdsf.dll", "kbdsg.dll", "kbdsl.dll", "kbdsl1.dll", "kbdsmsfi.dll", "kbdsmsno.dll", "kbdsn1.dll", "kbdsora.dll", "kbdsorex.dll", "kbdsors1.dll", "kbdsorst.dll", "kbdsp.dll", "kbdsw.dll", "kbdsw09.dll", "kbdsyr1.dll", "kbdsyr2.dll", "kbdtaile.dll", "kbdtajik.dll", "kbdtam99.dll", "kbdtat.dll", "kbdth0.dll", "kbdth1.dll", "kbdth2.dll", "kbdth3.dll", "kbdtifi.dll", "kbdtifi2.dll", "kbdtiprc.dll", "kbdtiprd.dll", "kbdtt102.dll", "kbdtuf.dll", "kbdtuq.dll", "kbdturme.dll", "kbdtzm.dll", "kbdughr.dll", "kbdughr1.dll", "kbduk.dll", "kbdukx.dll", "kbdur.dll", "kbdur1.dll", "kbdurdu.dll", "kbdus.dll", "kbdusa.dll", "kbdusl.dll", "kbdusr.dll", "kbdusx.dll", "kbduzb.dll", "kbdvntc.dll", "kbdwol.dll", "kbdyak.dll", "kbdyba.dll", "kbdycc.dll", "kbdycl.dll", "kd.dll", "kdcom.dll", "kdcpw.dll", "kdhvcom.dll", "kdnet.dll", "kdnet_uart16550.dll", "kdscli.dll", "kdstub.dll", "kdusb.dll", "kd_02_10df.dll", "kd_02_10ec.dll", "kd_02_1137.dll", "kd_02_14e4.dll", "kd_02_15b3.dll", "kd_02_1969.dll", "kd_02_19a2.dll", "kd_02_1af4.dll", "kd_02_8086.dll", "kd_07_1415.dll", "kd_0c_8086.dll", "kerbclientshared.dll", "kerberos.dll", "kernel32.dll", "kernelbase.dll", "keycredmgr.dll", "keyiso.dll", "keymgr.dll", "knobscore.dll", "knobscsp.dll", "ksuser.dll", "ktmw32.dll", "l2gpstore.dll", "l2nacp.dll", "l2sechc.dll", "laprxy.dll", "legacynetux.dll", "lfsvc.dll", "libcrypto.dll", "licensemanager.dll", "licensingcsp.dll", "licensingdiagspp.dll", "licensingwinrt.dll", "licmgr10.dll", "linkinfo.dll", "lltdapi.dll", "lltdres.dll", "lltdsvc.dll", "lmhsvc.dll", "loadperf.dll", "localsec.dll", "localspl.dll", "localui.dll", "locationapi.dll", "lockappbroker.dll", "lockcontroller.dll", "lockscreendata.dll", "loghours.dll", "logoncli.dll", "logoncontroller.dll", "lpasvc.dll", "lpk.dll", "lsasrv.dll", "lscshostpolicy.dll", "lsm.dll", "lsmproxy.dll", "lstelemetry.dll", "luainstall.dll", "luiapi.dll", "lz32.dll", "magnification.dll", "maintenanceui.dll", "manageci.dll", "mapconfiguration.dll", "mapcontrolcore.dll", "mapgeocoder.dll", "mapi32.dll", "mapistub.dll", "maprouter.dll", "mapsbtsvc.dll", "mapsbtsvcproxy.dll", "mapscsp.dll", "mapsstore.dll", "mapstoasttask.dll", "mapsupdatetask.dll", "mbaeapi.dll", "mbaeapipublic.dll", "mbaexmlparser.dll", "mbmediamanager.dll", "mbsmsapi.dll", "mbussdapi.dll", "mccsengineshared.dll", "mccspal.dll", "mciavi32.dll", "mcicda.dll", "mciqtz32.dll", "mciseq.dll", "mciwave.dll", "mcrecvsrc.dll", "mdmcommon.dll", "mdmdiagnostics.dll", "mdminst.dll", "mdmmigrator.dll", "mdmregistration.dll", "memorydiagnostic.dll", "messagingservice.dll", "mf.dll", "mf3216.dll", "mfaacenc.dll", "mfasfsrcsnk.dll", "mfaudiocnv.dll", "mfc42.dll", "mfc42u.dll", "mfcaptureengine.dll", "mfcore.dll", "mfcsubs.dll", "mfds.dll", "mfdvdec.dll", "mferror.dll", "mfh263enc.dll", "mfh264enc.dll", "mfksproxy.dll", "mfmediaengine.dll", "mfmjpegdec.dll", "mfmkvsrcsnk.dll", "mfmp4srcsnk.dll", "mfmpeg2srcsnk.dll", "mfnetcore.dll", "mfnetsrc.dll", "mfperfhelper.dll", "mfplat.dll", "mfplay.dll", "mfps.dll", "mfreadwrite.dll", "mfsensorgroup.dll", "mfsrcsnk.dll", "mfsvr.dll", "mftranscode.dll", "mfvdsp.dll", "mfvfw.dll", "mfwmaaec.dll", "mgmtapi.dll", "mi.dll", "mibincodec.dll", "midimap.dll", "migisol.dll", "miguiresource.dll", "mimefilt.dll", "mimofcodec.dll", "minstoreevents.dll", "miracastinputmgr.dll", "miracastreceiver.dll", "mirrordrvcompat.dll", "mispace.dll", "mitigationclient.dll", "miutils.dll", "mlang.dll", "mmcbase.dll", "mmcndmgr.dll", "mmcshext.dll", "mmdevapi.dll", "mmgaclient.dll", "mmgaproxystub.dll", "mmres.dll", "mobilenetworking.dll", "modemui.dll", "modernexecserver.dll", "moricons.dll", "moshost.dll", "moshostclient.dll", "moshostcore.dll", "mosstorage.dll", "mp3dmod.dll", "mp43decd.dll", "mp4sdecd.dll", "mpeval.dll", "mpg4decd.dll", "mpr.dll", "mprapi.dll", "mprddm.dll", "mprdim.dll", "mprext.dll", "mprmsg.dll", "mpssvc.dll", "mpunits.dll", "mrmcorer.dll", "mrmdeploy.dll", "mrmindexer.dll", "mrt100.dll", "mrt_map.dll", "msaatext.dll", "msac3enc.dll", "msacm32.dll", "msafd.dll", "msajapi.dll", "msalacdecoder.dll", "msalacencoder.dll", "msamrnbdecoder.dll", "msamrnbencoder.dll", "msamrnbsink.dll", "msamrnbsource.dll", "msasn1.dll", "msauddecmft.dll", "msaudite.dll", "msauserext.dll", "mscandui.dll", "mscat32.dll", "msclmd.dll", "mscms.dll", "mscoree.dll", "mscorier.dll", "mscories.dll", "msctf.dll", "msctfmonitor.dll", "msctfp.dll", "msctfui.dll", "msctfuimanager.dll", "msdadiag.dll", "msdart.dll", "msdelta.dll", "msdmo.dll", "msdrm.dll", "msdtckrm.dll", "msdtclog.dll", "msdtcprx.dll", "msdtcspoffln.dll", "msdtctm.dll", "msdtcuiu.dll", "msdtcvsp1res.dll", "msfeeds.dll", "msfeedsbs.dll", "msflacdecoder.dll", "msflacencoder.dll", "msftedit.dll", "msheif.dll", "mshtml.dll", "mshtmldac.dll", "mshtmled.dll", "mshtmler.dll", "msi.dll", "msicofire.dll", "msidcrl40.dll", "msident.dll", "msidle.dll", "msidntld.dll", "msieftp.dll", "msihnd.dll", "msiltcfg.dll", "msimg32.dll", "msimsg.dll", "msimtf.dll", "msisip.dll", "msiso.dll", "msiwer.dll", "mskeyprotcli.dll", "mskeyprotect.dll", "msls31.dll", "msmpeg2adec.dll", "msmpeg2enc.dll", "msmpeg2vdec.dll", "msobjs.dll", "msoert2.dll", "msopusdecoder.dll", "mspatcha.dll", "mspatchc.dll", "msphotography.dll", "msports.dll", "msprivs.dll", "msrahc.dll", "msrating.dll", "msrawimage.dll", "msrdc.dll", "msrdpwebaccess.dll", "msrle32.dll", "msscntrs.dll", "mssecuser.dll", "mssign32.dll", "mssip32.dll", "mssitlb.dll", "mssph.dll", "mssprxy.dll", "mssrch.dll", "mssvp.dll", "mstask.dll", "mstextprediction.dll", "mstscax.dll", "msutb.dll", "msv1_0.dll", "msvcirt.dll", "msvcp110_win.dll", "msvcp120_clr0400.dll", "msvcp140_clr0400.dll", "msvcp60.dll", "msvcp_win.dll", "msvcr100_clr0400.dll", "msvcr120_clr0400.dll", "msvcrt.dll", "msvfw32.dll", "msvidc32.dll", "msvidctl.dll", "msvideodsp.dll", "msvp9dec.dll", "msvproc.dll", "msvpxenc.dll", "mswb7.dll", "mswebp.dll", "mswmdm.dll", "mswsock.dll", "msxml3.dll", "msxml3r.dll", "msxml6.dll", "msxml6r.dll", "msyuv.dll", "mtcmodel.dll", "mtf.dll", "mtfappserviceds.dll", "mtfdecoder.dll", "mtffuzzyds.dll", "mtfserver.dll", "mtfspellcheckds.dll", "mtxclu.dll", "mtxdm.dll", "mtxex.dll", "mtxoci.dll", "muifontsetup.dll", "mycomput.dll", "mydocs.dll", "napcrypt.dll", "napinsp.dll", "naturalauth.dll", "naturallanguage6.dll", "navshutdown.dll", "ncaapi.dll", "ncasvc.dll", "ncbservice.dll", "ncdautosetup.dll", "ncdprop.dll", "nci.dll", "ncobjapi.dll", "ncrypt.dll", "ncryptprov.dll", "ncryptsslp.dll", "ncsi.dll", "ncuprov.dll", "nddeapi.dll", "ndfapi.dll", "ndfetw.dll", "ndfhcdiscovery.dll", "ndishc.dll", "ndproxystub.dll", "nduprov.dll", "negoexts.dll", "netapi32.dll", "netbios.dll", "netcenter.dll", "netcfgx.dll", "netcorehc.dll", "netdiagfx.dll", "netdriverinstall.dll", "netevent.dll", "netfxperf.dll", "neth.dll", "netid.dll", "netiohlp.dll", "netjoin.dll", "netlogon.dll", "netman.dll", "netmsg.dll", "netplwiz.dll", "netprofm.dll", "netprofmsvc.dll", "netprovfw.dll", "netprovisionsp.dll", "netsetupapi.dll", "netsetupengine.dll", "netsetupshim.dll", "netsetupsvc.dll", "netshell.dll", "nettrace.dll", "netutils.dll", "networkexplorer.dll", "networkhelper.dll", "networkicon.dll", "networkproxycsp.dll", "networkstatus.dll", "networkuxbroker.dll", "newdev.dll", "nfcradiomedia.dll", "ngccredprov.dll", "ngcctnr.dll", "ngcctnrsvc.dll", "ngcisoctnr.dll", "ngckeyenum.dll", "ngcksp.dll", "ngclocal.dll", "ngcpopkeysrv.dll", "ngcprocsp.dll", "ngcrecovery.dll", "ngcsvc.dll", "ngctasks.dll", "ninput.dll", "nlaapi.dll", "nlahc.dll", "nlasvc.dll", "nlhtml.dll", "nlmgp.dll", "nlmproxy.dll", "nlmsprep.dll", "nlsbres.dll", "nlsdata0000.dll", "nlsdata0009.dll", "nlsdl.dll", "nlslexicons0009.dll", "nmadirect.dll", "normaliz.dll", "npmproxy.dll", "npsm.dll", "nrpsrv.dll", "nshhttp.dll", "nshipsec.dll", "nshwfp.dll", "nsi.dll", "nsisvc.dll", "ntasn1.dll", "ntdll.dll", "ntdsapi.dll", "ntlanman.dll", "ntlanui2.dll", "ntlmshared.dll", "ntmarta.dll", "ntprint.dll", "ntshrui.dll", "ntvdm64.dll", "objsel.dll", "occache.dll", "ocsetapi.dll", "odbc32.dll", "odbcbcp.dll", "odbcconf.dll", "odbccp32.dll", "odbccr32.dll", "odbccu32.dll", "odbcint.dll", "odbctrac.dll", "oemlicense.dll", "offfilt.dll", "officecsp.dll", "offlinelsa.dll", "offlinesam.dll", "offreg.dll", "ole32.dll", "oleacc.dll", "oleacchooks.dll", "oleaccrc.dll", "oleaut32.dll", "oledlg.dll", "oleprn.dll", "omadmagent.dll", "omadmapi.dll", "onebackuphandler.dll", "onex.dll", "onexui.dll", "opcservices.dll", "opengl32.dll", "ortcengine.dll", "osbaseln.dll", "osksupport.dll", "osuninst.dll", "p2p.dll", "p2pgraph.dll", "p2pnetsh.dll", "p2psvc.dll", "packager.dll", "panmap.dll", "pautoenr.dll", "pcacli.dll", "pcadm.dll", "pcaevts.dll", "pcasvc.dll", "pcaui.dll", "pcpksp.dll", "pcsvdevice.dll", "pcwum.dll", "pcwutl.dll", "pdh.dll", "pdhui.dll", "peerdist.dll", "peerdistad.dll", "peerdistcleaner.dll", "peerdistsh.dll", "peerdistsvc.dll", "peopleapis.dll", "peopleband.dll", "perceptiondevice.dll", "perfctrs.dll", "perfdisk.dll", "perfnet.dll", "perfos.dll", "perfproc.dll", "perfts.dll", "phoneom.dll", "phoneproviders.dll", "phoneservice.dll", "phoneserviceres.dll", "phoneutil.dll", "phoneutilres.dll", "photowiz.dll", "pickerplatform.dll", "pid.dll", "pidgenx.dll", "pifmgr.dll", "pimstore.dll", "pkeyhelper.dll", "pktmonapi.dll", "pku2u.dll", "pla.dll", "playlistfolder.dll", "playsndsrv.dll", "playtodevice.dll", "playtomanager.dll", "playtomenu.dll", "playtoreceiver.dll", "ploptin.dll", "pmcsnap.dll", "pngfilt.dll", "pnidui.dll", "pnpclean.dll", "pnppolicy.dll", "pnpts.dll", "pnpui.dll", "pnpxassoc.dll", "pnpxassocprx.dll", "pnrpauto.dll", "pnrphc.dll", "pnrpnsp.dll", "pnrpsvc.dll", "policymanager.dll", "polstore.dll", "posetup.dll", "posyncservices.dll", "pots.dll", "powercpl.dll", "powrprof.dll", "ppcsnap.dll", "prauthproviders.dll", "prflbmsg.dll", "printui.dll", "printwsdahost.dll", "prm0009.dll", "prncache.dll", "prnfldr.dll", "prnntfy.dll", "prntvpt.dll", "profapi.dll", "profext.dll", "profprov.dll", "profsvc.dll", "profsvcext.dll", "propsys.dll", "provcore.dll", "provdatastore.dll", "provdiagnostics.dll", "provengine.dll", "provhandlers.dll", "provisioningcsp.dll", "provmigrate.dll", "provops.dll", "provplugineng.dll", "provsysprep.dll", "provthrd.dll", "proximitycommon.dll", "proximityservice.dll", "prvdmofcomp.dll", "psapi.dll", "pshed.dll", "psisdecd.dll", "psmsrv.dll", "pstask.dll", "pstorec.dll", "ptpprov.dll", "puiapi.dll", "puiobj.dll", "pushtoinstall.dll", "pwlauncher.dll", "pwrshplugin.dll", "pwsso.dll", "qasf.dll", "qcap.dll", "qdv.dll", "qdvd.dll", "qedit.dll", "qedwipes.dll", "qmgr.dll", "query.dll", "quiethours.dll", "qwave.dll", "racengn.dll", "racpldlg.dll", "radardt.dll", "radarrs.dll", "radcui.dll", "rasadhlp.dll", "rasapi32.dll", "rasauto.dll", "raschap.dll", "raschapext.dll", "rasctrs.dll", "rascustom.dll", "rasdiag.dll", "rasdlg.dll", "rasgcw.dll", "rasman.dll", "rasmans.dll", "rasmbmgr.dll", "rasmediamanager.dll", "rasmm.dll", "rasmontr.dll", "rasplap.dll", "rasppp.dll", "rastapi.dll", "rastls.dll", "rastlsext.dll", "rdbui.dll", "rdpbase.dll", "rdpcfgex.dll", "rdpcore.dll", "rdpcorets.dll", "rdpencom.dll", "rdpendp.dll", "rdpnano.dll", "rdpsaps.dll", "rdpserverbase.dll", "rdpsharercom.dll", "rdpudd.dll", "rdpviewerax.dll", "rdsappxhelper.dll", "rdsdwmdr.dll", "rdvvmtransport.dll", "rdxservice.dll", "rdxtaskfactory.dll", "reagent.dll", "reagenttask.dll", "recovery.dll", "regapi.dll", "regctrl.dll", "regidle.dll", "regsvc.dll", "reguwpapi.dll", "reinfo.dll", "remotepg.dll", "remotewipecsp.dll", "reportingcsp.dll", "resampledmo.dll", "resbparser.dll", "reseteng.dll", "resetengine.dll", "resetengonline.dll", "resourcemapper.dll", "resutils.dll", "rgb9rast.dll", "riched20.dll", "riched32.dll", "rjvmdmconfig.dll", "rmapi.dll", "rmclient.dll", "rnr20.dll", "roamingsecurity.dll", "rometadata.dll", "rotmgr.dll", "rpcepmap.dll", "rpchttp.dll", "rpcns4.dll", "rpcnsh.dll", "rpcrt4.dll", "rpcrtremote.dll", "rpcss.dll", "rsaenh.dll", "rshx32.dll", "rstrtmgr.dll", "rtffilt.dll", "rtm.dll", "rtmediaframe.dll", "rtmmvrortc.dll", "rtutils.dll", "rtworkq.dll", "rulebasedds.dll", "samcli.dll", "samlib.dll", "samsrv.dll", "sas.dll", "sbe.dll", "sbeio.dll", "sberes.dll", "sbservicetrigger.dll", "scansetting.dll", "scardbi.dll", "scarddlg.dll", "scardsvr.dll", "scavengeui.dll", "scdeviceenum.dll", "scecli.dll", "scesrv.dll", "schannel.dll", "schedcli.dll", "schedsvc.dll", "scksp.dll", "scripto.dll", "scrobj.dll", "scrptadm.dll", "scrrun.dll", "sdcpl.dll", "sdds.dll", "sdengin2.dll", "sdfhost.dll", "sdhcinst.dll", "sdiageng.dll", "sdiagprv.dll", "sdiagschd.dll", "sdohlp.dll", "sdrsvc.dll", "sdshext.dll", "searchfolder.dll", "sechost.dll", "seclogon.dll", "secproc.dll", "secproc_isv.dll", "secproc_ssp.dll", "secproc_ssp_isv.dll", "secur32.dll", "security.dll", "semgrps.dll", "semgrsvc.dll", "sendmail.dll", "sens.dll", "sensapi.dll", "sensorsapi.dll", "sensorscpl.dll", "sensorservice.dll", "sensorsnativeapi.dll", "sensorsutilsv2.dll", "sensrsvc.dll", "serialui.dll", "servicinguapi.dll", "serwvdrv.dll", "sessenv.dll", "setbcdlocale.dll", "settingmonitor.dll", "settingsync.dll", "settingsynccore.dll", "setupapi.dll", "setupcl.dll", "setupcln.dll", "setupetw.dll", "sfc.dll", "sfc_os.dll", "sgrmenclave.dll", "shacct.dll", "shacctprofile.dll", "sharedpccsp.dll", "sharedrealitysvc.dll", "sharehost.dll", "sharemediacpl.dll", "shcore.dll", "shdocvw.dll", "shell32.dll", "shellstyle.dll", "shfolder.dll", "shgina.dll", "shimeng.dll", "shimgvw.dll", "shlwapi.dll", "shpafact.dll", "shsetup.dll", "shsvcs.dll", "shunimpl.dll", "shutdownext.dll", "shutdownux.dll", "shwebsvc.dll", "signdrv.dll", "simauth.dll", "simcfg.dll", "skci.dll", "slc.dll", "slcext.dll", "slwga.dll", "smartscreenps.dll", "smbhelperclass.dll", "smbwmiv2.dll", "smiengine.dll", "smphost.dll", "smsroutersvc.dll", "sndvolsso.dll", "snmpapi.dll", "socialapis.dll", "softkbd.dll", "softpub.dll", "sortwindows61.dll", "sortwindows62.dll", "spacebridge.dll", "spacecontrol.dll", "spatializerapo.dll", "spatialstore.dll", "spbcd.dll", "speechpal.dll", "spfileq.dll", "spinf.dll", "spmpm.dll", "spnet.dll", "spoolss.dll", "spopk.dll", "spp.dll", "sppc.dll", "sppcext.dll", "sppcomapi.dll", "sppcommdlg.dll", "sppinst.dll", "sppnp.dll", "sppobjs.dll", "sppwinob.dll", "sppwmi.dll", "spwinsat.dll", "spwizeng.dll", "spwizimg.dll", "spwizres.dll", "spwmp.dll", "sqlsrv32.dll", "sqmapi.dll", "srchadmin.dll", "srclient.dll", "srcore.dll", "srevents.dll", "srh.dll", "srhelper.dll", "srm.dll", "srmclient.dll", "srmlib.dll", "srmscan.dll", "srmshell.dll", "srmstormod.dll", "srmtrace.dll", "srm_ps.dll", "srpapi.dll", "srrstr.dll", "srumapi.dll", "srumsvc.dll", "srvcli.dll", "srvsvc.dll", "srwmi.dll", "sscore.dll", "sscoreext.dll", "ssdm.dll", "ssdpapi.dll", "ssdpsrv.dll", "sspicli.dll", "sspisrv.dll", "ssshim.dll", "sstpsvc.dll", "starttiledata.dll", "startupscan.dll", "stclient.dll", "sti.dll", "sti_ci.dll", "stobject.dll", "storageusage.dll", "storagewmi.dll", "storewuauth.dll", "storprop.dll", "storsvc.dll", "streamci.dll", "structuredquery.dll", "sud.dll", "svf.dll", "svsvc.dll", "swprv.dll", "sxproxy.dll", "sxs.dll", "sxshared.dll", "sxssrv.dll", "sxsstore.dll", "synccenter.dll", "synccontroller.dll", "synchostps.dll", "syncproxy.dll", "syncreg.dll", "syncres.dll", "syncsettings.dll", "syncutil.dll", "sysclass.dll", "sysfxui.dll", "sysmain.dll", "sysntfy.dll", "syssetup.dll", "systemcpl.dll", "t2embed.dll", "tabbtn.dll", "tabbtnex.dll", "tabsvc.dll", "tapi3.dll", "tapi32.dll", "tapilua.dll", "tapimigplugin.dll", "tapiperf.dll", "tapisrv.dll", "tapisysprep.dll", "tapiui.dll", "taskapis.dll", "taskbarcpl.dll", "taskcomp.dll", "taskschd.dll", "taskschdps.dll", "tbauth.dll", "tbs.dll", "tcbloader.dll", "tcpipcfg.dll", "tcpmib.dll", "tcpmon.dll", "tcpmonui.dll", "tdh.dll", "tdlmigration.dll", "tellib.dll", "termmgr.dll", "termsrv.dll", "tetheringclient.dll", "tetheringmgr.dll", "tetheringservice.dll", "tetheringstation.dll", "textshaping.dll", "themecpl.dll", "themeservice.dll", "themeui.dll", "threadpoolwinrt.dll", "thumbcache.dll", "timebrokerclient.dll", "timebrokerserver.dll", "timesync.dll", "timesynctask.dll", "tlscsp.dll", "tokenbinding.dll", "tokenbroker.dll", "tokenbrokerui.dll", "tpmcertresources.dll", "tpmcompc.dll", "tpmtasks.dll", "tpmvsc.dll", "tquery.dll", "traffic.dll", "transportdsa.dll", "trie.dll", "trkwks.dll", "tsbyuv.dll", "tscfgwmi.dll", "tserrredir.dll", "tsf3gip.dll", "tsgqec.dll", "tsmf.dll", "tspkg.dll", "tspubwmi.dll", "tssessionux.dll", "tssrvlic.dll", "tsworkspace.dll", "ttdloader.dll", "ttdplm.dll", "ttdrecord.dll", "ttdrecordcpu.dll", "ttlsauth.dll", "ttlscfg.dll", "ttlsext.dll", "tvratings.dll", "twext.dll", "twinapi.dll", "twinui.dll", "txflog.dll", "txfw32.dll", "tzautoupdate.dll", "tzres.dll", "tzsyncres.dll", "ubpm.dll", "ucmhc.dll", "ucrtbase.dll", "ucrtbase_clr0400.dll", "ucrtbase_enclave.dll", "udhisapi.dll", "udwm.dll", "ueficsp.dll", "uexfat.dll", "ufat.dll", "uiamanager.dll", "uianimation.dll", "uiautomationcore.dll", "uicom.dll", "uireng.dll", "uiribbon.dll", "uiribbonres.dll", "ulib.dll", "umb.dll", "umdmxfrm.dll", "umpdc.dll", "umpnpmgr.dll", "umpo-overrides.dll", "umpo.dll", "umpoext.dll", "umpowmi.dll", "umrdp.dll", "unattend.dll", "unenrollhook.dll", "unimdmat.dll", "uniplat.dll", "unistore.dll", "untfs.dll", "updateagent.dll", "updatecsp.dll", "updatepolicy.dll", "upnp.dll", "upnphost.dll", "upshared.dll", "urefs.dll", "urefsv1.dll", "ureg.dll", "url.dll", "urlmon.dll", "usbcapi.dll", "usbceip.dll", "usbmon.dll", "usbperf.dll", "usbpmapi.dll", "usbtask.dll", "usbui.dll", "user32.dll", "usercpl.dll", "userdataservice.dll", "userdatatimeutil.dll", "userenv.dll", "userinitext.dll", "usermgr.dll", "usermgrcli.dll", "usermgrproxy.dll", "usoapi.dll", "usocoreps.dll", "usosvc.dll", "usp10.dll", "ustprov.dll", "utcutil.dll", "utildll.dll", "uudf.dll", "uvcmodel.dll", "uwfcfgmgmt.dll", "uwfcsp.dll", "uwfservicingapi.dll", "uxinit.dll", "uxlib.dll", "uxlibres.dll", "uxtheme.dll", "vac.dll", "van.dll", "vault.dll", "vaultcds.dll", "vaultcli.dll", "vaultroaming.dll", "vaultsvc.dll", "vbsapi.dll", "vbscript.dll", "vbssysprep.dll", "vcardparser.dll", "vdsbas.dll", "vdsdyn.dll", "vdsutil.dll", "vdsvd.dll", "vds_ps.dll", "verifier.dll", "vertdll.dll", "vfuprov.dll", "vfwwdm32.dll", "vhfum.dll", "vid.dll", "videohandlers.dll", "vidreszr.dll", "virtdisk.dll", "vmbuspipe.dll", "vmdevicehost.dll", "vmictimeprovider.dll", "vmrdvcore.dll", "voiprt.dll", "vpnike.dll", "vpnikeapi.dll", "vpnsohdesktop.dll", "vpnv2csp.dll", "vscmgrps.dll", "vssapi.dll", "vsstrace.dll", "vss_ps.dll", "w32time.dll", "w32topl.dll", "waasassessment.dll", "waasmediccapsule.dll", "waasmedicps.dll", "waasmedicsvc.dll", "wabsyncprovider.dll", "walletproxy.dll", "walletservice.dll", "wavemsp.dll", "wbemcomn.dll", "wbiosrvc.dll", "wci.dll", "wcimage.dll", "wcmapi.dll", "wcmcsp.dll", "wcmsvc.dll", "wcnapi.dll", "wcncsvc.dll", "wcneapauthproxy.dll", "wcneappeerproxy.dll", "wcnnetsh.dll", "wcnwiz.dll", "wc_storage.dll", "wdc.dll", "wdi.dll", "wdigest.dll", "wdscore.dll", "webauthn.dll", "webcamui.dll", "webcheck.dll", "webclnt.dll", "webio.dll", "webservices.dll", "websocket.dll", "wecapi.dll", "wecsvc.dll", "wephostsvc.dll", "wer.dll", "werconcpl.dll", "wercplsupport.dll", "werenc.dll", "weretw.dll", "wersvc.dll", "werui.dll", "wevtapi.dll", "wevtfwd.dll", "wevtsvc.dll", "wfapigp.dll", "wfdprov.dll", "wfdsconmgr.dll", "wfdsconmgrsvc.dll", "wfhc.dll", "whealogr.dll", "whhelper.dll", "wiaaut.dll", "wiadefui.dll", "wiadss.dll", "wiarpc.dll", "wiascanprofiles.dll", "wiaservc.dll", "wiashext.dll", "wiatrace.dll", "wificloudstore.dll", "wificonfigsp.dll", "wifidisplay.dll", "wimgapi.dll", "win32spl.dll", "win32u.dll", "winbio.dll", "winbiodatamodel.dll", "winbioext.dll", "winbrand.dll", "wincorlib.dll", "wincredprovider.dll", "wincredui.dll", "windowmanagement.dll", "windowscodecs.dll", "windowscodecsext.dll", "windowscodecsraw.dll", "windowsiotcsp.dll", "windowslivelogin.dll", "winethc.dll", "winhttp.dll", "winhttpcom.dll", "winhvemulation.dll", "winhvplatform.dll", "wininet.dll", "wininetlui.dll", "wininitext.dll", "winipcfile.dll", "winipcsecproc.dll", "winipsec.dll", "winlangdb.dll", "winlogonext.dll", "winmde.dll", "winml.dll", "winmm.dll", "winmmbase.dll", "winmsipc.dll", "winnlsres.dll", "winnsi.dll", "winreagent.dll", "winrnr.dll", "winrscmd.dll", "winrsmgr.dll", "winrssrv.dll", "winrttracing.dll", "winsatapi.dll", "winscard.dll", "winsetupui.dll", "winshfhc.dll", "winsku.dll", "winsockhc.dll", "winsqlite3.dll", "winsrpc.dll", "winsrv.dll", "winsrvext.dll", "winsta.dll", "winsync.dll", "winsyncmetastore.dll", "winsyncproviders.dll", "wintrust.dll", "wintypes.dll", "winusb.dll", "wirednetworkcsp.dll", "wisp.dll", "wkscli.dll", "wkspbrokerax.dll", "wksprtps.dll", "wkssvc.dll", "wlanapi.dll", "wlancfg.dll", "wlanconn.dll", "wlandlg.dll", "wlangpui.dll", "wlanhc.dll", "wlanhlp.dll", "wlanmediamanager.dll", "wlanmm.dll", "wlanmsm.dll", "wlanpref.dll", "wlanradiomanager.dll", "wlansec.dll", "wlansvc.dll", "wlansvcpal.dll", "wlanui.dll", "wlanutil.dll", "wldap32.dll", "wldp.dll", "wlgpclnt.dll", "wlidcli.dll", "wlidcredprov.dll", "wlidfdp.dll", "wlidnsp.dll", "wlidprov.dll", "wlidres.dll", "wlidsvc.dll", "wmadmod.dll", "wmadmoe.dll", "wmalfxgfxdsp.dll", "wmasf.dll", "wmcodecdspps.dll", "wmdmlog.dll", "wmdmps.dll", "wmdrmsdk.dll", "wmerror.dll", "wmi.dll", "wmiclnt.dll", "wmicmiplugin.dll", "wmidcom.dll", "wmidx.dll", "wmiprop.dll", "wmitomi.dll", "wmnetmgr.dll", "wmp.dll", "wmpdui.dll", "wmpdxm.dll", "wmpeffects.dll", "wmphoto.dll", "wmploc.dll", "wmpps.dll", "wmpshell.dll", "wmsgapi.dll", "wmspdmod.dll", "wmspdmoe.dll", "wmvcore.dll", "wmvdecod.dll", "wmvdspa.dll", "wmvencod.dll", "wmvsdecd.dll", "wmvsencd.dll", "wmvxencd.dll", "woftasks.dll", "wofutil.dll", "wordbreakers.dll", "workfoldersgpext.dll", "workfoldersres.dll", "workfoldersshell.dll", "workfolderssvc.dll", "wosc.dll", "wow64.dll", "wow64cpu.dll", "wow64win.dll", "wpbcreds.dll", "wpc.dll", "wpcapi.dll", "wpcdesktopmonsvc.dll", "wpcproxystubs.dll", "wpcrefreshtask.dll", "wpcwebfilter.dll", "wpdbusenum.dll", "wpdshext.dll", "wpdshserviceobj.dll", "wpdsp.dll", "wpd_ci.dll", "wpnapps.dll", "wpnclient.dll", "wpncore.dll", "wpninprc.dll", "wpnprv.dll", "wpnservice.dll", "wpnsruprov.dll", "wpnuserservice.dll", "wpportinglibrary.dll", "wpprecorderum.dll", "wptaskscheduler.dll", "wpx.dll", "ws2help.dll", "ws2_32.dll", "wscapi.dll", "wscinterop.dll", "wscisvif.dll", "wsclient.dll", "wscproxystub.dll", "wscsvc.dll", "wsdapi.dll", "wsdchngr.dll", "wsdprintproxy.dll", "wsdproviderutil.dll", "wsdscanproxy.dll", "wsecedit.dll", "wsepno.dll", "wshbth.dll", "wshcon.dll", "wshelper.dll", "wshext.dll", "wshhyperv.dll", "wship6.dll", "wshqos.dll", "wshrm.dll", "wshtcpip.dll", "wshunix.dll", "wslapi.dll", "wsmagent.dll", "wsmauto.dll", "wsmplpxy.dll", "wsmres.dll", "wsmsvc.dll", "wsmwmipl.dll", "wsnmp32.dll", "wsock32.dll", "wsplib.dll", "wsp_fs.dll", "wsp_health.dll", "wsp_sr.dll", "wtsapi32.dll", "wuapi.dll", "wuaueng.dll", "wuceffects.dll", "wudfcoinstaller.dll", "wudfplatform.dll", "wudfsmcclassext.dll", "wudfx.dll", "wudfx02000.dll", "wudriver.dll", "wups.dll", "wups2.dll", "wuuhext.dll", "wuuhosdeployment.dll", "wvc.dll", "wwaapi.dll", "wwaext.dll", "wwanapi.dll", "wwancfg.dll", "wwanhc.dll", "wwanprotdim.dll", "wwanradiomanager.dll", "wwansvc.dll", "wwapi.dll", "xamltilerender.dll", "xaudio2_8.dll", "xaudio2_9.dll", "xblauthmanager.dll", "xblgamesave.dll", "xblgamesaveext.dll", "xblgamesaveproxy.dll", "xboxgipsvc.dll", "xboxgipsynthetic.dll", "xboxnetapisvc.dll", "xinput1_4.dll", "xinput9_1_0.dll", "xinputuap.dll", "xmlfilter.dll", "xmllite.dll", "xmlprovi.dll", "xolehlp.dll", "xpsgdiconverter.dll", "xpsprint.dll", "xpspushlayer.dll", "xpsrasterservice.dll", "xpsservices.dll", "xwizards.dll", "xwreg.dll", "xwtpdui.dll", "xwtpw32.dll", "zipcontainer.dll", "zipfldr.dll", "bootsvc.dll", "halextintcpsedma.dll", "icsvcvss.dll", "ieproxydesktop.dll", "lsaadt.dll", "nlansp_c.dll", "nrtapi.dll", "opencl.dll", "pfclient.dll", "pnpdiag.dll", "prxyqry.dll", "rdpnanotransport.dll", "servicingcommon.dll", "sortwindows63.dll", "sstpcfg.dll", "tdhres.dll", "umpodev.dll", "utcapi.dll", "windlp.dll", "wow64base.dll", "wow64con.dll", "blbuires.dll", "bpainst.dll", "cbclient.dll", "certadm.dll", "certocm.dll", "certpick.dll", "csdeployres.dll", "dsdeployres.dll", "eapa3hst.dll", "eapacfg.dll", "eapahost.dll", "elsext.dll", "encdump.dll", "escmigplugin.dll", "fsclient.dll", "fsdeployres.dll", "fssminst.dll", "fssmres.dll", "fssprov.dll", "ipamapi.dll", "kpssvc.dll", "lbfoadminlib.dll", "mintdh.dll", "mmci.dll", "mmcico.dll", "mprsnap.dll", "mstsmhst.dll", "mstsmmc.dll", "muxinst.dll", "personax.dll", "rassfm.dll", "rasuser.dll", "rdmsinst.dll", "rdmsres.dll", "rtrfiltr.dll", "sacsvr.dll", "scrdenrl.dll", "sdclient.dll", "sharedstartmodel.dll", "smsrouter.dll", "spwizimg_svr.dll", "sqlcecompact40.dll", "sqlceoledb40.dll", "sqlceqp40.dll", "sqlcese40.dll", "srvmgrinst.dll", "svrmgrnc.dll", "tapisnap.dll", "tlsbrand.dll", "tsec.dll", "tsprop.dll", "tspubiconhelper.dll", "tssdjet.dll", "tsuserex.dll", "ualapi.dll", "ualsvc.dll", "umcres.dll", "updatehandlers.dll", "usocore.dll", "vssui.dll", "wsbappres.dll", "wsbonline.dll", "wsmselpl.dll", "wsmselrr.dll", "xpsfilt.dll", "xpsshhdr.dll" + ) and + not ( + ( + dll.name : "icuuc.dll" and dll.code_signature.subject_name in ( + "Valve", "Valve Corp.", "Avanquest Software (7270356 Canada Inc)", "Adobe Inc." + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : ("timeSync.dll", "appInfo.dll") and dll.code_signature.subject_name in ( + "VMware Inc.", "VMware, Inc." + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "libcrypto.dll" and dll.code_signature.subject_name in ( + "NoMachine S.a.r.l.", "Oculus VR, LLC" + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "ucrtbase.dll" and dll.code_signature.subject_name in ( + "Proofpoint, Inc.", "Rapid7 LLC", "Eclipse.org Foundation, Inc.", "Amazon.com Services LLC", "Windows Phone", "London Jamocha Community CIC", "Palo Alto Networks (Netherlands) B.V.", "Sophos Ltd" + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "d3d9.dll" and dll.code_signature.subject_name == "Open Source Developer Alban CLIQUET" and dll.code_signature.trusted == true + ) or + ( + dll.name : ("libcrypto.dll", "wmi.dll", "geolocation.dll", "kerberos.dll", "UpdateAgent.dll") and + dll.code_signature.subject_name == "Bitdefender SRL" and dll.code_signature.trusted == true + ) or + (dll.name : "ICMP.dll" and dll.code_signature.subject_name == "Paessler AG" and dll.code_signature.trusted == true) or + (dll.name : "dbghelp.dll" and dll.code_signature.trusted == true) or + (dll.name : "DirectML.dll" and dll.code_signature.subject_name == "Adobe Inc." and dll.code_signature.trusted == true) or + (dll.name : "icsvc.dll" and dll.code_signature.subject_name in ("Dell Inc", "Dell Technologies Inc.") and dll.code_signature.trusted == true) or + (dll.name : "offreg.dll" and dll.code_signature.subject_name in ("Malwarebytes Inc.", "Malwarebytes Inc") and dll.code_signature.trusted == true) or + (dll.name : ("AppMgr.dll", "icuuc.dll") and dll.code_signature.subject_name in ("Autodesk, Inc", "Autodesk, Inc.") and dll.code_signature.trusted == true) or + (dll.name : ("SsShim.dll", "Msi.dll", "wdscore.dll") and process.name : "DismHost.exe" and dll.path : "C:\\Windows\\Temp\\*") or + (dll.code_signature.trusted == true and + dll.code_signature.subject_name in ( + "ALIBABA CLOUD COMPUTING LTD", + "Epic Systems Corporation", + "Google LLC", + "Agilysys, Inc.", + "CD PROJEKT S.A.", + "Check Point Software Technologies Ltd.", + "Dedalus Italia S.P.A.", + "AOMEI International Network Limited", + "CHENGDU AOMEI TECHNOLOGY CO., LTD.", + "GN Hearing A/S", + "Paessler GmbH", + "Symantec Corporation")) or + ( + dll.path : ( + "?:\\Windows\\SystemApps\\*\\dxgi.dll", + "?:\\Windows\\SystemApps\\*\\wincorlib.dll", + "?:\\Windows\\dxgi.dll", + "?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll", + "?:\\Program Files (x86)\\SAP\\FrontEnd\\SAPgui\\dbghelp.dll", + "?:\\Program Files (x86)\\Common Files\\Crystal Decision\\2.0\\bin\\atl.dll" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing +** ID: T1553.002 +** Reference URL: https://attack.mitre.org/techniques/T1553/002/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-openssh-backdoor-logging-activity.asciidoc new file mode 100644 index 0000000000..09300736da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-openssh-backdoor-logging-activity.asciidoc @@ -0,0 +1,221 @@ +[[prebuilt-rule-8-19-26-potential-openssh-backdoor-logging-activity]] +=== Potential OpenSSH Backdoor Logging Activity + +Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/eset/malware-ioc/tree/master/sshdoor +* https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 216 + +*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 Potential OpenSSH Backdoor Logging Activity* + + +OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. + + +*Possible investigation steps* + + +- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". +- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. +- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. +- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. +- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. +- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. + + +*False positive analysis* + + +- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. +- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. +- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. +- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. +- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. +- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. +- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. +- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. +- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.name in ("ssh", "sshd") and + ( + ( + file.name : (".*", "~*", "*~") and not file.name : ( + ".cache", ".viminfo", ".bash_history", ".google_authenticator", ".jelenv", ".csvignore", ".rtreport", ".git*" + ) + ) or + file.extension : ("in", "out", "ini", "h", "gz", "so", "sock", "sync", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9") or + file.path : + ( + "/tmp/*", + "/var/tmp/*", + "/dev/shm/*", + "/usr/share/*", + "/usr/include/*", + "/usr/local/include/*", + "/usr/share/man/*", + "/usr/local/share/*", + "/usr/lib/*.so.*", + "/usr/bin/ssd", + "/var/run/sshd/sshd.pid", + "/var/run/nscd/ns.pid", + "/var/run/udev/ud.pid", + "/var/run/udevd.pid" + ) + ) and + not file.path like ("/tmp/krb5cc*", "/tmp/ansible_*", "/storage/*", "/tmp/clearsigned.message.*", "/var/sftp/refinitiv/*", "/tmp/fileutil.message.*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc new file mode 100644 index 0000000000..1b74220bd0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-26-potential-redis-config-set-cron-directory-persistence-redisraider]] +=== Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider) + +This rule detects attempts to abuse Redis CONFIG SET commands to redirect the database save directory to a cron directory on Linux hosts. Attackers issue CONFIG SET dir to a cron path such as /etc/cron.d or /var/spool/cron, set a filename via CONFIG SET dbfilename, write a cron payload via SET, and then call BGSAVE to flush it to disk, establishing persistence for execution of an XMRig cryptominer. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/redisraider-mining-campaign/ +* https://attack.mitre.org/techniques/T1053/003/ +* https://attack.mitre.org/techniques/T1496/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*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 Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider)* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers exploit this to redirect Redis's BGSAVE output into system directories such as `/etc/cron.d` or `/var/spool/cron`, writing attacker-controlled content as a cron job. The RedisRaider campaign used this technique to deploy XMRig cryptominers at scale by mass-scanning IPv4 blocks for unauthenticated Redis instances. + +A related variant (not specific to RedisRaider) targets SSH key injection using `CONFIG SET dir /root/.ssh` and `CONFIG SET dbfilename authorized_keys`. Consider a companion rule for that pattern if your Redis instances are internet-exposed. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Internet-sourced CONFIG SET to a cron path is almost certainly malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the primary target of RedisRaider-style campaigns. +- Review subsequent Redis commands from the same source IP for `SET` (cron payload write) and `BGSAVE` (flush to disk), which complete the persistence chain. +- Examine the Redis host for new or modified files under `/etc/cron.d`, `/etc/cron.daily`, `/etc/cron.hourly`, `/var/spool/cron`, or `/var/spool/cron/crontabs` at or after the alert time. +- Check for XMRig or other cryptominer process execution and unexplained CPU spikes on the host. +- Review outbound network connections from the Redis host for connections to known mining pools or C2 infrastructure. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command used during backup configuration, data migration, or operational changes. Verify whether the directory is a known backup or data path rather than a system directory. +- Legitimate Redis usage will never set `dir` to `/etc/cron.d`, `/var/spool/cron`, or any other system cron directory. A match on this pattern has an extremely low false positive rate. +- Automated deployment or configuration management tools (Ansible, Chef, Puppet) may issue CONFIG SET as part of Redis setup — verify the source IP and timing against known deployment windows. + + +*Response and remediation* + + +- Immediately check the target cron directories for newly created files written by the Redis process (owner: redis, unusual content). +- If a cron file was written, delete it and terminate any spawned miner processes before remediating. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis exposed to any network is the root cause of this attack class. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*CONFIG SET dir*" and + ( + network_traffic.redis.query like~ "*/etc/cron*" or + network_traffic.redis.query like~ "*/var/spool/cron*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-ssh-authorized-key-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-ssh-authorized-key-injection.asciidoc new file mode 100644 index 0000000000..d9f1202c01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-config-set-ssh-authorized-key-injection.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-26-potential-redis-config-set-ssh-authorized-key-injection]] +=== Potential Redis CONFIG SET SSH Authorized Key Injection + +This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redis.io/docs/latest/operate/oss_and_stack/management/security/ +* https://attack.mitre.org/techniques/T1098/004/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Redis CONFIG SET SSH Authorized Key Injection* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers targeting unauthenticated Redis instances exploit this to redirect BGSAVE output into `/root/.ssh/authorized_keys`, injecting their own SSH public key and establishing persistent root shell access without credentials. + +The full attack chain is: +1. `CONFIG SET dir /root/.ssh` — redirects the save path to the SSH directory +2. `CONFIG SET dbfilename authorized_keys` — sets the output filename +3. `SET key " + +ssh-rsa ATTACKER_KEY + +"` — writes the public key with surrounding newlines +4. `BGSAVE` — flushes the in-memory dataset (including the injected key) to disk + +A related variant targets cron persistence (`CONFIG SET dir /etc/cron.d`) for cryptominer deployment, as used by the RedisRaider campaign. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Any external IP issuing CONFIG SET to an SSH directory should be treated as malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the prerequisite for this attack. +- Review subsequent Redis commands from the same source IP for `SET` (key write) and `BGSAVE` (flush to disk), which complete the injection chain. +- Examine `/root/.ssh/authorized_keys` and other user SSH directories on the Redis host for unexpected or recently modified entries at or after the alert time. +- Check SSH login events on the Redis host for successful logins from unknown keys or source IPs shortly after the alert. +- Review outbound connections from the Redis host for lateral movement or C2 activity following a successful key injection. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command, but pointing it to any `/.ssh` directory has no legitimate use case. A match on this pattern has an extremely low false positive rate. +- `CONFIG SET dbfilename authorized_keys` has no legitimate operational use. Any match should be investigated immediately. +- Automated deployment tooling (Ansible, Chef, Puppet) will never target SSH directories via Redis CONFIG SET — this combination is exclusively malicious. + + +*Response and remediation* + + +- Immediately inspect `/root/.ssh/authorized_keys` and all user `~/.ssh/authorized_keys` files on the Redis host for unauthorized entries and remove them. +- Rotate SSH host keys and audit all active SSH sessions on the affected host. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis reachable from any network is the root cause. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + ( + ( + network_traffic.redis.query like~ "*CONFIG SET dir*" and + network_traffic.redis.query like~ "*/.ssh*" + ) or + ( + network_traffic.redis.query like~ "*CONFIG SET dbfilename*" and + network_traffic.redis.query like~ "*authorized_keys*" + ) + ) + +---------------------------------- + +*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: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc new file mode 100644 index 0000000000..ec864aa2b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-26-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell]] +=== Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell) + +This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2025-49844 +* https://redis.io/blog/redis-security-advisory-cve-2025-49844 +* https://www.cisa.gov/known-exploited-vulnerabilities-catalog +* https://www.wiz.io/blog/pwn2own-berlin-2025-redis-cve-2025-49844 + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*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 Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell)* + + +CVE-2025-49844 is a use-after-free in the Redis Lua interpreter. An authenticated attacker sends an EVAL command whose Lua script calls `string.rep()` to create memory pressure, then `collectgarbage('collect')` to force GC, triggering the use-after-free to achieve RCE. This rule matches on the `network_traffic.redis.query` field populated by the network_traffic (Packetbeat) Redis protocol module. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is a known trusted host or an internet address. Internet-exposed Redis (port 6379) with this pattern is almost certainly malicious. +- Confirm the destination Redis version. If unpatched (6.2.x branch: < 6.2.20; 7.2.x branch: < 7.2.11; 7.4.x branch: < 7.4.6; 8.0.x branch: < 8.0.4; 8.2.x branch: < 8.2.2), treat the alert as a high-confidence exploitation attempt. +- Review surrounding Redis commands (AUTH, CONFIG, SLAVEOF, DEBUG) from the same source IP for evidence of post-exploitation configuration tampering. +- Examine the destination host for evidence of reverse-shell establishment: outbound connections from the Redis process, new listening ports, or child process spawning (bash -i, nc, /dev/tcp patterns). +- Pivot to endpoint telemetry on the Redis host for process execution anomalies at or after the alert time. + + +*False positive analysis* + + +- `string.rep()` and `collectgarbage('collect')` are valid Lua functions individually. Their deliberate combination inside a Redis EVAL is almost exclusively associated with CVE-2025-49844 or explicit security testing. +- Authorized penetration testing and vulnerability scanning against the CVE will trigger this rule. Validate against known scanner IPs and scheduled assessment windows before escalating. + + +*Response and remediation* + + +- Immediately patch affected Redis instances: 6.2.x >= 6.2.20, 7.2.x >= 7.2.11, 7.4.x >= 7.4.6, 8.0.x >= 8.0.4, 8.2.x >= 8.2.2. +- Restrict Redis network access to trusted hosts only. Redis should never be directly reachable from the internet. +- Require authentication (`requirepass` or ACL) and rotate credentials if exploitation is suspected. +- If Lua scripting is not required, restrict EVAL via ACLs (`ACL SETUSER -eval`). +- If successful exploitation is suspected, isolate the host, collect artifacts, and rotate all credentials stored in or accessible via Redis. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. The rule matches on the `network_traffic.redis.query` field (keyword — human-readable command text) populated +for every Redis transaction; the raw wire bytes are available in `network_traffic.redis.request` (text) if +deeper inspection is needed. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation — this rule only covers unencrypted Redis* + + +Redis uses a plaintext protocol by default (port 6379, no TLS). Packetbeat can inspect the full request payload +on unencrypted connections, which is the configuration used by the vast majority of internet-exposed instances +(8,500+ vulnerable instances identified as of October 2025 were all unencrypted). + +If TLS is configured for Redis (`tls-port`, `tls-cert-file`, and `tls-key-file` in redis.conf), Packetbeat cannot +inspect the payload without TLS decryption. For TLS-protected Redis deployments, supplement this rule with +endpoint detection (process command-line arguments, system call monitoring) on the Redis host itself. + + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*EVAL*" and + network_traffic.redis.query like~ "*string.rep*" and + network_traffic.redis.query like~ "*collectgarbage*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-quick-assist-full-control-sharing-mode-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-quick-assist-full-control-sharing-mode-enabled.asciidoc new file mode 100644 index 0000000000..501bf4754a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-quick-assist-full-control-sharing-mode-enabled.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-26-quick-assist-full-control-sharing-mode-enabled]] +=== Quick Assist Full Control Sharing Mode Enabled + +Identifies when Microsoft Quick Assist sharing mode is set to FullControl on a Windows host. This grants the remote helper full interactive control of the target device and may indicate IT help desk fraud, unauthorized remote access, or lateral movement preparation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.application* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ +* https://attack.mitre.org/software/S1209/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Data Source: Windows Application Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Quick Assist Full Control Sharing Mode Enabled* + + +Microsoft Quick Assist is a built-in remote support tool. When a sharer grants FullControl, the helper can interact with +the desktop as if physically present. Adversaries abuse Quick Assist in help desk fraud and social engineering to gain +interactive access without deploying separate remote access software. + +Quick Assist logs these transitions in the Windows Application log under the Quick Assist provider. A `setsharingmode` +command with sharing mode `FullControl` is written to `winlog.event_data.param1`, often alongside a JSON payload that +includes `"result":"true"` when consent is granted. + + +*Possible investigation steps* + + +- Review `winlog.event_data.param1` and any related Quick Assist Application log events around `@timestamp` for + `beginsharing`, `setsharingmode`, and `endsharing` commands to reconstruct the session timeline. +- Identify the local user on `host.id` who initiated or approved the session and determine whether Quick Assist use is + expected for that user, host role, or business unit. +- Correlate with process telemetry for `QuickAssist.exe` on the same host and timeframe, including parent process, + command line, and code signature details when available. +- Check for related alerts on the same `host.id` or `user.id`, such as credential access, defense evasion, or + additional remote access activity during or shortly after the session. +- If the host is a server or privileged workstation, determine whether any follow-on actions occurred during the + FullControl window, such as new logons, service creation, or lateral movement. + + +*False positive analysis* + + +- IT help desk, managed service providers, and internal support teams legitimately use Quick Assist with FullControl + during approved troubleshooting. Confirm the session aligns with an open ticket, known support staff, and expected + host and user pairings before closing as benign. +- Before creating an exception, anchor it on the minimum confirmed workflow: `host.id`, `user.id`, and recurring + support patterns. Avoid broad exceptions on the Quick Assist provider alone. + + +*Response and remediation* + + +- If confirmed malicious, terminate the Quick Assist session, isolate the affected host when feasible, and reset + credentials for accounts used or exposed during the session. +- Preserve Application log events containing `winlog.event_data.param1` and related Quick Assist telemetry before + remediation. +- Review whether Quick Assist should remain enabled organization-wide or be restricted via policy for high-value hosts. +- Hunt for additional hosts where the same remote helper pattern or concurrent Quick Assist FullControl sessions + occurred. + +==== Setup + + + +*Setup* + + +Windows Application event log collection must be enabled via the Elastic Agent System integration to ingest Application log events. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and winlog.channel:"Application" and event.provider:"Quick Assist" and event.code:"0" and + winlog.event_data.param1:(*FullControl* and *setsharingmode*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rdp-remote-desktop-protocol-from-the-internet.asciidoc new file mode 100644 index 0000000000..89a3962c51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-26-rdp-remote-desktop-protocol-from-the-internet]] +=== RDP (Remote Desktop Protocol) from the Internet + +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. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* 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 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 query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:3389 or data_stream.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 + ) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-remote-ssh-login-enabled-via-systemsetup-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-remote-ssh-login-enabled-via-systemsetup-command.asciidoc new file mode 100644 index 0000000000..564a086c26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-remote-ssh-login-enabled-via-systemsetup-command.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-26-remote-ssh-login-enabled-via-systemsetup-command]] +=== Remote SSH Login Enabled via systemsetup Command + +Detects use of the systemsetup command to enable remote SSH Login. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://documents.trendmicro.com/assets/pdf/XCSSET_Technical_Brief.pdf +* https://ss64.com/osx/systemsetup.html +* https://support.apple.com/guide/remote-desktop/about-systemsetup-apd95406b8d/mac + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 112 + +*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 Remote SSH Login Enabled via systemsetup Command* + + +The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login, which facilitates remote management and access. Adversaries may exploit this to gain unauthorized access and move laterally within a network. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding legitimate administrative tools, by monitoring process execution patterns and arguments. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the systemsetup command with the arguments "-setremotelogin" and "on" to ensure the alert is not a false positive. +- Check the parent process of the systemsetup command to identify if it was executed by a known administrative tool or script, excluding /usr/local/jamf/bin/jamf as per the rule. +- Investigate the user account associated with the process execution to determine if it is a legitimate administrator or a potentially compromised account. +- Examine recent login events and SSH access logs on the host to identify any unauthorized access attempts or successful logins following the enabling of remote SSH login. +- Correlate this event with other security alerts or logs from the same host or network segment to identify potential lateral movement or further malicious activity. + + +*False positive analysis* + + +- Legitimate administrative tools like Jamf may trigger this rule when enabling SSH for authorized management purposes. To handle this, ensure that the process parent executable path for Jamf is correctly excluded in the detection rule. +- Automated scripts used for system configuration and maintenance might enable SSH as part of their routine operations. Review these scripts and, if verified as safe, add their parent process paths to the exclusion list. +- IT support activities that require temporary SSH access for troubleshooting can also cause false positives. Document these activities and consider scheduling them during known maintenance windows to reduce alerts. +- Security software or management tools that periodically check or modify system settings could inadvertently trigger this rule. Identify these tools and exclude their specific process paths if they are confirmed to be non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious or unauthorized SSH sessions that are currently active on the affected system. +- Review and revoke any unauthorized SSH keys or credentials that may have been added to the system. +- Conduct a thorough examination of the system logs to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system to a known good state from a backup taken before the unauthorized SSH access was enabled, if possible. +- Implement network segmentation to limit SSH access to only trusted administrative systems and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and +( + ( + process.name == "systemsetup" and + process.args like~ "-setremotelogin" and + process.args like~ "on" + ) or + ( + process.name == "launchctl" and + process.args in ("load", "bootstrap") and + ( + process.command_line like~ "*/System/Library/LaunchDaemons/ssh.plist*" or + process.command_line like~ "*com.openssh.sshd*" + ) + ) +) and +process.parent.executable != null and +not process.parent.executable like ("/usr/local/jamf/bin/jamf", "/usr/libexec/xpcproxy", "/usr/bin/sudo") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-from-the-internet.asciidoc new file mode 100644 index 0000000000..5d75032072 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-from-the-internet.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-26-rpc-remote-procedure-call-from-the-internet]] +=== RPC (Remote Procedure Call) from the Internet + +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. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Network Traffic +* Data Source: PAN-OS +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 112 + +*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 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 query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + not (event.type: denied or event.action: flow_dropped or event.outcome: failure) 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 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-to-the-internet.asciidoc new file mode 100644 index 0000000000..49597e1394 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-rpc-remote-procedure-call-to-the-internet.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-26-rpc-remote-procedure-call-to-the-internet]] +=== RPC (Remote Procedure Call) to the Internet + +This rule detects network events that may indicate the use of RPC traffic to 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. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Tactic: Lateral Movement +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* 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 RPC (Remote Procedure Call) to the Internet* + + +RPC enables remote management and resource sharing across networks, 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 from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network. +- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity. +- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic. +- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication. +- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic. +- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts. +- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening. +- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts. +- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC. +- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident. +- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation. +- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic. +- 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 logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) 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" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* 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/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-security-file-access-via-common-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-security-file-access-via-common-utilities.asciidoc new file mode 100644 index 0000000000..5572546016 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-security-file-access-via-common-utilities.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-26-security-file-access-via-common-utilities]] +=== Security File Access via Common Utilities + +This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*Version*: 108 + +*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 Security File Access via Common Utilities* + + +In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. +- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. +- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. +- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. +- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. +- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. +- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. +- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. +- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. +- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. +- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("cat", "less", "more", "strings", "find", "xargs") and +process.parent.executable != null and +process.args like ( + "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*", + "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*", + "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json", + "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json", + "/home/*/.azure/azureProfile.json" +) and not ( + process.parent.name in ("wazuh-modulesd", "lynis") or + process.command_line in ("cat /etc/login.defs" , "cat /home/asterisk/.aws/credentials") or + ?process.parent.command_line in ( + "/bin/sh /usr/sbin/lynis audit system --cronjob", + "/usr/bin/find -L /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;", + "/usr/bin/find /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;" + ) or + ?process.parent.args in ("/opt/imperva/ragent/bin/get_sys_resources.sh", "/usr/sbin/lynis", "./terra_linux.sh") or + process.args == "/usr/bin/coreutils" or + (process.parent.name == "pwsh" and process.parent.command_line like "*Evaluate-STIG*") or + ?process.parent.executable like ( + "/usr/sap/audit_scripts/auto_audit_gral.sh", "/opt/saltstack/salt/bin/python3*", "/opt/puppetlabs/puppet/bin/ruby" + ) or + ?process.entry_leader.executable like ( + "/usr/sbin/ScanAssistant", "/opt/Tanium/TaniumClient/TaniumClient", "/tmp/CVU_*resource/exectask", "/opt/nessus/sbin/nessus-service" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smb-windows-file-sharing-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smb-windows-file-sharing-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..9a85c456d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smb-windows-file-sharing-activity-to-the-internet.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-26-smb-windows-file-sharing-activity-to-the-internet]] +=== SMB (Windows File Sharing) Activity to the Internet + +This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted systems. 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 or for data exfiltration. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Tactic: Exfiltration +* Domain: Network +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 112 + +*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 SMB (Windows File Sharing) Activity to the Internet* + + +SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization. +- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access. +- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity. +- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes. +- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors. + + +*False positive analysis* + + +- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives. +- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted. +- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification. +- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs. +- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445. +- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation. +- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet. +- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(network_traffic.flow or zeek.smb_cmd or zeek.smb_files or zeek.smb_mapping) or event.category:(network or network_traffic)) + and network.transport:tcp and destination.port:(139 or 445) + 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 100.64.0.0/10 + 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.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smtp-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smtp-on-port-26-tcp.asciidoc new file mode 100644 index 0000000000..13d62bde8b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-smtp-on-port-26-tcp.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-26-smtp-on-port-26-tcp]] +=== SMTP on Port 26/TCP + +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. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/unit42-badpatch/ +* https://isc.sans.edu/forums/diary/Next+up+whats+up+with+TCP+port+26/25564/ + +*Tags*: + +* Tactic: Command and Control +* Tactic: Exfiltration +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 112 + +*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 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 query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26 + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Mail Protocols +** ID: T1071.003 +** Reference URL: https://attack.mitre.org/techniques/T1071/003/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..dda43b0953 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,317 @@ +[[prebuilt-rule-8-19-26-suspicious-child-execution-via-web-server]] +=== Suspicious Child Execution via Web Server + +Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/tag/web-shell/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Execution via Web Server* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a malicious script, often embedded into a compromised web server, that grants an attacker remote access and control over the server. This enables the execution of arbitrary commands, data exfiltration, and further exploitation of the target network. + +This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors by the subject process such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Investigate the process information for malicious or uncommon processes/process trees. + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} + - Investigate the process tree spawned from the user that is used to run the web application service. A user that is running a web application should not spawn other child processes. + - !{osquery{"label":"Osquery - Retrieve Process Info for Webapp User","query":"SELECT name, cmdline, parent, path, uid FROM processes WHERE uid = {{process.user.id}}"}} +- Examine the command line to determine which commands or scripts were executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", "*.bin", "*.jar", "*.mjs", + + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + + // Cloud CLI + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_19_resource_*/exectask*", "/u01/app/*/grid/bin/crsctl.bin", "/u01/app/*/grid/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/app/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.working_directory == "/var/lib/logrotate" and + process.name == "cat" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* 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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..12f0037381 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,402 @@ +[[prebuilt-rule-8-19-26-suspicious-command-execution-via-web-server]] +=== Suspicious Command Execution via Web Server + +Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*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 Suspicious Command Execution via Web Server* + + +This alert fires when a Linux web server launches a shell to run commands that look like exploitation activity, such as discovery, credential access, payload decoding, or reverse shell setup. That matters because web servers rarely need to spawn shell commands, so this behavior often signals command injection, a dropped web shell, or attacker persistence. A common pattern is an app exploit causing php-fpm or nginx to run `sh -c 'id; cat /etc/passwd; curl ... | bash'` from `/tmp`. + + +*Possible investigation steps* + + +- Review the full process ancestry and execution context to determine what application component invoked the shell, which service account ran it, what working directory and environment it used, and whether the command aligns with any documented application behavior. +- Correlate the execution time with web server access, error, and application logs to identify the triggering request, including source IP, requested URI, parameters, headers, authenticated user or session, and any indications of command injection or direct web shell access. +- Inspect recently created or modified files in the web root and writable locations such as upload, cache, temp, and shared-memory directories for dropped scripts, encoded payloads, cron changes, SSH key additions, or other persistence artifacts tied to the command. +- Scope for follow-on activity by pivoting on the source IP, command fragments, spawned children, outbound connections, and similar executions on other web servers to determine whether exploitation was successful, repeated, or part of a broader campaign. +- If the activity is unauthorized or cannot be explained, isolate the host, preserve relevant volatile and disk evidence, rotate secrets accessible to the web service, and remediate the vulnerable application or remove any discovered web shell before restoring service. + + +*False positive analysis* + + +- A legitimate web administration or diagnostics function may invoke `sh -c` to run commands such as `id`, `whoami`, `hostname`, or read OS metadata for status pages; verify the command matches documented application behavior and correlate it to an authorized request in web or application logs. +- A normal application workflow may use the web server to unpack user uploads or stage temporary content under `/tmp`, `/var/tmp`, or `/dev/shm` during import, conversion, or update operations; verify the execution aligns with a known user action or scheduled maintenance window and that the created files are expected temporary artifacts owned by the service account. + + +*Response and remediation* + + +- Isolate the affected web server from the network or remove it from the load balancer immediately, preserve a forensic snapshot if possible, and block the attacker-controlled IPs, domains, and downloaded payload locations observed in the command chain. +- Hunt for and remove persistence by deleting web shells and dropped scripts in the document root, uploads, `/tmp`, `/var/tmp`, and `/dev/shm`, and by cleaning unauthorized cron entries, systemd services, startup scripts, SSH `authorized_keys`, and any attacker-created local accounts. +- Reset trust on the host by rotating application secrets, database passwords, API tokens, cloud credentials, and SSH keys that were present or reachable from the web server, and invalidate active sessions tied to the compromised application. +- Rebuild or reimage the server from a known-good source, patch the exploited web application or server component, restore only validated content and configurations, and verify no unauthorized binaries, modified packages, or backdoored application files remain before returning it to service. +- Escalate to incident response immediately if the shell command opened a reverse shell, downloaded or piped a payload into an interpreter, accessed sensitive files such as `/etc/shadow`, `.ssh`, or cloud credential stores, or if similar activity is found on additional hosts. +- Harden the environment by removing unnecessary shell execution from the application, disabling write and execute permissions in web-accessible upload and temp paths, enforcing least privilege for the web service account, enabling WAF or virtual patching for the exploited weakness, and increasing monitoring on web roots and startup locations. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and +process.args in ("-c", "-cl", "-lc") and ( + process.command_line like~ ( + + /* Suspicious Paths */ + "* /tmp/* ", "* /var/tmp/* ", "* /dev/shm/*", "* /run/*", "* /var/run/*", + + /* Encoding, Decoding & Piping */ + "*|sh", "*| sh *", "*| sh ", "*|bash*", "*| bash*", "*|zsh*", "*| zsh*", "*|dash*", "*| dash*", + "*|python*", "*| python*", "*|php*", "*| php*", "*|perl*", "*| perl*", "*|ruby*", "*| ruby*", + "*|node*", "*| node*", "*|lua*", "*| lua*", "*|busybox*", "*| busybox*", "*|*base64 -d*", "*|*base64 --decode*", + "*|*base64 --decode*", "*|*openssl base64 -d*", "*xxd *", "*| openssl*enc * -d *", "*b64decode -r*", + + /* Interpreter Execution */ + "*python -c*", "*python3 -c*", "*php -r*", "*perl -e*", "*ruby -e*", "*lua -e*", "*node -e *", + + /* Reverse Shells */ + "*netcat *", "* nc *", "*ncat *", "*/dev/tcp*", "*/dev/udp/*", "*socat *", "*openssl*s_client *", "*stty*raw*-echo*", + "*mkfifo /tmp/*", + + /* File Access */ + "*>*/etc/cron*", "*crontab*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*/etc/shadow*", + "*/etc/passwd*", "*/etc/master.passwd*", + + /* Enumeration & Discovery */ + "*/etc/hosts*", "*/etc/resolv.conf*", "*/etc/hostname*", "*/etc/issue*", "*/etc/os-release*", "*lsb_release*", + "*/proc/*/environ*", "*sudo -l*", "*/proc/*/cgroup*", "*dockerenv*", "*/proc/*/mountinfo*", "*printenv*", + "*cat*.env *", "*getcap*", "*capsh*", "*find / *", "*netstat *", + + /* AWS Credentials */ + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*.aws/credentials*", "*/.aws/config*", + + /* Azure Credentials */ + "*AZURE_CLIENT_ID*", "*AZURE_TENANT_ID*", "*AZURE_CLIENT_SECRET*", "*AZURE_FEDERATED_TOKEN_FILE*", + "*IDENTITY_ENDPOINT*", "*IDENTITY_HEADER*", "*MSI_ENDPOINT*", "*MSI_SECRET*", "*/.azure/*", + "*/run/secrets/azure/*", + + /* GCP Credentials */ + "*/.config/gcloud/*", "*application_default_credentials.json*", "*type: service_account*", + "*client_email*", "*private_key_id*", "*/run/secrets/google/*", "*GOOGLE_APPLICATION_CREDENTIALS*", + + /* Misc. Cloud */ + "*/.docker/config.json*", "*/.npmrc*", "*/secrets/kubernetes.io/serviceaccount/*", + + /* Helpers */ + "*timeout *sh -c *", "*env *sh *-c*", "*exec -a*", + + /* Miscellaneous */ + "*chattr *", "*busybox *", "*#!*", "*chmod +x *", "*chmod 777*", "*chpasswd*", + "**", "*kworker*", + + /* Decompression */ + "*gzip -*d *", "*bzip2 -*d *", "*xz -*d *", "*tar -*x*", + + /* Path Traversal */ + "*../../../*etc/*", "*/.../*", "*../../../*home/*/*", "*../../../*root/*", + + /* File Upload/Download */ + "*pastebin.com*", "*transfer.sh*", "*bashupload.com*", + + /* Enumeration & Discovery */ + "* id *", "* whoami *", "* hostname *" + ) or + /* Keep this to not miss FNs due to spacing */ + process.args in ("id", "whoami", "hostname") +) and +not ( + ( + process.parent.name == "nginx" and + process.args like ("chmod 777 /etc/resty-*", "resty*") + ) or + ( + process.parent.name == "apache2" and ( + process.command_line in ( + "sh -c /usr/local/bin/php -r 'echo phpversion();'", "sh -c -- /usr/local/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/lsb_release -a 2>/dev/null" + ) or + process.args like ( + """bash -c "( /home/*/apps/richdocumentscode/collabora/Collabora_Online.AppImage*""", + "chmod 777 /etc/cobra/uploads/mysql*", "stat*" + ) or + process.command_line like ( + "*/usr/bin/crontab*phpupdatecrontab.txt", "*mysqldump*/var/www/html/*/writable/uploads/backup/mysql*", + "sh -c chmod 777 -R /opt/data/www/php_upload/*/temp" + ) + ) + ) or + ( + process.parent.name like "php-fpm*" and ( + process.command_line in ( + "sh -c /usr/bin/php -r 'echo phpversion();'", "sh -c -- /usr/bin/php -r 'echo phpversion();'", + "sh -c php -r 'print_r(phpversion());'", "sh -c chattr -i -a /usr/local/virtualizor/license2.php", + "sh -c source /etc/os-release 2>/dev/null && echo $ID $ID_LIKE", + "sh -c php -r \"echo date('T');\"", + "sh -c php -r \"echo PHP_VERSION;\"" + ) or + process.command_line like ( + "*var_export*extension_loaded*", "*/tmp/tmp_resize*", "*/v1/objects/hosts/*_Infoterminal*", "*python -m json.tool*", + "sh -c timeout 3600 ssh -o ControlMaster=auto -o ControlPath=/var/www/html/storage/app/ssh/mux/*" + ) or + process.args like ("ps*|*grep*", "ffmpeg*") + ) + ) or + ( + process.parent.name == "php-cgi" and ( + process.command_line like ( + "sh -c nohup php /home/*/public_html/lockindex.php index.php >/dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-content/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-includes/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/*/wp-content/* >> /dev/null 2>&1 &", + "*-ef|grep*" + ) or + process.args like "ps*| grep*" + ) + ) or + ( + process.command_line == "/bin/sh -c echo | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" and + process.parent.name == "gunicorn" + ) or + ( + process.parent.executable == "/usr/local/bin/gunicorn" and + process.command_line == "/bin/sh -c echo 'Q' | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" + ) or + ( + process.parent.executable == "/opt/bitnami/apache/bin/httpd" and + process.command_line == "sh -c /opt/bitnami/php/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/containers/storage/overlay/*/merged/usr/local/sbin/php-fpm" and + process.command_line == "sh -c /usr/local/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/sbin/uwsgi" and + process.command_line == "/bin/sh -c { touch /run/uwsgi-logrotate }" + ) or + (process.parent.name like "python*" and process.parent.command_line like "*hive_server.py*") or + (process.parent.name == "sw-engine-fpm" and process.command_line like ("*/opt/psa/admin/bin/*", "*/usr/local/psa/admin/*")) or + (process.parent.name == "httpd" and process.command_line like ("*/datastore/htdocs/control-states/compass*", "*/dev/shm/netmon-log*")) or + (process.parent.name == "asterisk" and process.args like "/bin/chmod 777 */gravacoes/*.WAV") or + (process.parent.name == "nginx" and process.command_line like "sh -c gcc -print-multiarch 2>/dev/null > /tmp/lua_*") or + (process.parent.name == "varnishd" and process.args like "exec gcc*") or + (process.parent.name == "zabbix_server" and process.command_line like "*/usr/sbin/sendmail*") or + (process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and process.command_line like "*morpheus-local*") or + ( + process.parent.name == "ruby" and + process.command_line in ( + "sh -c echo \"^d\" | openssl s_client -connect 127.0.0.1:443 2>&1", + "sh -c cat /etc/hosts.allow 2>/dev/null" + ) + ) or + (process.parent.name == "java" and process.args like "chmod 777 *.csv") or + process.command_line == "sh -c node -v || nodejs -v" or + process.working_directory like ("/var/lib/puppet/rack/puppetmasterd", "/u01/app/*/sysman/emd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* 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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..648ccfff17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-26-suspicious-kernel-feature-activity]] +=== Suspicious Kernel Feature Activity + +This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 6 + +*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 Suspicious Kernel Feature Activity* + + +Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent. + + +*Possible investigation steps* + + +- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope. +- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes. +- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user. +- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings. +- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise. +- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions. +- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns. +- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines. +- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule. +- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files. +- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated. +- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network. +- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.command_line : ( + "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", + "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", + "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*", + "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*", + "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*", + "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", + "*kernel.sysrq*" +) and +?process.parent.executable != null and +( + (process.name == "tee" and process.args like "-*a*") or // also detects --append + (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *") +) and +not ( + process.parent.executable in ( + "/opt/novell/groupwise/agents/bin/gwia", "/opt/novell/groupwise/agents/bin/gwmta", "/opt/novell/groupwise/agents/bin/gwpoa", + "/opt/illumio_ven/system/etc/init.d/illumio-firewall", "/usr/bin/oracle-database-preinstall-19c-verify", "/usr/bin/make", + "/usr/local/qualys/cloud-agent/bin/qualys-scan-util" + ) or + process.parent.executable like "/tmp/CVU_19_resource*/checkmemlock.sh" or + process.parent.args == "/usr/share/mysql/mysql-systemd-start" or + process.parent.command_line like "*ansible*" or + (process.parent.name in ("crond", "cron") and process.command_line like "*drop_caches*") or + (process.parent.name == "python.original" and process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..a7d3eed716 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-child-execution-via-web-server.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-26-unusual-child-execution-via-web-server]] +=== Unusual Child Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*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 Unusual Child Execution via Web Server* + + +This alert flags a Linux web service starting a child program it does not normally launch, which can reveal a compromised application server being used for persistence or follow-on actions. A common pattern is an attacker exploiting a web app bug, then making nginx, Apache, or a Python app server spawn a shell or script interpreter that downloads tools, runs system commands, or installs a backdoor under the web service context. + + +*Possible investigation steps* + + +- Review the full parent-to-descendant execution chain to determine whether the web service launched a shell, interpreter, downloader, or archive utility that then executed additional payloads. +- Correlate the process start time with web access, error, reverse-proxy, and WAF logs to identify the triggering request, source IP, requested path, upload activity, and signs of exploitation such as command injection or remote file inclusion. +- Determine whether the spawned program is part of a legitimate deployment or maintenance task by validating its file path, package ownership, hash, modification time, deployment records, and recent change windows. +- Examine activity under the web service account around the alert for suspicious file writes, new scheduled tasks or service entries, privilege escalation attempts, credential access, and unusual outbound network connections. +- If the execution is not explained by approved application behavior, contain the affected host or web service, preserve forensic artifacts, remove unauthorized files or persistence mechanisms, rotate exposed secrets, and hunt for the same behavior across other internet-facing servers. + + +*False positive analysis* + + +- A newly deployed or updated web application may legitimately cause the web server or app server to launch a previously unseen helper binary for application functionality, so verify the child executable path, package ownership, and command line against recent approved deployment or configuration changes. +- A CGI, FastCGI, or application framework process may spawn a custom maintenance or content-processing program only for specific requests, so confirm the parent-child relationship by correlating the execution time and arguments with the triggering web request and expected application behavior. + + +*Response and remediation* + + +- Immediately isolate the affected Linux web host or remove it from the load balancer, stop the compromised web service if business impact allows, and block the source IPs and outbound destinations associated with the malicious child process and any follow-on downloads. +- Preserve forensic evidence and remove persistence by collecting the suspicious executable or script, web-accessible backdoors, recent uploads, cron jobs, systemd service files, rc.local changes, modified SSH authorized_keys entries, and any attacker-created accounts before deleting them. +- Terminate all attacker-controlled processes spawned by the web service, then delete dropped payloads and staging files from locations such as /tmp, /var/tmp, /dev/shm, and the web root, and revert any unauthorized permission, sudoers, or startup changes used to maintain execution. +- Restore the application and host to a known-good state by rebuilding from a trusted image or clean backup, redeploying verified packages and web content, rotating credentials and tokens exposed on the server, and confirming no unauthorized binaries or modified files remain. +- Escalate to incident response immediately if the web child process launched a shell or interpreter, established outbound command-and-control traffic, modified authentication material, moved laterally, or if sensitive data, production secrets, or customer-facing systems may have been exposed. +- Harden the environment by patching the exploited web component, disabling unnecessary script execution from upload and web content directories, enforcing least privilege for the web service account, restricting outbound network access, and expanding monitoring for similar child-process launches and persistence artifacts across peer web servers. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.executable:* and process.command_line:* and +not ( + process.name:( + arp or aws or az or base16 or base32 or base64 or base64mime or base64pem or base64plain or base64url or + basenc or basez or bash or busybox or cat or chmod or chpasswd or cp or crictl or csh or ctr or curl or dash or + df or dig or docker or du or fish or gcloud or helm or host or htop or ifconfig or ip or ksh or kubectl or ln or + lsblk or lsof or ltrace or mkdir or mksh or mv or nc or nc.openbsd or nc.traditional or ncat or netcat or ngrok or + nmap or nslookup or openssl or passwd or rm or sh or socat or ss or strace or sudo or tcpdump or tcsh or telnet or + top or touch or traceroute or wget or whoami or xxd or zsh or *.bin or *.elf or *.jar or *.lua* or *.mjs or + *.js or *.php* or *.pl or *.py or *.rb or *.sh or .* + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /home/*/* or /lost+found/* or /proc/* or /root/* or /run/* or /sys/* or /tmp/* or + /var/mail/* or /var/run/* or /var/tmp/* or /var/www/* or "/usr/bin/ffprobe" or "/usr/bin/ffmpeg" + ) or + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..a20bfcd527 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-unusual-command-execution-via-web-server.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-26-unusual-command-execution-via-web-server]] +=== Unusual Command Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 5 + +*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 Unusual Command Execution via Web Server* + + +This rule detects shells invoked by web server processes on Linux to run one-off commands, surfacing command lines the server has never executed before. Attackers exploit vulnerable apps or dropped webshells to launch bash -c from web roots, e.g., download a payload with wget/curl into /opt or /tmp, chmod +x and execute it, or open a reverse shell (nc -e sh) to implant services or cron-like tasks and persist under the web server account. + + +*Possible investigation steps* + + +- Reconstruct the process tree around the event to identify the shell payload and parent service, determine if it chains downloads, reverse shells, or archive extraction, and hash/snapshot any referenced files. +- Pivot to web server access and error logs at the timestamp to identify the request path, client IP, user agent, and HTTP verb that triggered execution, noting anomalies like POST uploads, long query strings, or 500s. +- List and diff newly created or recently modified files under common web roots and application directories around the event time, looking for webshells, chmod+x artifacts, .php/.jsp backdoors, or systemd/cron writes by the same user. +- Correlate with network telemetry to see if the web tier opened outbound connections or listeners (nc, bash -i, curl/wget), and capture any active sockets and destinations for rapid containment. +- Validate whether the command matches expected maintenance tasks for the application (e.g., wkhtmltopdf or image processing), and if not, isolate the process and host while scoping for the same pattern across other servers and preserving volatile evidence. + + +*False positive analysis* + + +- A legitimate web-admin workflow (plugin/module install, content import, or cache warmup) spawns sh -c from an apache/nginx parent in /var/www to run tar/chmod/chown steps, producing a command line the host has not previously executed under www-data. +- A recently deployed application feature performs server-side document or image processing and rotates logs by calling sh -c from a framework parent (flask/rails/php) with a working directory in /opt or /usr/share/nginx, making the specific shell invocation a new term for this server. + + +*Response and remediation* + + +- Quarantine the affected web server by removing it from the load balancer, stopping apache/nginx/httpd, and killing the spawned shell (e.g., bash -c) while capturing /proc//cmdline and /proc//environ, lsof, and active sockets for evidence. +- Block outbound egress from the web server account and immediately deny destinations contacted by curl/wget or reverse shells (nc, bash -i to /dev/tcp), and rotate exposed API keys or credentials referenced in the command line. +- Eradicate persistence by deleting newly dropped or modified files under /var/www, /usr/share/nginx, /srv/http, /opt, or /home/*/public_html (webshells, .php backdoors), removing downloaded binaries from /tmp or /opt, and cleaning cron/systemd units created by www-data/nginx. +- Recover by restoring web content and application code from known-good backups or images, verifying file ownership and permissions, and restarting the service with monitored command allowlists and file integrity checks. +- Escalate to full incident response and forensic imaging if any reverse shell artifacts (nc -e sh, bash -i >& /dev/tcp/*), privileged writes (/etc/systemd/system/*.service, /var/spool/cron/*), or sudo execution by the web server user are observed. +- Harden by disabling risky exec paths (PHP exec/system/shell_exec and unsafe plugins), enforcing noexec,nodev,nosuid mounts on web roots, applying SELinux/AppArmor confinement to web processes, narrowing outbound egress, and deploying WAF/mod_security rules for upload and RCE vectors. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.command_line:* and +process.name:(bash or busybox or csh or dash or fish or ksh or mksh or sh or tcsh or zsh) and +process.args:(-c or -cl or -lc) and +not ( + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* or + (process.parent.name:nginx and process.name:busybox and process.args:gcc*/tmp/lua_*) or + (process.parent.name:apache2 and process.args:\"/usr/bin/7za*) or + (process.parent.name:zabbix_server and process.command_line:*fping*) or + (process.parent.name:php-fpm* and (process.command_line:*/usr/bin/pdftotext* or process.args:clamdscan*)) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-from-the-internet.asciidoc new file mode 100644 index 0000000000..10489cb162 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-from-the-internet.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-26-vnc-virtual-network-computing-from-the-internet]] +=== VNC (Virtual Network Computing) from the Internet + +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. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: pfSense +* Resources: Investigation Guide + +*Version*: 112 + +*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 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 query + + +[source, js] +---------------------------------- +(data_stream.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 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-to-the-internet.asciidoc new file mode 100644 index 0000000000..d1051ece1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rule-8-19-26-vnc-virtual-network-computing-to-the-internet.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-26-vnc-virtual-network-computing-to-the-internet]] +=== VNC (Virtual Network Computing) to the Internet + +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. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Lateral Movement +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: pfSense +* Resources: Investigation Guide + +*Version*: 112 + +*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 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 query + + +[source, js] +---------------------------------- +(data_stream.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" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* 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/ +* Sub-technique: +** Name: VNC +** ID: T1021.005 +** Reference URL: https://attack.mitre.org/techniques/T1021/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-appendix.asciidoc new file mode 100644 index 0000000000..6f0239e33d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-appendix.asciidoc @@ -0,0 +1,94 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-26-prebuilt-rules-8-19-26-appendix"] += Downloadable rule update v8.19.26 + +This section lists all updates associated with version 8.19.26 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-26-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-guardrail-deleted-or-weakened.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc[] +include::prebuilt-rule-8-19-26-aws-lambda-layer-shared-externally.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-provisioned-model-throughput-tampering.asciidoc[] +include::prebuilt-rule-8-19-26-aws-lambda-function-deletion.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-agent-or-action-group-manipulation.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc[] +include::prebuilt-rule-8-19-26-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc[] +include::prebuilt-rule-8-19-26-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc[] +include::prebuilt-rule-8-19-26-aws-lambda-event-source-mapping-creation.asciidoc[] +include::prebuilt-rule-8-19-26-aws-lambda-function-url-created-with-public-access.asciidoc[] +include::prebuilt-rule-8-19-26-azure-vm-boot-diagnostics-retrieved.asciidoc[] +include::prebuilt-rule-8-19-26-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc[] +include::prebuilt-rule-8-19-26-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc[] +include::prebuilt-rule-8-19-26-azure-ad-graph-potential-enumeration-roadrecon.asciidoc[] +include::prebuilt-rule-8-19-26-azure-ad-graph-access-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-26-azure-ad-graph-access-with-unusual-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-26-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-26-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-26-entra-id-temporary-access-pass-created-for-user.asciidoc[] +include::prebuilt-rule-8-19-26-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-26-entra-id-guest-account-promoted-to-member.asciidoc[] +include::prebuilt-rule-8-19-26-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc[] +include::prebuilt-rule-8-19-26-entra-id-oauth-application-redirect-uri-modified.asciidoc[] +include::prebuilt-rule-8-19-26-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-26-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc[] +include::prebuilt-rule-8-19-26-m365-teams-rogue-help-desk-chat-created.asciidoc[] +include::prebuilt-rule-8-19-26-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc[] +include::prebuilt-rule-8-19-26-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc[] +include::prebuilt-rule-8-19-26-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc[] +include::prebuilt-rule-8-19-26-potential-redis-config-set-ssh-authorized-key-injection.asciidoc[] +include::prebuilt-rule-8-19-26-quick-assist-full-control-sharing-mode-enabled.asciidoc[] +include::prebuilt-rule-8-19-26-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc[] +include::prebuilt-rule-8-19-26-potential-masquerading-as-system32-dll.asciidoc[] +include::prebuilt-rule-8-19-26-java-dropped-and-executed-with-dns-lookup.asciidoc[] +include::prebuilt-rule-8-19-26-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-26-azure-compute-vm-command-executed.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[] +include::prebuilt-rule-8-19-26-application-removed-from-blocklist-in-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-26-domain-added-to-google-workspace-trusted-domains.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-bitlocker-setting-disabled.asciidoc[] +include::prebuilt-rule-8-19-26-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-admin-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc[] +include::prebuilt-rule-8-19-26-application-added-to-google-workspace-domain.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-2sv-policy-disabled-by-user.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-custom-admin-role-created.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-password-policy-modified.asciidoc[] +include::prebuilt-rule-8-19-26-google-workspace-role-modified.asciidoc[] +include::prebuilt-rule-8-19-26-deprecated-mfa-disabled-for-google-workspace-organization.asciidoc[] +include::prebuilt-rule-8-19-26-potential-openssh-backdoor-logging-activity.asciidoc[] +include::prebuilt-rule-8-19-26-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-26-pluggable-authentication-module-pam-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-26-polkit-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-26-security-file-access-via-common-utilities.asciidoc[] +include::prebuilt-rule-8-19-26-deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc[] +include::prebuilt-rule-8-19-26-kernel-module-load-via-built-in-utility.asciidoc[] +include::prebuilt-rule-8-19-26-linux-user-added-to-privileged-group.asciidoc[] +include::prebuilt-rule-8-19-26-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-26-suspicious-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-26-unusual-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-26-unusual-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-26-remote-ssh-login-enabled-via-systemsetup-command.asciidoc[] +include::prebuilt-rule-8-19-26-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-26-ipsec-nat-traversal-port-activity.asciidoc[] +include::prebuilt-rule-8-19-26-smtp-on-port-26-tcp.asciidoc[] +include::prebuilt-rule-8-19-26-rdp-remote-desktop-protocol-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-vnc-virtual-network-computing-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-vnc-virtual-network-computing-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc[] +include::prebuilt-rule-8-19-26-rpc-remote-procedure-call-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-rpc-remote-procedure-call-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-smb-windows-file-sharing-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-26-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-26-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc new file mode 100644 index 0000000000..b4b7e4bb10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-26-prebuilt-rules-8-19-26-summary]] +[role="xpack"] +== Update v8.19.26 + +This section lists all updates associated with version 8.19.26 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. | new | 1 + +|<> | Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. | new | 1 + +|<> | Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. | new | 1 + +|<> | Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. | new | 1 + +|<> | Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. | new | 1 + +|<> | Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. | new | 2 + +|<> | Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. | new | 1 + +|<> | Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. | new | 1 + +|<> | Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. | new | 1 + +|<> | Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. | new | 1 + +|<> | Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. | new | 1 + +|<> | Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. | new | 1 + +|<> | Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. | new | 1 + +|<> | Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. | new | 1 + +|<> | Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. | new | 1 + +|<> | Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. | new | 1 + +|<> | Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. | new | 1 + +|<> | Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. | new | 1 + +|<> | Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. | new | 1 + +|<> | Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. | new | 1 + +|<> | Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. | new | 1 + +|<> | Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. | new | 1 + +|<> | Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. | new | 1 + +|<> | Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. | new | 1 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. | new | 2 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. | new | 1 + +|<> | Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. | new | 1 + +|<> | Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. | new | 1 + +|<> | Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. | new | 1 + +|<> | Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). | new | 1 + +|<> | Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. | new | 1 + +|<> | Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. | new | 1 + +|<> | Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. | new | 1 + +|<> | Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. | new | 1 + +|<> | Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. | new | 1 + +|<> | Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. | new | 1 + +|<> | Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. | new | 1 + +|<> | This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. | new | 1 + +|<> | This rule detects attempts to abuse Redis CONFIG SET commands to redirect the database save directory to a cron directory on Linux hosts. Attackers issue CONFIG SET dir to a cron path such as /etc/cron.d or /var/spool/cron, set a filename via CONFIG SET dbfilename, write a cron payload via SET, and then call BGSAVE to flush it to disk, establishing persistence for execution of an XMRig cryptominer. | new | 1 + +|<> | This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root. | new | 1 + +|<> | Identifies when Microsoft Quick Assist sharing mode is set to FullControl on a Windows host. This grants the remote helper full interactive control of the target device and may indicate IT help desk fraud, unauthorized remote access, or lateral movement preparation. | new | 1 + +|<> | Identifies PowerShell script block content associated with an Antimalware Scan Interface (AMSI) bypass that hooks the RPC runtime marshaling stub NdrClientCall3 (or NdrClientCall2) in rpcrt4.dll. Unlike bypasses that patch AmsiScanBuffer or set amsiInitFailed, this technique operates at the RPC layer used by AMSI to delegate scan requests to the antivirus provider, tampering with the request before it reaches the engine and leaving AMSI itself unmodified. The loader allocates an executable trampoline and marshals a delegate to the native stub; these primitives appear in PowerShell Script Block Logging before the hook takes effect. | new | 1 + +|<> | Identifies suspicious instances of default system32 DLLs either unsigned or signed with non-MS certificates. This can potentially indicate the attempt to masquerade as system DLLs, perform DLL Search Order Hijacking or backdoor and resign legitimate DLLs. | new | 111 + +|<> | Identifies a recently dropped or modified javaw.exe process started from a user-writable path to run a JAR or Java classpath application, followed by a DNS lookup. Adversaries may drop Java payloads into user directories and execute them immediately to establish command and control while evading application control focused on native Windows binaries. | new | 1 + +|<> | Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. | update | 8 + +|<> | Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. | update | 109 + +|<> | Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. | update | 111 + +|<> | Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. | update | 10 + +|<> | Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. | update | 112 + +|<> | Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. | update | 211 + +|<> | Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. | update | 112 + +|<> | Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. | update | 12 + +|<> | Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. | update | 113 + +|<> | Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. | update | 211 + +|<> | Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. | update | 213 + +|<> | 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. | update | 211 + +|<> | Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. | update | 112 + +|<> | Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. | update | 212 + +|<> | Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. | update | 212 + +|<> | Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. | update | 211 + +|<> | Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. | update | 211 + +|<> | Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. | update | 211 + +|<> | Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. | update | 211 + +|<> | Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. | update | 216 + +|<> | This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. | update | 6 + +|<> | This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. | update | 108 + +|<> | This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. | update | 8 + +|<> | This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. | update | 108 + +|<> | Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. | update | 120 + +|<> | Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. | update | 217 + +|<> | Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. | update | 115 + +|<> | Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. | update | 115 + +|<> | Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. | update | 2 + +|<> | This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. | update | 2 + +|<> | This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. | update | 5 + +|<> | Detects use of the systemsetup command to enable remote SSH Login. | update | 112 + +|<> | 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. | update | 115 + +|<> | 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. | update | 111 + +|<> | 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. | update | 112 + +|<> | 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. | update | 111 + +|<> | 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. | update | 112 + +|<> | 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. | update | 112 + +|<> | Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. | update | 2 + +|<> | 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. | update | 112 + +|<> | This rule detects network events that may indicate the use of RPC traffic to 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. | update | 111 + +|<> | This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted systems. 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 or for data exfiltration. | update | 112 + +|<> | Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. | update | 112 + +|<> | Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable and use WSL to avoid detection. | update | 115 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 3afc9eaea0..ca4d2308c3 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 25 Jun 2026 | 44 | 44 | +This release includes new rules for AWS, Windows, Azure, Microsoft 365, Azure AD Graph, Network Packet Capture, and Network Traffic. New rules for AWS include detection for persistence, defense evasion, impact, discovery, and execution. New rules for Windows include detection for command and control, defense evasion, and execution. New rules for Azure include detection for lateral movement, execution, and credential access. New rules for Microsoft 365 include detection for initial access, persistence, and credential access. New rules for Azure AD Graph include detection for discovery. New rules for Network Packet Capture include detection for persistence and initial access. New rules for Network Traffic include detection for credential access. Additionally, significant tuning for Linux, Windows, macOS, Azure, Google Workspace, and network rules improves efficacy and performance. + + |<> | 02 Jun 2026 | 18 | 29 | 8.19 Docs and News Feed This release includes new rules for Linux, AWS, Azure, Microsoft 365, Google Workspace, Network Packet Capture, and Elastic Defend. New rules for Linux include detection for credential access, discovery, and persistence. New rules for AWS include detection for credential access. New rules for Azure include detection for execution. New rules for Microsoft 365 include detection for defense evasion, initial access, and collection. New rules for Google Workspace include detection for initial access and persistence. New rules for Network Packet Capture include detection for credential access. New rules for Elastic Defend include detection for command and control and credential access. Additionally, significant tuning for Linux, Windows, macOS, Kubernetes, AWS, Microsoft 365, Google Workspace, and network rules improves efficacy and performance. @@ -138,3 +142,4 @@ include::downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc[l include::downloadable-packages/8-19-23/prebuilt-rules-8-19-23-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index 896c8cfc3e..9e9eff057e 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -24,16 +24,46 @@ and their rule type is `machine_learning`. |<> |Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 +|<> |Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + +|<> |Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1 + |<> |Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034] |None |8 |<> |Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. |[Domain: LLM], [Data Source: AWS], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0015], [Mitre Atlas: T0034], [Mitre Atlas: T0046], [Resources: Investigation Guide] |None |8 +|<> |Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. |[Domain: Cloud], [Domain: LLM], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS CloudTrail], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Discovery], [Tactic: Initial Access] |None |1 + +|<> |Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1 + |<> |Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |8 |<> |Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |9 +|<> |Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Exfiltration], [Mitre Atlas: T0024], [Mitre Atlas: T0024.000], [Resources: Investigation Guide] |None |2 + |<> |Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |6 +|<> |Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Impact] |None |1 + +|<> |Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Log Auditing], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |1 + +|<> |Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Impact] |None |1 + +|<> |Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + +|<> |Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. |[Domain: Cloud], [Domain: LLM], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + +|<> |Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + +|<> |Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 + |<> |Detects the use of the AWS CLI with the "--endpoint-url" argument, which allows users to specify a custom endpoint URL for AWS services. This can be leveraged by adversaries to redirect API requests to non-standard or malicious endpoints, potentially bypassing typical security controls and logging mechanisms. This behavior may indicate an attempt to interact with unauthorized or compromised infrastructure, exfiltrate data, or perform other malicious activities under the guise of legitimate AWS operations. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |7 |<> |Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS CloudShell], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |3 @@ -186,14 +216,30 @@ and their rule type is `machine_learning`. |<> |Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |113 +|<> |Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Identifies successful PutKeyPolicy calls on AWS KMS keys. The key policy is a resource-based policy that controls which principals can use the key for cryptographic operations and administration. Adversaries with "kms:PutKeyPolicy" may add or broaden principals (including external accounts) to decrypt or exfiltrate data protected by the key, or to preserve access after other credentials are rotated. This is distinct from disabling or scheduling deletion of the key. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Identifies when an AWS Lambda function is created or updated. AWS Lambda lets you run code without provisioning or managing servers. Adversaries can create or update Lambda functions to execute malicious code, exfiltrate data, or escalate privileges. This is a [building block rule](https://www.elastic.co/guide/en/security/current/building-block-rule.html) that does not generate alerts, but signals when a Lambda function is created or updated that matches the rule's conditions. To generate alerts, create a rule that uses this signal as a building block. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Asset Visibility], [Tactic: Execution], [Rule Type: BBR] |None |4 +|<> |Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + +|<> |Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 +|<> |Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |9 +|<> |Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Discovery], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 |<> |Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |214 @@ -312,9 +358,9 @@ and their rule type is `machine_learning`. |<> |Identifies the creation of a Process ID (PID), lock or reboot file created in temporary file storage paradigm (tmpfs) directory /var/run. On Linux, the PID files typically hold the process ID to track previous copies running and manage other tasks. Certain Linux malware use the /var/run directory for holding data, executables and other tasks, disguising itself or these files as legitimate PID files. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Threat: BPFDoor], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame] |None |219 -|<> |Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. |[Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Impact], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: PAN-OS], [Data Source: Network Traffic] |None |111 +|<> |Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. |[Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Impact], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: Zeek] |None |112 -|<> |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. |[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] |None |114 +|<> |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. |[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] |None |115 |<> |This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107 @@ -380,9 +426,9 @@ and their rule type is `machine_learning`. |<> |Identifies execution of the Apple script interpreter (osascript) without a password prompt and with administrator privileges. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213 -|<> |Detects when a Google marketplace application is added to the Google Workspace domain. An adversary may add a malicious application to an organization’s Google Workspace domain in order to maintain a presence in their target’s organization and steal data. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |210 +|<> |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. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 -|<> |Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |111 +|<> |Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |112 |<> |Identifies the creation of an archive file with an unusual extension. Attackers may attempt to evade detection by masquerading files using the file extension values used by image, audio, or document file types. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Rule Type: BBR] |None |4 @@ -454,6 +500,14 @@ and their rule type is `machine_learning`. |<> |Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature to persist and/or collect clear text credentials as they traverse the registered plugins during user logon. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 +|<> |Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2 + +|<> |Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Arc], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 |<> |Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107 @@ -476,7 +530,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |2 -|<> |Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles may be able to execute commands on a VM as well. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Execution], [Resources: Investigation Guide] |None |108 +|<> |Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |109 |<> |Identifies the creation of suppression rules in Azure. Suppression rules are a mechanism used to suppress alerts previously identified as false positives or too noisy to be in production. This mechanism can be abused or mistakenly configured, resulting in defense evasions and loss of security visibility. |[Domain: Cloud], [Data Source: Azure], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 @@ -524,8 +578,16 @@ and their rule type is `machine_learning`. |<> |Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Storage], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |3 +|<> |Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Identifies the successful deployment of a high-risk Azure Virtual Machine extension by an interactive user principal. Attackers with privileged Azure RBAC roles can abuse VM extensions such as VMAccess, CustomScriptExtension, and RunCommand to execute arbitrary code, create backdoor accounts, harvest credentials, and establish persistence on Azure-hosted virtual machines without requiring direct network access to the VM. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their objective. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |108 |<> |Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade defenses and/or to eliminate barriers to their objective. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |108 @@ -702,6 +764,8 @@ and their rule type is `machine_learning`. |<> |Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |419 +|<> |Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |120 + |<> |Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |214 |<> |Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Resources: Investigation Guide] |None |213 @@ -716,6 +780,8 @@ and their rule type is `machine_learning`. |<> |Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |214 +|<> |Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 + |<> |Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |110 |<> |Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |110 @@ -762,7 +828,7 @@ and their rule type is `machine_learning`. |<> |This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers. Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or move laterally within the environment. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4 -|<> |Detects when a domain is added to the list of trusted Google Workspace domains. An adversary may add a trusted domain in order to collect and exfiltrate data from their target’s organization with less restrictive security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210 +|<> |Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211 |<> |Identifies .lnk shortcut file downloaded from outside the local network. These shortcut files are commonly used in phishing campaigns. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 @@ -842,6 +908,8 @@ and their rule type is `machine_learning`. |<> |Identifies an Azure Active Directory (AD) Global Administrator role addition to a Privileged Identity Management (PIM) user account. PIM is a service that enables you to manage, control, and monitor access to important resources in an organization. Users who are assigned to the Global administrator role can read and modify any administrative setting in your Azure AD organization. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 +|<> |Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |111 |<> |Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |110 @@ -854,10 +922,14 @@ and their rule type is `machine_learning`. |<> |Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9 +|<> |Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 |<> |Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker authenticates is using a user agent that is not consistent with common browser, mobile, or Windows platform authentication clients. Adversary-in-the-middle and OAuth phishing tooling often presents scripted or relayed user agents (for example Node.js, Python, or generic HTTP libraries) while still targeting first-party resources through the broker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4 |<> |Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker's polling client (e.g., Python script) and the victim's browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6 @@ -868,6 +940,8 @@ and their rule type is `machine_learning`. |<> |Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 +|<> |Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |9 |<> |Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Tactic: Persistence], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5 @@ -916,6 +990,8 @@ and their rule type is `machine_learning`. |<> |Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 +|<> |Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 + |<> |Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |5 |<> |Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner for an Azure application in order to grant additional permissions and modify the application's configuration using another account. |[Domain: Cloud], [Data Source: Azure], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 @@ -1082,7 +1158,7 @@ and their rule type is `machine_learning`. |<> |Identifies the load of a driver with an original file name and signature values that were observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |13 -|<> |Detects the first time a third-party application logs in and authenticated with OAuth. OAuth is used to grant permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Defense Evasion], [Tactic: Initial Access], [Resources: Investigation Guide] |None |11 +|<> |Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Defense Evasion], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |12 |<> |Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111 @@ -1224,19 +1300,17 @@ and their rule type is `machine_learning`. |<> |Generates a detection alert for each Google SecOps alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Google SecOps alerts in the app. |[Data Source: Google SecOps], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 -|<> |Google Workspace admins may setup 2-step verification (2SV) to add an extra layer of security to user accounts by asking users to verify their identity when they use login credentials. Admins have the ability to enforce 2SV from the admin console as well as the methods acceptable for verification and enrollment period. 2SV requires enablement on admin accounts prior to it being enabled for users within organization units. Adversaries may disable 2SV to lower the security requirements to access a valid account. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |111 - -|<> |Detects when a domain-wide delegation of authority is granted to a service account. Domain-wide delegation can be configured to grant third-party and internal applications to access the data of Google Workspace users. An adversary may configure domain-wide delegation to maintain access to their target’s data. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |211 +|<> |Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |112 -|<> |Assigning the administrative role to a user will grant them access to the Google Admin console and grant them administrator privileges which allow them to access and manage various resources and applications. An adversary may create a new administrator account for persistence or apply the admin role to an existing user to carry out further intrusion efforts. Users with super-admin privileges can bypass single-sign on if enabled in Google Workspace. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211 +|<> |Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |212 -|<> |Detects when a custom admin role is deleted. An adversary may delete a custom admin role in order to impact the permissions or capabilities of system administrators. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |210 +|<> |Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |212 -|<> |Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |111 +|<> |Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211 -|<> |Detects when a custom admin role is created in Google Workspace. An adversary may create a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |210 +|<> |Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |112 -|<> |Detects when a custom Gmail route is added or modified in Google Workspace. Adversaries can add a custom e-mail route for outbound mail to route these e-mails to their own inbox of choice for data gathering. This allows adversaries to capture sensitive information from e-mail and potential attachments, such as invoices or payment documents. By default, all email from current Google Workspace users with accounts are routed through a domain's mail server for inbound and outbound mail. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |110 +|<> |Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |211 |<> |Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Threat: Tycoon2FA], [Resources: Investigation Guide] |None |1 @@ -1244,19 +1318,21 @@ and their rule type is `machine_learning`. |<> |Detects when Google Workspace administrators initiate bulk movement or export of user Drive data. This includes admin data transfer requests that reassign a user's Drive files to another account, and Customer Takeout export jobs that package organizational data for download or off-platform transfer. Adversaries with administrative access may abuse these mechanisms to stage or exfiltrate sensitive files. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |112 -|<> |Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9 +|<> |Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Credential Access], [Tactic: Collection], [Resources: Investigation Guide] |None |10 + +|<> |Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |111 |<> |Surfaces Google Workspace sign-in events that Google's identity risk engine has flagged as suspicious via the `is_suspicious` field on the `login` activity record. This is Google's own ML-driven sign-in risk signal. The field is set by Google server-side based on signals like sign-ins from anonymizer infrastructure, known-malicious IP ranges, atypical user characteristics, or anomalous device fingerprints. Use this signal as enrichment alongside the other Workspace sign-in rules rather than as a standalone alert. This rule is a building block. It does not generate user-facing alerts by default but populates `signal.rule.building_block_type` for correlation rules or analyst pivots. |[Domain: Cloud], [Domain: Identity], [Data Source: Google Workspace], [Data Source: Google Workspace Audit Logs], [Data Source: Google Workspace User Log Events], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Credential Access], [Rule Type: BBR], [Resources: Investigation Guide] |None |1 -|<> |Detects when multi-factor authentication (MFA) enforcement is disabled for Google Workspace users. An adversary may disable MFA enforcement in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |212 +|<> |Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Impact], [Tactic: Credential Access], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |213 |<> |Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where "copy" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Initial Access], [Resources: Investigation Guide] |None |13 -|<> |Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |210 +|<> |Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211 -|<> |Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |112 +|<> |Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |113 -|<> |Detects when a custom admin role or its permissions are modified. An adversary may modify a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |210 +|<> |Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence], [Tactic: Privilege Escalation] |None |211 |<> |Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 @@ -1300,7 +1376,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job combination has identified a host with one or more suspicious Windows processes that exhibit unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |111 -|<> |Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable and use WSL to avoid detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Data Source: SentinelOne] |None |114 +|<> |Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable and use WSL to avoid detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Data Source: SentinelOne] |None |115 |<> |The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or RHEL) and macOS systems. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |214 @@ -1310,7 +1386,7 @@ and their rule type is `machine_learning`. |<> |Identifies when Internet Information Services (IIS) HTTP Logging is disabled on a server. An attacker with IIS server access via a webshell or other mechanism can disable HTTP Logging as an effective anti-forensics measure. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318 -|<> |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. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |110 +|<> |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. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: pfSense], [Resources: Investigation Guide] |None |111 |<> |This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |108 @@ -1360,6 +1436,8 @@ and their rule type is `machine_learning`. |<> |Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |216 +|<> |Identifies a recently dropped or modified javaw.exe process started from a user-writable path to run a JAR or Java classpath application, followed by a DNS lookup. Adversaries may drop Java payloads into user directories and execute them immediately to establish command and control while evading application control focused on native Windows binaries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + |<> |Identifies the creation or modification of a K Desktop Environment (KDE) AutoStart script or desktop file that will execute upon each user logon. Adversaries may abuse this method for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |220 |<> |Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214 @@ -1380,7 +1458,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 -|<> |Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |216 +|<> |Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |217 |<> |Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This rule identifies attempts to remove a kernel module. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |215 @@ -1534,8 +1612,6 @@ and their rule type is `machine_learning`. |<> |This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 -|<> |Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |119 - |<> |This rule monitors for X11 forwarding via SSH. X11 forwarding is a feature that allows users to run graphical applications on a remote server and display the application's graphical user interface on their local machine. Attackers can abuse X11 forwarding for tunneling their GUI-based tools, pivot through compromised systems, and create covert communication channels, enabling lateral movement and facilitating remote control of systems within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |109 |<> |This rule identifies Linux system information discovery activity via built-in commands that read common system files. Adversaries may use these commands to gather information about the operating system, installed services, and hardware configuration to aid in further exploration and exploitation of the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne] |None |8 @@ -1548,7 +1624,7 @@ and their rule type is `machine_learning`. |<> |This rule detects Linux user account credential modification events where the echo command is used to directly echo a password into the passwd or shadow utilities. This technique is used by malware to automate the process of user account credential modification on Linux systems post-infection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 -|<> |Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |114 +|<> |Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |115 |<> |This rule detects the deletion of user or group accounts on Linux systems. Adversaries may use these commands to remove accounts to cover their tracks or disrupt operations. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 @@ -1610,6 +1686,10 @@ and their rule type is `machine_learning`. |<> |Identifies when a new role is assigned to a management group in Microsoft 365. An adversary may attempt to add a role in order to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |213 +|<> |Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |1 + +|<> |Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |1 + |<> |Identifies when the Microsoft 365 Global Administrator or Company Administrator role is assigned to a user or service principal. The Global Administrator role has extensive privileges across Entra ID and Microsoft 365 services, making it a high-value target for adversaries seeking persistent access. Successful assignments of this role may indicate potential privilege escalation or unauthorized access attempts, especially if performed by accounts that do not typically manage high-privilege roles. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |215 |<> |Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |11 @@ -1658,14 +1738,14 @@ and their rule type is `machine_learning`. |<> |Identifies when custom applications are allowed in Microsoft Teams. If an organization requires applications other than those available in the Teams app store, custom applications can be developed as packages and uploaded. An adversary may abuse this behavior to establish persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |214 +|<> |Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies Microsoft 365 audit logs generated for Threat Intelligence signals by Microsoft Defender for Office 365. This includes phishing and malware events, campaign-related threat detections, file-based threats in SharePoint, OneDrive, and Teams, as well as Microsoft Threat Intelligence Center (MSTIC) signals. These events provide early indicators of compromise attempts and can be correlated with other signals for threat hunting and detection. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Defender], [Data Source: Microsoft Defender for Office 365], [Data Source: Microsoft Threat Intelligence], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Resources: Investigation Guide], [Rule Type: BBR] |None |4 |<> |This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |8 |<> |Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account. |[Tactic: Persistence], [Use Case: Identity and Access Audit], [Data Source: Okta], [Domain: Cloud], [Resources: Investigation Guide] |None |419 -|<> |Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |210 - |<> |Microsoft Office Products offer options for users and developers to control the security settings for running and using Macros. Adversaries may abuse these security settings to modify the default behavior of the Office Application to trust future macros and/or disable security warnings, which could increase their chances of establishing persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |313 |<> |A supervised machine learning model has identified a DNS question name that used by the SUNBURST malware and is predicted to be the result of a Domain Generation Algorithm. |[Domain: Network], [Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Domain Generation Algorithm Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |10 @@ -1786,6 +1866,8 @@ and their rule type is `machine_learning`. |<> |This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information. |[Domain: Cloud], [Domain: IAM], [Domain: Storage], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Data Source: Azure], [Data Source: Azure Activity Logs], [Data Source: GCP], [Data Source: Google Cloud Platform], [Data Source: Kubernetes], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6 +|<> |Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. |[Domain: Network], [Domain: Endpoint], [Use Case: Threat Detection], [Use Case: Vulnerability], [Use Case: Network Security Monitoring], [Tactic: Credential Access], [Tactic: Execution], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1 + |<> |This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. |[Domain: Identity], [Domain: SaaS], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |311 |<> |This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |3 @@ -1996,7 +2078,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the usage of "curl" or "wget" to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |7 -|<> |This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107 +|<> |This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 |<> |This rule monitors for the creation of Pluggable Authentication Module (PAM) shared object files or configuration files. Attackers may create these files to maintain persistence on a compromised system, or harvest account credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9 @@ -2004,7 +2086,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors for the creation of Polkit policy files on Linux systems. Polkit policy files are used to define the permissions for system-wide services and applications. The creation of new Polkit policy files may indicate an attempt to modify the authentication process, which could be used for persistence by an adversary. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |107 -|<> |This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |7 +|<> |This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |8 |<> |Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network segmentation restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |419 @@ -2014,6 +2096,8 @@ and their rule type is `machine_learning`. |<> |Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to create DNS-named records. Attackers can create wildcard records to redirect traffic for names that do not explicitly match records in the zone, positioning themselves as an adversary-in-the-middle and enabling credential interception or relay through ADIDNS manipulation similar in outcome to LLMNR/NBNS spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108 +|<> |Identifies PowerShell script block content associated with an Antimalware Scan Interface (AMSI) bypass that hooks the RPC runtime marshaling stub NdrClientCall3 (or NdrClientCall2) in rpcrt4.dll. Unlike bypasses that patch AmsiScanBuffer or set amsiInitFailed, this technique operates at the RPC layer used by AMSI to delegate scan requests to the antivirus provider, tampering with the request before it reaches the engine and leaving AMSI itself unmodified. The loader allocates an executable trampoline and marshals a delegate to the native stub; these primitives appear in PowerShell Script Block Logging before the hook takes effect. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |1 + |<> |Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |12 |<> |Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Potential Overload], [Use Case: Resource Exhaustion], [Mitre Atlas: LLM04], [Resources: Investigation Guide] |None |8 @@ -2088,7 +2172,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected data exfiltration to a particular geo-location (by region name). Data transfers to geo-locations that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |7 -|<> |Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Auditd Manager], [Data Source: Windows Security Event Logs] |None |7 +|<> |Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Auditd Manager], [Data Source: Windows Security Event Logs] |None |8 |<> |Detects the use of wget to upload files to an internet server. Threat actors often will collect data on a system and attempt to exfiltrate it back to their command and control servers. Use of wget in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |3 @@ -2218,7 +2302,7 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious instances of communications apps, both unsigned and renamed ones, that can indicate an attempt to conceal malicious activity, bypass security features such as allowlists, or trick users into executing malware. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Elastic Endgame] |None |13 -|<> |Identifies suspicious instances of default system32 DLLs either unsigned or signed with non-MS certificates. This can potentially indicate the attempt to masquerade as system DLLs, perform DLL Search Order Hijacking or backdoor and resign legitimate DLLs. |[Domain: Endpoint], [Data Source: Elastic Defend], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Rule Type: BBR] |None |110 +|<> |Identifies suspicious instances of default system32 DLLs either unsigned or signed with non-MS certificates. This can potentially indicate the attempt to masquerade as system DLLs, perform DLL Search Order Hijacking or backdoor and resign legitimate DLLs. |[Domain: Endpoint], [Data Source: Elastic Defend], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |111 |<> |Identifies suspicious instances of default system32 executables, either unsigned or signed with non-MS certificates. This could indicate the attempt to masquerade as system executables or backdoored and resigned legitimate executables. |[Domain: Endpoint], [Data Source: Elastic Defend], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Rule Type: BBR] |None |9 @@ -2258,7 +2342,7 @@ and their rule type is `machine_learning`. |<> |Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. |[Domain: Identity], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Data Source: Okta System Logs], [Resources: Investigation Guide] |None |418 -|<> |Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |215 +|<> |Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |216 |<> |Adversaries may attempt to connect to a remote system over Windows Remote Desktop Protocol (RDP) to achieve lateral movement. Adversaries may avoid using the Microsoft Terminal Services Client (mstsc.exe) binary to establish an RDP connection to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6 @@ -2368,6 +2452,12 @@ and their rule type is `machine_learning`. |<> |Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |8 +|<> |This rule detects attempts to abuse Redis CONFIG SET commands to redirect the database save directory to a cron directory on Linux hosts. Attackers issue CONFIG SET dir to a cron path such as /etc/cron.d or /var/spool/cron, set a filename via CONFIG SET dbfilename, write a cron payload via SET, and then call BGSAVE to flush it to disk, establishing persistence for execution of an XMRig cryptominer. |[Domain: Network], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Impact], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + +|<> |This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root. |[Domain: Network], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + +|<> |This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. |[Domain: Network], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + |<> |Identifies remote access to the registry to potentially dump credential data from the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |114 |<> |Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |316 @@ -2468,7 +2558,7 @@ and their rule type is `machine_learning`. |<> |This detection rule identifies when 'SCNotification.exe' loads an untrusted DLL, which is a potential indicator of an attacker attempt to hijack/impersonate a Windows user session. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 -|<> |Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. |[Domain: Network], [Domain: Application], [Domain: Web], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Initial Access], [Data Source: Network Packet Capture], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1 +|<> |Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. |[Domain: Network], [Domain: Application], [Domain: Web], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Initial Access], [Data Source: Network Packet Capture], [Data Source: Network Traffic], [Data Source: Zeek], [Resources: Investigation Guide] |None |2 |<> |Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 @@ -2610,15 +2700,17 @@ and their rule type is `machine_learning`. |<> |This rule identifies the execution of commands that can be used to query the Windows Registry. Adversaries may query the registry to gain situational awareness about the host, like installed security software, programs and settings. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend] |None |108 -|<> |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. |[Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |110 +|<> |Identifies when Microsoft Quick Assist sharing mode is set to FullControl on a Windows host. This grants the remote helper full interactive control of the target device and may indicate IT help desk fraud, unauthorized remote access, or lateral movement preparation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Data Source: Windows Application Event Logs], [Resources: Investigation Guide] |None |1 + +|<> |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. |[Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |111 |<> |Identifies registry write modifications to enable Remote Desktop Protocol (RDP) access. This could be indicative of adversary lateral movement preparation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317 |<> |Identifies the execution of a Python script that uses the ROT cipher for letters substitution. Adversaries may use this method to encode and obfuscate part of their malicious code in legit python packages. |[Domain: Endpoint], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 -|<> |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. |[Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |111 +|<> |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. |[Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: Network Traffic], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |112 -|<> |This rule detects network events that may indicate the use of RPC traffic to 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. |[Tactic: Initial Access], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |110 +|<> |This rule detects network events that may indicate the use of RPC traffic to 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. |[Tactic: Initial Access], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |111 |<> |This rule leverages the new_terms rule type to identify the installation of RPM packages by an unusual parent process. RPM is a package management system used in Linux systems such as Red Hat, CentOS and Fedora. Attacks may backdoor RPM packages to gain initial access or install malicious RPM packages to maintain persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 @@ -2674,7 +2766,7 @@ and their rule type is `machine_learning`. |<> |Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame] |None |4 -|<> |Detects use of the systemsetup command to enable remote SSH Login. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 +|<> |Detects use of the systemsetup command to enable remote SSH Login. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 |<> |Identifies remote scheduled task creations on a target host. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |215 @@ -2704,11 +2796,11 @@ and their rule type is `machine_learning`. |<> |Identifies modifications to the registered Subject Interface Package (SIP) providers. SIP providers are used by the Windows cryptographic system to validate file signatures on the system. This may be an attempt to bypass signature validation checks or inject code into critical processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |316 -|<> |This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted systems. 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 or for data exfiltration. |[Tactic: Initial Access], [Tactic: Exfiltration], [Domain: Network], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |111 +|<> |This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted systems. 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 or for data exfiltration. |[Tactic: Initial Access], [Tactic: Exfiltration], [Domain: Network], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |112 |<> |Identifies potentially suspicious processes that are not trusted or living-off-the-land binaries (LOLBin) making Server Message Block (SMB) network connections over port 445. Windows File Sharing is typically implemented over SMB, which communicates between hosts using port 445. Legitimate connections are generally established by the kernel (PID 4). This rule helps to detect processes that might be port scanners, exploits, or user-level processes attempting lateral movement within the network by leveraging SMB connections. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |117 -|<> |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. |[Tactic: Command and Control], [Tactic: Exfiltration], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |111 +|<> |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. |[Tactic: Command and Control], [Tactic: Exfiltration], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |112 |<> |The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s). |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |210 @@ -2740,7 +2832,7 @@ and their rule type is `machine_learning`. |<> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318 -|<> |This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |107 +|<> |This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |108 |<> |Identifies the use of Windows Management Instrumentation Command (WMIC) to discover certain System Security Settings such as AntiVirus or Host Firewall details. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Windows Security Event Logs] |None |217 @@ -2920,13 +3012,13 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious commands being used with certutil.exe. CertUtil is a native Windows component which is part of Certificate Services. CertUtil is often abused by attackers to live off the land for stealthier command and control or data exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318 -|<> |Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |114 +|<> |Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |115 |<> |Detects attempts to exploit privilege escalation vulnerabilities related to the Adobe Acrobat Reader PrivilegedHelperTool responsible for installing updates. For more information, refer to CVE-2020-9615, CVE-2020-9614 and CVE-2020-9613 and verify that the impacted system is patched. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110 |<> |Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |322 -|<> |Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 |<> |Identifies a network connection by the command prompt (cmd.exe) when it is executed with specific arguments, such as a script or a URL, or when it is spawned by Microsoft Office applications. Adversaries often abuse cmd.exe to download malicious payloads or establish command and control channels from a remote source. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |215 @@ -3006,7 +3098,7 @@ and their rule type is `machine_learning`. |<> |Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. |[Domain: Endpoint], [Domain: Identity], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |5 -|<> |This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |5 +|<> |This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |6 |<> |Monitors for the elevation of regular user permissions to root permissions through the kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process, and hijack the execution flow by hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |7 @@ -3278,7 +3370,7 @@ and their rule type is `machine_learning`. |<> |This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12 -|<> |This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. |[Domain: Endpoint], [Domain: Web], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. |[Domain: Endpoint], [Domain: Web], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 |<> |Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |319 @@ -3288,7 +3380,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |213 -|<> |This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. |[Domain: Endpoint], [Domain: Web], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4 +|<> |This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. |[Domain: Endpoint], [Domain: Web], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5 |<> |A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |212 @@ -3488,9 +3580,9 @@ and their rule type is `machine_learning`. |<> |This rule leverages the "auditd_manager" integration to detect user or group creation or modification events on Linux systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |8 -|<> |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. |[Tactic: Command and Control], [Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |111 +|<> |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. |[Tactic: Command and Control], [Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: pfSense], [Resources: Investigation Guide] |None |112 -|<> |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. |[Tactic: Command and Control], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |111 +|<> |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. |[Tactic: Command and Control], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: pfSense], [Resources: Investigation Guide] |None |112 |<> |Identifies potential credential decrypt operations by PowerShell or unsigned processes using the Veeam.Backup.Common.dll library. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index 9094508f45..500061e1f9 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -3,11 +3,26 @@ include::rule-details/apt-package-manager-configuration-file-creation.asciidoc[] include::rule-details/aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc[] include::rule-details/aws-access-token-used-from-multiple-addresses.asciidoc[] include::rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc[] +include::rule-details/aws-bedrock-agent-created-by-iam-user-or-root.asciidoc[] +include::rule-details/aws-bedrock-agent-or-action-group-manipulation.asciidoc[] +include::rule-details/aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc[] include::rule-details/aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc[] include::rule-details/aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc[] +include::rule-details/aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc[] +include::rule-details/aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc[] +include::rule-details/aws-bedrock-guardrail-deleted-or-weakened.asciidoc[] include::rule-details/aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc[] include::rule-details/aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc[] +include::rule-details/aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc[] include::rule-details/aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc[] +include::rule-details/aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc[] +include::rule-details/aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc[] +include::rule-details/aws-bedrock-provisioned-model-throughput-tampering.asciidoc[] +include::rule-details/aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc[] +include::rule-details/aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc[] +include::rule-details/aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc[] +include::rule-details/aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc[] +include::rule-details/aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc[] include::rule-details/aws-cli-command-with-custom-endpoint-url.asciidoc[] include::rule-details/aws-cloudshell-environment-created.asciidoc[] include::rule-details/aws-cloudtrail-log-created.asciidoc[] @@ -84,10 +99,18 @@ include::rule-details/aws-iam-user-addition-to-group.asciidoc[] include::rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc[] include::rule-details/aws-iam-virtual-mfa-device-registration-attempt-with-session-token.asciidoc[] include::rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc[] +include::rule-details/aws-kms-imported-key-material-deleted.asciidoc[] include::rule-details/aws-kms-key-policy-updated-via-putkeypolicy.asciidoc[] +include::rule-details/aws-lambda-event-source-mapping-creation.asciidoc[] include::rule-details/aws-lambda-function-created-or-updated.asciidoc[] +include::rule-details/aws-lambda-function-deletion.asciidoc[] +include::rule-details/aws-lambda-function-invoked-by-an-unusual-principal.asciidoc[] +include::rule-details/aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc[] +include::rule-details/aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc[] include::rule-details/aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] +include::rule-details/aws-lambda-function-url-created-with-public-access.asciidoc[] include::rule-details/aws-lambda-layer-added-to-existing-function.asciidoc[] +include::rule-details/aws-lambda-layer-shared-externally.asciidoc[] include::rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc[] include::rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc[] include::rule-details/aws-management-console-root-login.asciidoc[] @@ -218,6 +241,10 @@ include::rule-details/attempted-private-key-access.asciidoc[] include::rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc[] include::rule-details/authentication-via-unusual-pam-grantor.asciidoc[] include::rule-details/authorization-plugin-modification.asciidoc[] +include::rule-details/azure-ad-graph-access-with-suspicious-user-agent.asciidoc[] +include::rule-details/azure-ad-graph-access-with-unusual-client-and-user.asciidoc[] +include::rule-details/azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc[] +include::rule-details/azure-ad-graph-potential-enumeration-roadrecon.asciidoc[] include::rule-details/azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc[] include::rule-details/azure-automation-account-created.asciidoc[] include::rule-details/azure-automation-runbook-created-or-modified.asciidoc[] @@ -253,7 +280,11 @@ include::rule-details/azure-storage-account-deletions-by-user.asciidoc[] include::rule-details/azure-storage-account-key-regenerated.asciidoc[] include::rule-details/azure-storage-account-keys-accessed-by-privileged-user.asciidoc[] include::rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc[] +include::rule-details/azure-vm-boot-diagnostics-retrieved.asciidoc[] +include::rule-details/azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc[] include::rule-details/azure-vm-extension-deployment-by-user.asciidoc[] +include::rule-details/azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc[] +include::rule-details/azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc[] include::rule-details/azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc[] include::rule-details/azure-vnet-firewall-policy-deleted.asciidoc[] include::rule-details/azure-vnet-full-network-packet-capture-enabled.asciidoc[] @@ -342,6 +373,7 @@ include::rule-details/delete-volume-usn-journal-with-fsutil.asciidoc[] include::rule-details/deprecated-adobe-hijack-persistence.asciidoc[] include::rule-details/deprecated-eggshell-backdoor-execution.asciidoc[] include::rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc[] +include::rule-details/deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc[] include::rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc[] include::rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc[] include::rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[] @@ -349,6 +381,7 @@ include::rule-details/deprecated-m365-security-compliance-unusual-volume-of-file include::rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc[] include::rule-details/deprecated-m365-teams-external-access-enabled.asciidoc[] include::rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc[] +include::rule-details/deprecated-mfa-disabled-for-google-workspace-organization.asciidoc[] include::rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc[] include::rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc[] include::rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc[] @@ -412,19 +445,23 @@ include::rule-details/entra-id-external-guest-user-invited.asciidoc[] include::rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc[] include::rule-details/entra-id-global-administrator-role-assigned.asciidoc[] include::rule-details/entra-id-global-administrator-role-assigned-pim-user.asciidoc[] +include::rule-details/entra-id-guest-account-promoted-to-member.asciidoc[] include::rule-details/entra-id-high-risk-sign-in.asciidoc[] include::rule-details/entra-id-high-risk-user-sign-in-heuristic.asciidoc[] include::rule-details/entra-id-illicit-consent-grant-via-registered-application.asciidoc[] include::rule-details/entra-id-kali365-default-user-agent-detected.asciidoc[] include::rule-details/entra-id-mfa-disabled-for-user.asciidoc[] include::rule-details/entra-id-mfa-totp-brute-force-attempted.asciidoc[] +include::rule-details/entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc[] include::rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc[] include::rule-details/entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc[] +include::rule-details/entra-id-oauth-application-redirect-uri-modified.asciidoc[] include::rule-details/entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc[] include::rule-details/entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc[] include::rule-details/entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc[] include::rule-details/entra-id-oauth-device-code-grant-by-unusual-user.asciidoc[] include::rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc[] +include::rule-details/entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc[] include::rule-details/entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc[] include::rule-details/entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc[] include::rule-details/entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc[] @@ -449,6 +486,7 @@ include::rule-details/entra-id-sharepoint-or-onedrive-accessed-by-unusual-client include::rule-details/entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc[] include::rule-details/entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc[] include::rule-details/entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc[] +include::rule-details/entra-id-temporary-access-pass-created-for-user.asciidoc[] include::rule-details/entra-id-unusual-cloud-device-registration.asciidoc[] include::rule-details/entra-id-user-added-as-registered-application-owner.asciidoc[] include::rule-details/entra-id-user-added-as-service-principal-owner.asciidoc[] @@ -603,19 +641,19 @@ include::rule-details/github-user-blocked-from-organization.asciidoc[] include::rule-details/github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc[] include::rule-details/google-calendar-c2-via-script-interpreter.asciidoc[] include::rule-details/google-secops-external-alerts.asciidoc[] -include::rule-details/google-workspace-2sv-policy-disabled.asciidoc[] +include::rule-details/google-workspace-2sv-policy-disabled-by-user.asciidoc[] include::rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] -include::rule-details/google-workspace-admin-role-assigned-to-a-user.asciidoc[] +include::rule-details/google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc[] include::rule-details/google-workspace-admin-role-deletion.asciidoc[] include::rule-details/google-workspace-bitlocker-setting-disabled.asciidoc[] include::rule-details/google-workspace-custom-admin-role-created.asciidoc[] -include::rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc[] include::rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc[] include::rule-details/google-workspace-device-registration-burst-for-single-user.asciidoc[] include::rule-details/google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc[] include::rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[] +include::rule-details/google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc[] include::rule-details/google-workspace-login-flagged-suspicious.asciidoc[] -include::rule-details/google-workspace-mfa-enforcement-disabled.asciidoc[] +include::rule-details/google-workspace-mfa-enforcement-disabled-for-organization.asciidoc[] include::rule-details/google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc[] include::rule-details/google-workspace-password-policy-modified.asciidoc[] include::rule-details/google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc[] @@ -671,6 +709,7 @@ include::rule-details/interactive-logon-by-an-unusual-process.asciidoc[] include::rule-details/interactive-shell-launched-via-unusual-parent-process-in-a-container.asciidoc[] include::rule-details/interactive-terminal-spawned-via-perl.asciidoc[] include::rule-details/interactive-terminal-spawned-via-python.asciidoc[] +include::rule-details/java-dropped-and-executed-with-dns-lookup.asciidoc[] include::rule-details/kde-autostart-script-or-desktop-file-creation.asciidoc[] include::rule-details/krbtgt-delegation-backdoor.asciidoc[] include::rule-details/kerberos-cached-credentials-dumping.asciidoc[] @@ -758,7 +797,6 @@ include::rule-details/linux-audio-recording-activity-detected.asciidoc[] include::rule-details/linux-clipboard-activity-detected.asciidoc[] include::rule-details/linux-group-creation.asciidoc[] include::rule-details/linux-process-hooking-via-gdb.asciidoc[] -include::rule-details/linux-restricted-shell-breakout-via-linux-binary-s.asciidoc[] include::rule-details/linux-ssh-x11-forwarding.asciidoc[] include::rule-details/linux-system-information-discovery.asciidoc[] include::rule-details/linux-system-information-discovery-via-getconf.asciidoc[] @@ -796,6 +834,8 @@ include::rule-details/m365-exchange-mailbox-items-accessed-excessively.asciidoc[ include::rule-details/m365-exchange-malware-filter-policy-deleted.asciidoc[] include::rule-details/m365-exchange-malware-filter-rule-modified.asciidoc[] include::rule-details/m365-exchange-management-group-role-assigned.asciidoc[] +include::rule-details/m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc[] +include::rule-details/m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc[] include::rule-details/m365-identity-global-administrator-role-assigned.asciidoc[] include::rule-details/m365-identity-login-from-atypical-region.asciidoc[] include::rule-details/m365-identity-login-from-impossible-travel-location.asciidoc[] @@ -820,10 +860,10 @@ include::rule-details/m365-sharepoint-site-administrator-added.asciidoc[] include::rule-details/m365-sharepoint-site-sharing-policy-weakened.asciidoc[] include::rule-details/m365-sharepoint-onedrive-file-access-via-powershell.asciidoc[] include::rule-details/m365-teams-custom-application-interaction-enabled.asciidoc[] +include::rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc[] include::rule-details/m365-threat-intelligence-signal.asciidoc[] include::rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc[] include::rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[] -include::rule-details/mfa-disabled-for-google-workspace-organization.asciidoc[] include::rule-details/ms-office-macro-security-registry-modifications.asciidoc[] include::rule-details/machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc[] include::rule-details/machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc[] @@ -884,6 +924,7 @@ include::rule-details/multiple-alerts-in-different-att-ck-tactics-on-a-single-ho include::rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc[] include::rule-details/multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc[] include::rule-details/multiple-cloud-secrets-accessed-by-source-address.asciidoc[] +include::rule-details/multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc[] include::rule-details/multiple-device-token-hashes-for-single-okta-session.asciidoc[] include::rule-details/multiple-elastic-defend-alerts-by-agent.asciidoc[] include::rule-details/multiple-elastic-defend-alerts-from-a-single-process-tree.asciidoc[] @@ -998,6 +1039,7 @@ include::rule-details/port-forwarding-rule-addition.asciidoc[] include::rule-details/possible-fin7-dga-command-and-control-behavior.asciidoc[] include::rule-details/possible-okta-dos-attack.asciidoc[] include::rule-details/potential-adidns-poisoning-via-wildcard-record-creation.asciidoc[] +include::rule-details/potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc[] include::rule-details/potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[] include::rule-details/potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc[] include::rule-details/potential-account-takeover-logon-from-new-source-ip.asciidoc[] @@ -1175,6 +1217,9 @@ include::rule-details/potential-protocol-tunneling-via-yuze.asciidoc[] include::rule-details/potential-remcos-trojan-execution.asciidoc[] include::rule-details/potential-ransomware-behavior-note-files-by-system.asciidoc[] include::rule-details/potential-ransomware-note-file-dropped-via-smb.asciidoc[] +include::rule-details/potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc[] +include::rule-details/potential-redis-config-set-ssh-authorized-key-injection.asciidoc[] +include::rule-details/potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc[] include::rule-details/potential-remote-credential-access-via-registry.asciidoc[] include::rule-details/potential-remote-desktop-shadowing-activity.asciidoc[] include::rule-details/potential-remote-desktop-tunneling-detected.asciidoc[] @@ -1296,6 +1341,7 @@ include::rule-details/python-path-file-pth-creation.asciidoc[] include::rule-details/python-site-or-user-customize-file-creation.asciidoc[] include::rule-details/quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc[] include::rule-details/query-registry-using-built-in-tools.asciidoc[] +include::rule-details/quick-assist-full-control-sharing-mode-enabled.asciidoc[] include::rule-details/rdp-remote-desktop-protocol-from-the-internet.asciidoc[] include::rule-details/rdp-enabled-via-registry.asciidoc[] include::rule-details/rot-encoded-python-script-execution.asciidoc[] diff --git a/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc index c0a4bb627a..7fe9aed88e 100644 --- a/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc @@ -9,6 +9,8 @@ Specially crafted DNS requests can manipulate a known overflow vulnerability in * logs-network_traffic.* * logs-panw.panos* +* logs-zeek.* +* logs-corelight.* *Severity*: medium @@ -34,10 +36,12 @@ Specially crafted DNS requests can manipulate a known overflow vulnerability in * Tactic: Impact * Resources: Investigation Guide * Use Case: Vulnerability +* Data Source: Corelight * Data Source: PAN-OS * Data Source: Network Traffic +* Data Source: Zeek -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -75,7 +79,7 @@ Detection alerts from this rule indicate possible anomalous activity around larg - Based on this rule, which looks for a threshold of 65k bytes, activity below this value is expected to be legitimate. In packet capture files received by the https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/[SANS Internet Storm Center], byte responses in observed attacks were all greater than 65k bytes. - This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host. -- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow records (`event.duration` > 60 seconds) with `event.action` of `flow_terminated` or `network_flow` are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection. +- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters, as well as Zeek/Corelight connection summary records, record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow or connection records (`event.duration` > 60 seconds) are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection. *Related rules* @@ -102,12 +106,17 @@ Detection alerts from this rule indicate possible anomalous activity around larg ---------------------------------- ((event.category:(network or network_traffic) and destination.port:53) or network.protocol:"dns" - or data_stream.dataset:(network_traffic.dns or zeek.dns)) + or data_stream.dataset:(network_traffic.dns or zeek.dns) + or (event.module:corelight and event.dataset:dns)) and destination.bytes >= 65000 and event.type:("allowed" or "end" or "protocol" or "start") and not ( - event.action:("flow_terminated" or "network_flow") - and event.duration > 60000000000 + event.duration > 60000000000 + and ( + event.action:("flow_terminated" or "network_flow") + or data_stream.dataset:zeek.connection + or (event.module:corelight and event.dataset:conn) + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc index bc2e5c5ebc..175dfe84a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc @@ -13,6 +13,7 @@ This rule detects network events that may indicate the use of Telnet traffic. Te * logs-network_traffic.* * logs-panw.panos* * logs-fortinet_fortigate.log-* +* logs-pfsense.log-* * logs-sonicwall_firewall.log-* * logs-suricata.* @@ -35,13 +36,14 @@ This rule detects network events that may indicate the use of Telnet traffic. Te * Tactic: Command and Control * Tactic: Lateral Movement * Tactic: Initial Access -* Data Source: PAN-OS * Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense * Data Source: SonicWall * Data Source: Suricata * Resources: Investigation Guide -*Version*: 114 +*Version*: 115 *Rule authors*: @@ -105,14 +107,14 @@ Telnet, a protocol for remote command-line access, is often used in legacy syste [source, js] ---------------------------------- (data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow - or sonicwall_firewall.log or suricata.eve or panw.panos) + 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 end) - and not event.action:(flow_dropped or flow_denied or denied or deny or - flow_terminated or timeout or Reject or network_flow or connection-denied or - connection-end or server-rst or client-rst) + 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:(traceroute or stretchoid-scanning) + and not network.application:(stretchoid-scanning or traceroute) and destination.port:23 ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc index 1ea353f925..1ffce5be78 100644 --- a/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc @@ -1,14 +1,14 @@ [[application-added-to-google-workspace-domain]] === Application Added to Google Workspace Domain -Detects when a Google marketplace application is added to the Google Workspace domain. An adversary may add a malicious application to an organization’s Google Workspace domain in order to maintain a presence in their target’s organization and steal data. +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* +* logs-google_workspace.admin-* *Severity*: medium @@ -34,7 +34,7 @@ Detects when a Google marketplace application is added to the Google Workspace d * Tactic: Persistence * Resources: Investigation Guide -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,39 +54,52 @@ Detects when a Google marketplace application is added to the Google Workspace d *Investigating Application Added to Google Workspace Domain* -Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or on Google Apps Script and created by both Google and third-party developers. +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. -Marketplace applications require access to specific Google Workspace resources. Applications can be installed by individual users, if they have permission, or can be installed for an entire Google Workspace domain by administrators. Consent screens typically display what permissions and privileges the application requires during installation. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent. - -Google clearly states that they are not responsible for any product on the Marketplace that originates from a source other than Google. - -This rule checks for applications that were manually added to the Marketplace by a Google Workspace account. +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 associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. -- With access to the Google Workspace admin console, visit the `Security > Investigation tool` with filters for the user email and event is `Assign Role` or `Update Role` to determine if new cloud roles were recently updated. -- With the user account, review other potentially related events within the last 48 hours. -- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. -- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace Apps`. +- 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: "" 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* -- Google Workspace administrators might intentionally remove an application from the blocklist due to a re-assessment or a domain-wide required need for the application. -- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. -- Contact the user to verify that they intentionally removed the application from the blocklist and their reasoning. +- 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 the outcome of the triage. -- Disable or limit the account during the investigation and response. +- 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. @@ -94,7 +107,7 @@ This rule checks for applications that were manually added to the Marketplace by - 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 user to ensure that the least privilege principle is being followed. +- 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). @@ -106,8 +119,7 @@ This rule checks for applications that were manually added to the Marketplace by - 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). +- 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 @@ -122,7 +134,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:ADD_APPLICATION +data_stream.dataset:google_workspace.admin and event.action:ADD_APPLICATION ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc index f53e0ba788..0f11b42c55 100644 --- a/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc @@ -8,7 +8,7 @@ Google Workspace administrators may be aware of malicious applications within th *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -34,7 +34,7 @@ Google Workspace administrators may be aware of malicious applications within th * Resources: Investigation Guide * Tactic: Defense Evasion -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -67,11 +67,12 @@ This rule identifies a Marketplace blocklist update that consists of a Google Wo - Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the app moved from blocked to allowed and note the affected organizational unit (`google_workspace.admin.org_unit.name`). - This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. - With access to the Google Workspace admin console, visit the `Security > Investigation` tool with filters for the user email and event is `Assign Role` or `Update Role` to determine if new cloud roles were recently updated. - After identifying the involved user account, review other potentially related events within the last 48 hours. - Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. -- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace Apps`. +- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace apps > Apps list`. *False positive analysis* @@ -122,7 +123,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:"google_workspace.admin" and event.category:"iam" and event.type:"change" and +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and google_workspace.admin.application.name:"Google Workspace Marketplace" and google_workspace.admin.old_value: *allowed*false* and google_workspace.admin.new_value: *allowed*true* diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-created-by-iam-user-or-root.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-created-by-iam-user-or-root.asciidoc new file mode 100644 index 0000000000..88a4e4535e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-created-by-iam-user-or-root.asciidoc @@ -0,0 +1,121 @@ +[[aws-bedrock-agent-created-by-iam-user-or-root]] +=== AWS Bedrock Agent Created by IAM User or Root + +Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent Created by IAM User or Root* + + +AWS Bedrock Agents can autonomously perform complex tasks by combining foundation models with action groups +(Lambda functions) and knowledge bases. A rogue agent could serve as a persistent AI-driven foothold, executing +attacker-controlled instructions via inference requests. + + +*Possible investigation steps* + + +- **Identity**: `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`. This rule fires only + for IAMUser or Root — both are direct human credentials, not automated pipeline roles. Confirm the user is + known and authorized to create agents. + +- **Agent configuration** in `aws.cloudtrail.request_parameters`: + - `agentName` — does the name match known internal projects? + - `foundationModel` — which model was selected? Expensive models (Claude Opus-class) indicate higher cost risk. + - `instruction` — the system prompt. Adversarial, minimal, or exfiltration-oriented instructions are a red flag. + - `actionGroupExecutor.lambda` — Lambda ARN presence means the agent can invoke external code. + +- **Cross-account indicators**: Lambda ARNs in action groups belonging to a different account than + `cloud.account.id` indicate external code execution capability. + +- **Follow-on activity**: Look for `PrepareAgent`, `CreateAgentAlias`, `CreateAgentActionGroup`, or + `AssociateAgentKnowledgeBase` from the same identity within the next hour. + + +*False positive analysis* + +- Developers creating agents interactively with personal IAM user credentials. Confirm the agent is for a known + project and the IAM user is authorized. Production agent deployment should use IAM roles — personal key use + is itself a misconfiguration worth noting. + + +*Response and remediation* + +- Delete the unauthorized agent using `DeleteAgent`. +- Review and remove associated action groups and aliases. +- Audit Lambda functions referenced in action group executors for malicious code. +- Restrict `bedrock:CreateAgent` to specific deployment roles via IAM policy or SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: "CreateAgent" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("IAMUser" or "Root") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-or-action-group-manipulation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-or-action-group-manipulation.asciidoc new file mode 100644 index 0000000000..50b4761e5c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-agent-or-action-group-manipulation.asciidoc @@ -0,0 +1,141 @@ +[[aws-bedrock-agent-or-action-group-manipulation]] +=== AWS Bedrock Agent or Action Group Manipulation + +Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateAgent.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgentActionGroup.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_PrepareAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent or Action Group Manipulation* + + +Amazon Bedrock agents orchestrate foundation models with developer-defined instructions and action groups that connect +the agent to Lambda functions or APIs. Because end users and applications repeatedly invoke deployed agents, an attacker +who modifies an existing agent's instructions, action groups, collaborators, or alias can implant durable malicious +behavior into a trusted component without deploying any new infrastructure. The `PrepareAgent` call makes a tampered +configuration live, and updating an alias repoints traffic to the tampered version. + +This rule identifies changes to existing Bedrock agents while intentionally excluding `CreateAgent`, which represents +net-new resource creation rather than tampering with established, trusted agents. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who made the change. + - Inspect `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to establish whether the + change came from an interactive session, automation, or an unfamiliar location. + - Confirm whether a corresponding change request or deployment exists for the affected agent. +- **Examine the change** + - Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.flattened.request_parameters` for the targeted agent + ID, action group definition, Lambda ARN, collaborator, or alias routing configuration. + - For `UpdateAgent`, inspect the modified instruction text for prompt-injection or data-exfiltration intent. + - For action group changes, validate the referenced Lambda function or API schema ownership and intent. + - For alias changes, confirm which agent version the alias now points to. +- **Correlate activity** + - Look for a `PrepareAgent` call following configuration changes, which indicates the tampered config was made live. + - Search for surrounding IAM, Lambda, or STS activity from the same identity that could indicate broader compromise. + + +*False positive analysis* + + +- **Planned development and tuning**: Legitimate developers regularly update agent instructions and action groups. + Validate against change tickets and known engineering activity. +- **Automation**: IaC pipelines and deployment tooling may call these APIs on every release. Exempt known automation + roles if they cause recurring false positives. + + +*Response and remediation* + + +- If the change is unauthorized, revert the agent, action group, collaborator, and alias to a known-good version and + re-run `PrepareAgent` to restore trusted behavior. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review the affected agent's action group Lambda functions and APIs for malicious code or data flows. +- Restrict `bedrock:UpdateAgent`, `bedrock:*AgentActionGroup`, `bedrock:*AgentCollaborator`, `bedrock:*AgentAlias`, and + `bedrock:PrepareAgent` permissions to a small set of administrative roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "UpdateAgent" or + "CreateAgentActionGroup" or + "UpdateAgentActionGroup" or + "AssociateAgentCollaborator" or + "UpdateAgentCollaborator" or + "CreateAgentAlias" or + "UpdateAgentAlias" or + "PrepareAgent" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc new file mode 100644 index 0000000000..0c7683888a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc @@ -0,0 +1,136 @@ +[[aws-bedrock-automated-reasoning-safety-policy-tampering]] +=== AWS Bedrock Automated Reasoning Safety Policy Tampering + +Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/automated-reasoning.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Automated Reasoning Safety Policy Tampering* + + +AWS Bedrock Automated Reasoning policies enforce formal, rule-based validation of model outputs, acting as a +safety control that constrains what a model is permitted to return. Deleting a policy or modifying its +definition or annotations directly weakens this control. Adversaries who have gained access to the Bedrock +control plane may tamper with these policies to evade output-validation defenses, enabling unsafe, manipulated, +or non-compliant model behavior. This detection identifies `DeleteAutomatedReasoningPolicy`, +`UpdateAutomatedReasoningPolicy`, and `UpdateAutomatedReasoningPolicyAnnotations` calls so responders can +confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Determine whether the identity normally administers Bedrock safety policies and whether the action aligns + with an approved change request. +- **Review the specific action** + - For `DeleteAutomatedReasoningPolicy`, identify the deleted policy in + `aws.cloudtrail.flattened.request_parameters` and confirm whether a replacement control exists. + - For `UpdateAutomatedReasoningPolicy` / `UpdateAutomatedReasoningPolicyAnnotations`, inspect + `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to understand what was changed + and whether the change loosens validation constraints. +- **Correlate surrounding activity** + - Look for other Defense Evasion or Bedrock control-plane activity from the same identity in the surrounding + window (model invocation changes, guardrail modifications, logging changes). + - Check `cloud.account.id` and `cloud.region` to scope blast radius across the environment. + + +*False positive analysis* + + +- **Planned policy maintenance**: Governance teams may legitimately tune or retire Automated Reasoning + policies. Validate against change tickets and standard templates. +- **Automation**: IaC or CI/CD pipelines may update policies during deployments. Confirm the actor maps to + known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, restore the prior policy definition or recreate the deleted policy from a + known-good configuration. +- Revoke or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is suspected. +- Review all Bedrock control-plane activity from the same identity in the preceding window for further + defense-impairing actions. +- Restrict `bedrock:DeleteAutomatedReasoningPolicy` and `bedrock:UpdateAutomatedReasoningPolicy*` permissions + to a small set of administrative roles and enforce approval workflows. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "DeleteAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicyAnnotations" + ) and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc new file mode 100644 index 0000000000..a688b84439 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc @@ -0,0 +1,124 @@ +[[aws-bedrock-foundation-model-access-enabled-or-entitlement-granted]] +=== AWS Bedrock Foundation Model Access Enabled or Entitlement Granted + +Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*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 AWS Bedrock Foundation Model Access Enabled or Entitlement Granted* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable. + +This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access. +- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved. +- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise. +- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking). +- Contact the resource owner to confirm whether enabling this model access was planned and authorized. + + +*False positive analysis* + + +- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows. +- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected. + + +*Response and remediation* + + +- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model. +- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs. +- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "success" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc new file mode 100644 index 0000000000..6009b84430 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc @@ -0,0 +1,141 @@ +[[aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key]] +=== AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key + +Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_InvokeModel.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Discovery +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key* + + +This rule fires when the same long-term IAM user access key (AKIA*) calls `ListFoundationModels` and then +invokes a model within 15 minutes. This sequence — enumerate available models, then immediately use one — is +consistent with LLMjacking: an adversary using stolen IAM user credentials to discover and abuse available +AI model capabilities at the account owner's expense. + +Long-term access keys (`AKIA*` prefix) belong to IAM users, not roles. Legitimate Bedrock workloads in +production almost always run under IAM roles with short-lived credentials. A long-term key performing both +model discovery and invocation is unusual and warrants investigation. + + +*Possible investigation steps* + + +- **Identify the key and owner**: Review `aws.cloudtrail.user_identity.arn` and + `aws.cloudtrail.user_identity.access_key_id`. Determine who owns the key and whether it is authorized for + Bedrock usage. +- **Check for credential exposure**: Search for the access key in source code, CI/CD logs, and secret scanning + alerts. A key used from an unexpected source IP is a strong indicator of compromise. +- **Examine the invocation**: Review `aws.cloudtrail.request_parameters` on the `InvokeModel` event to identify + which model was invoked. Cross-reference with Bedrock invocation logs for prompt and response content. +- **Correlate source IP and user agent**: Confirm `source.ip` and `user_agent.original` match the key owner's + expected environment. Residential IPs, VPNs, or unexpected tools are suspicious. +- **Look for volume**: Check whether this is the first invocation or part of a burst of `InvokeModel` calls. + High-volume invocations following enumeration are a strong LLMjacking signal. + + +*False positive analysis* + + +- **Developer testing**: Engineers using long-term IAM user keys for local Bedrock development may trigger this + rule when they first explore available models. Validate against a known developer identity and source IP. + Encourage migration to IAM roles for all Bedrock workloads. + + +*Response and remediation* + + +- Immediately disable or rotate the access key if compromise is suspected. +- Review all Bedrock invocations made by the key before and after this event. +- Check whether the same key accessed other AWS services (S3, EC2, Secrets Manager). +- Enforce IAM roles for all Bedrock workloads and restrict long-term key usage via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by aws.cloudtrail.user_identity.access_key_id with maxspan=15m + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action == "ListFoundationModels" + and event.outcome == "success" + and aws.cloudtrail.user_identity.access_key_id like "AKIA*"] + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action : ("InvokeModel", "InvokeModelWithResponseStream", "Converse", "ConverseStream") + and event.outcome == "success"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrail-deleted-or-weakened.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrail-deleted-or-weakened.asciidoc new file mode 100644 index 0000000000..6a20e17970 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-guardrail-deleted-or-weakened.asciidoc @@ -0,0 +1,127 @@ +[[aws-bedrock-guardrail-deleted-or-weakened]] +=== AWS Bedrock Guardrail Deleted or Weakened + +Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrail Deleted or Weakened* + + +AWS Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model +invocations. Adversaries who gain access to the Bedrock control plane may delete a guardrail (`DeleteGuardrail`), +loosen its policies (`UpdateGuardrail`), remove or overwrite the organization-enforced guardrail +configuration (`DeleteEnforcedGuardrailConfiguration` / `PutEnforcedGuardrailConfiguration`) to then enforce it on +model deployments. This detection identifies those control-plane changes so responders can confirm +intent before accepting the change. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Confirm a related change request exists and that the identity is authorized to manage guardrails. +- **Validate the change** + - For `UpdateGuardrail` / `PutEnforcedGuardrailConfiguration`, inspect + `aws.cloudtrail.flattened.request_parameters` and `aws.cloudtrail.response_elements` to determine + which content, topic, word, or sensitive-information policies were removed or weakened. + - For `DeleteGuardrail` / `DeleteEnforcedGuardrailConfiguration`, identify the targeted guardrail + or org configuration and whether protected workloads still reference it. +- **Correlate activity** + - Look for surrounding Bedrock `InvokeModel` / `Converse` activity and other defense-impairing + actions (e.g., logging or detector changes) from the same identity. + - Check for prior enumeration such as `ListGuardrails` or `GetGuardrail`. + + +*Response and remediation* + + +- If unauthorized, restore the guardrail and/or org-enforced configuration to its approved state and + re-associate it with affected Bedrock workloads. +- Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and review the actor's + recent activity; rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteGuardrail`, `bedrock:UpdateGuardrail`, and the enforced-configuration + permissions to a small set of admin roles, and enforce guardrail state via AWS Config or SCPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "DeleteGuardrail" or + "UpdateGuardrail" or + "DeleteEnforcedGuardrailConfiguration" or + "PutEnforcedGuardrailConfiguration" + ) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc new file mode 100644 index 0000000000..78e0214e33 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc @@ -0,0 +1,183 @@ +[[aws-bedrock-high-frequency-single-model-inference-api-probing]] +=== AWS Bedrock High-Frequency Single-Model Inference API Probing + +Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0024 +* https://atlas.mitre.org/techniques/AML.T0024.000 +* https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Exfiltration +* Mitre Atlas: T0024 +* Mitre Atlas: T0024.000 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing* + + +Membership inference compares many samples against a model to infer whether +specific records were present in training data. Because prompts and responses often appear benign, the +actionable signal is frequently statistical: unusually high inference rates concentrated on one model from +a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, +`InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by +default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is +disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric. + +This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not +as conclusive membership inference detection. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted + `Esql.model_id`. +- Determine whether the call volume exceeds the principal's historical baseline for the same model. +- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance + responses that may indicate membership testing. +- Inspect `source.ip`, `user_agent.original`, and recent IAM activity for signs of compromised credentials + or unexpected automation. +- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse + campaign. + + +*Response and remediation* + + +- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating. +- Enable model invocation logging for content-level review if not already configured. +- If abuse is confirmed, rotate access keys or disable the compromised principal. + + +*Additional information* + + +- For further details on how Amazon Bedrock integrates with AWS CloudTrail to log control plane and data plane runtime operations, see the https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html[AWS Bedrock User Guide on CloudTrail Logging]. +- To explore the adversarial tactics, techniques, and case studies surrounding machine learning model data leakage, consult the https://atlas.mitre.org/techniques/AML.T0024[MITRE ATLAS Exfiltration via Inferences (AML.T0024)] documentation. + + + +==== Setup + + + +*Setup* + + +This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS +integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management +events by default; no Bedrock model invocation logging is required. + + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +// Bedrock runtime inference APIs (CloudTrail management events, logged by default) used to probe at scale +| where + event.provider == "bedrock.amazonaws.com" + and event.action in ( + "InvokeModel", + "Converse", + "ConverseStream", + "InvokeModelWithResponseStream" + ) + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + and aws.cloudtrail.request_parameters IS NOT NULL + +| grok aws.cloudtrail.request_parameters """modelId=(?[^,}\]]+)""" +| where Esql.model_id IS NOT NULL + +// preserve the grouping keys plus the ECS context fields collected via VALUES() below +| keep + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id, + event.action, + source.ip, + user_agent.original, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + cloud.region, + source.as.organization.name + +// aggregate per principal + account + model, capturing analyst context with VALUES() +| stats + Esql.inference_call_count = count(*), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name) + by + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id + +| where Esql.inference_call_count >= 500 + +| keep + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id, + Esql.inference_call_count, + Esql.event_action_values, + Esql.source_ip_values, + Esql.user_agent_original_values, + Esql.aws_cloudtrail_user_identity_type_values, + Esql.aws_cloudtrail_user_identity_access_key_id_values, + Esql.cloud_region_values, + Esql.source_as_organization_name_values + +| sort Esql.inference_call_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc new file mode 100644 index 0000000000..aa79a65070 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc @@ -0,0 +1,154 @@ +[[aws-bedrock-knowledge-base-or-rag-data-source-tampering]] +=== AWS Bedrock Knowledge Base or RAG Data Source Tampering + +Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Knowledge Base or RAG Data Source Tampering* + + +AWS Bedrock knowledge bases provide Retrieval-Augmented Generation (RAG) by grounding model responses in a stored +corpus that is synchronized from a configured data source. Because RAG-enabled applications present these grounded +answers as authoritative, an adversary who can ingest, delete, or repoint the underlying corpus can poison the answers +returned to downstream users and systems. This rule detects control-plane changes to knowledge bases and data sources +that could enable such corpus poisoning. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id`. + - Examine `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to determine whether the + change came from an approved operator, automation, or an unexpected origin. + - Confirm a related change request exists (content update, data source migration, scheduled ingestion). +- **Validate the specific action** + - Inspect `event.action` and `aws.cloudtrail.flattened.request_parameters` to identify the knowledge base, data + source, and any S3 bucket / ingestion configuration referenced. + - For `CreateDataSource` / `UpdateDataSource`, verify the data source location (e.g., S3 bucket) is org-owned and not + attacker-controlled. + - For `IngestKnowledgeBaseDocuments` / `StartIngestionJob`, review what content was ingested and from where. + - For `DeleteKnowledgeBaseDocuments` / `DeleteDataSource`, determine whether legitimate content was removed. +- **Correlate activity** + - Look for prior enumeration of Bedrock resources or anomalous IAM/STS activity from the same identity. + - Review `cloud.account.id` and `cloud.region` to confirm the change occurred where expected. + + +*False positive analysis* + + +- **Planned content maintenance**: Routine ingestion, document updates, and re-syncs by data teams or MLOps automation + are expected. Validate against change tickets and known automation roles. +- **Infrastructure-as-code**: Pipelines may create or update data sources during deployments. Confirm the source IP and + ARN match expected automation. + + +*Response and remediation* + + +- If unauthorized, suspend or disable the implicated knowledge base and data source to prevent further poisoned + retrieval, and revert the corpus to a known-good state. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Audit recent ingestion jobs and document changes, and validate the integrity of the data source location. +- Restrict Bedrock Agent knowledge base and data source mutation permissions to a small set of trusted roles. + + +==== Setup + + + +*Setup* + + +This rule requires the AWS CloudTrail integration. The data source and knowledge base configuration actions are management +events (captured by default), but the direct document operations (`IngestKnowledgeBaseDocuments`, `DeleteKnowledgeBaseDocuments`) +are Bedrock CloudTrail **data events** that are off by default. Without Bedrock data-event logging enabled on the trail, this rule +provides only **partial coverage** — it will see config changes but not direct document ingestion/deletion, the primary poisoning +vector. Enable Bedrock data-event logging for full coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "IngestKnowledgeBaseDocuments" or + "DeleteKnowledgeBaseDocuments" or + "UpdateKnowledgeBase" or + "CreateDataSource" or + "UpdateDataSource" or + "DeleteDataSource" or + "StartIngestionJob" or + "DeleteKnowledgeBase" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc new file mode 100644 index 0000000000..45f71f0cd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc @@ -0,0 +1,128 @@ +[[aws-bedrock-model-invocation-logging-disabled-or-modified]] +=== AWS Bedrock Model Invocation Logging Disabled or Modified + +Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Invocation Logging Disabled or Modified* + + +AWS Bedrock model invocation logging captures the prompts and responses processed by foundation models and delivers them +to an S3 bucket or CloudWatch log group. This data feeds the `logs-aws_bedrock.invocation-*` dataset that all data-plane +Bedrock detections depend on. Deleting the configuration stops this telemetry entirely, while overwriting it with `Put` +can silently redirect logs to a destination the defender does not monitor. Either action effectively blinds the +data-plane detection stack, making this a high-priority defense-evasion event. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved Bedrock administrator and whether a change request exists. +- **Determine the exact action** + - For `DeleteModelInvocationLoggingConfiguration`, logging is being turned off entirely — confirm this is intentional. + - For `PutModelInvocationLoggingConfiguration`, inspect `aws.cloudtrail.flattened.request_parameters` for the new + `s3Config` bucket name / key prefix and `cloudWatchConfig` log group, and verify they are owned and monitored by your org. +- **Correlate surrounding activity** + - Pivot on the same identity, `source.ip`, and `cloud.account.id` for prior enumeration + (`GetModelInvocationLoggingConfiguration`) or follow-on Bedrock data-plane activity (model invocations) that would now + be unlogged. + - Check for parallel logging-tampering against CloudTrail, Config, or GuardDuty. + + +*False positive analysis* + + +- **Planned changes**: Logging migrations or compliance updates may legitimately reconfigure or remove the + configuration. Validate against change tickets and infrastructure-as-code pipelines. + + +*Response and remediation* + + +- If unauthorized, restore model invocation logging to the approved destination and verify log delivery resumes into + `logs-aws_bedrock.invocation-*`. +- Review and secure any attacker-specified S3 bucket or CloudWatch log group, and treat data sent there as exposed. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteModelInvocationLoggingConfiguration` and `bedrock:PutModelInvocationLoggingConfiguration` to a + small set of administrative roles and alert on changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("DeleteModelInvocationLoggingConfiguration" or "PutModelInvocationLoggingConfiguration") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-provisioned-model-throughput-tampering.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-provisioned-model-throughput-tampering.asciidoc new file mode 100644 index 0000000000..a18329bfde --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-provisioned-model-throughput-tampering.asciidoc @@ -0,0 +1,145 @@ +[[aws-bedrock-provisioned-model-throughput-tampering]] +=== AWS Bedrock Provisioned Model Throughput Tampering + +Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateProvisionedModelThroughput.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Provisioned Model Throughput Tampering* + + +Amazon Bedrock Provisioned Throughput reserves dedicated, billed model capacity for foundation models. +Because this capacity is committed and metered, adversaries can abuse it in two ways: scaling capacity up to +incur large, unauthorized cloud spend (resource/bill hijacking), or deleting reserved throughput to deny +service to production workloads that rely on committed capacity. This rule identifies +`CreateProvisionedModelThroughput`, `UpdateProvisionedModelThroughput`, and `DeleteProvisionedModelThroughput` +calls so responders can confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved administrator, ML/platform engineer, or automation role. + - Confirm a corresponding change request or capacity-planning ticket exists. +- **Validate the request details** + - Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` for the model ID, + commitment duration, and requested model units. Unusually large model-unit counts or long commitment + terms on a Create/Update may indicate cost-driven abuse. + - For `DeleteProvisionedModelThroughput`, identify which provisioned model was removed and whether any + production workload depended on it. +- **Correlate activity** + - Review other Bedrock control-plane actions (e.g., model invocation logging changes, guardrail changes) + and IAM/STS activity from the same identity around the same time. + - Check `cloud.account.id` and `cloud.region` for whether the activity occurred in an expected account/region. + + +*False positive analysis* + + +- **Capacity planning**: Platform, ML, or FinOps teams may legitimately create, update, or delete provisioned + throughput. Validate against change tickets and standard capacity-management procedures. +- **Automation**: IaC or deployment pipelines may manage provisioned throughput on bootstrap or teardown. + Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- If unauthorized, immediately disable the offending access key or role and revert the change (delete + unauthorized provisioned throughput, or recreate deleted reserved capacity required by production). +- Review billing and Cost Explorer for unexpected Bedrock provisioned-throughput charges. +- Audit the actor's recent activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:CreateProvisionedModelThroughput`, `bedrock:UpdateProvisionedModelThroughput`, and + `bedrock:DeleteProvisionedModelThroughput` to a small set of administrative roles and enforce approval + workflows and budget alarms. + + +*Additional information* + + +- **https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html[Amazon Bedrock Provisioned Throughput]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "CreateProvisionedModelThroughput" or + "UpdateProvisionedModelThroughput" or + "DeleteProvisionedModelThroughput" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..e0ade8d22c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc @@ -0,0 +1,129 @@ +[[aws-bedrock-resource-based-policy-modified-or-deleted]] +=== AWS Bedrock Resource-Based Policy Modified or Deleted + +Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Resource-Based Policy Modified or Deleted* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. Adversaries can attach a policy that grants an external principal +access for persistence or cross-account access, or delete a policy to break existing access controls. This +rule detects successful `PutResourcePolicy` and `DeleteResourcePolicy` calls against the Bedrock control +plane. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm the identity is expected to manage Bedrock resource policies and that a related change request + exists. +- **Validate the policy change** + - For `PutResourcePolicy`, inspect `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. + - For `DeleteResourcePolicy`, determine which resource lost its policy and whether that resource should + have remained restricted. +- **Correlate activity** + - Look for related Bedrock actions (model invocation, agent updates, knowledge base access) from the same + identity or the newly granted principal. + - Check for prior enumeration of Bedrock resources or other recent IAM/resource-policy changes. + + +*False positive analysis* + + +- **Planned access management**: Legitimate sharing or onboarding may add or remove resource policies. + Validate against change tickets and standard templates. +- **Automation**: IaC or platform pipelines may set or remove resource policies during deployment. Confirm + the actor matches known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, revert the resource policy to its approved state and remove any external + or overly permissive principals. +- Disable or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for further + access grants or persistence. +- Restrict `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy` to administrative roles and + enforce least-privilege resource policies. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "success" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc new file mode 100644 index 0000000000..7e43d987a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc @@ -0,0 +1,126 @@ +[[aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent]] +=== AWS Bedrock Third-Party or External Knowledge Base Associated to Agent + +Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Third-Party or External Knowledge Base Associated to Agent* + + +Amazon Bedrock agents use knowledge bases to retrieve content that is injected into the model's context as +trusted, authoritative information (Retrieval-Augmented Generation). The `AssociateAgentKnowledgeBase`, and +`UpdateAgentKnowledgeBase` actions change which knowledge base an agent trusts. Because the model consumes this +content as ground truth, redirecting an agent toward an externally controlled or attacker-supplied knowledge base +is a supply-chain and indirect prompt-injection delivery vector — distinct from poisoning the content of a knowledge +base the agent already trusts. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, and `source.ip`. + - Confirm a related change request exists (RAG pipeline change, agent onboarding, model improvement work). +- **Validate the association** + - In `aws.cloudtrail.flattened.request_parameters`, identify the `agentId`, `knowledgeBaseId`, and any third-party + or external endpoint/configuration referenced. + - Confirm the knowledge base and its underlying data source are owned by your organization and not an external account. +- **Assess blast radius** + - Determine which applications or users invoke the affected agent and what sensitivity of decisions it drives. + - Check `aws.cloudtrail.flattened.response_elements` for the resulting association state. +- **Correlate activity** + - Look for preceding enumeration (`ListAgents`, `ListKnowledgeBases`, `GetAgent`) or creation of new knowledge + bases and data sources from the same identity. + + +*False positive analysis* + + +- **Planned RAG changes**: ML/platform teams routinely associate or update knowledge bases. Validate via ticket + and confirm the resource is an approved, organization-owned knowledge base. +- **Automation**: IaC or CI/CD pipelines may manage agent–knowledge base associations during deployment. + + +*Response and remediation* + + +- If unauthorized, dissociate the knowledge base from the agent and restore the approved configuration. +- Review the associated knowledge base and its data source for attacker-controlled or external content; quarantine if suspect. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:AssociateAgentKnowledgeBase`, `bedrock:UpdateAgentKnowledgeBase`, and third-party association + permissions to a small set of trusted roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "AssociateAgentKnowledgeBase" or + "UpdateAgentKnowledgeBase" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc new file mode 100644 index 0000000000..98abe20753 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc @@ -0,0 +1,124 @@ +[[aws-bedrock-unauthorized-foundation-model-access-attempt]] +=== AWS Bedrock Unauthorized Foundation Model Access Attempt + +Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*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 AWS Bedrock Unauthorized Foundation Model Access Attempt* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap. +- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted. +- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts. +- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity. + + +*False positive analysis* + + +- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows. +- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "failure" + and aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc new file mode 100644 index 0000000000..1139531140 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc @@ -0,0 +1,133 @@ +[[aws-bedrock-unauthorized-resource-based-policy-modification-attempt]] +=== AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt + +Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy +that grants an external principal access for persistence or cross-account access, or delete a policy to break +existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied +(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform — +a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not +take effect. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an + identity that should never touch these APIs is more suspicious than one from an admin with a transient gap. +- **Assess the attempt** + - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason. + - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. +- **Correlate activity** + - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission + enumeration or escalation attempts. + - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related + resources, and review any IAM changes in the surrounding window. + + +*False positive analysis* + + +- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may + generate transient denials. Validate against change tickets and known automation. +- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and + identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in + `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access + grants, permission changes, or other persistence attempts. +- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied + and successful calls. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "failure" and + aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc new file mode 100644 index 0000000000..bb4f2010c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc @@ -0,0 +1,127 @@ +[[aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered]] +=== AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered + +Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelImportJob.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-import.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered* + + +Amazon Bedrock allows organizations to import custom models, deploy them, and register marketplace model endpoints for inference. Each of these paths introduces a model artifact that did not necessarily originate from the organization's trusted training and approval pipeline. Adversaries who can import a backdoored or poisoned model — or register an untrusted marketplace endpoint — can influence the output of any downstream application that invokes that model, constituting a supply-chain compromise. This detection identifies `CreateModelImportJob`, `CreateCustomModelDeployment`, `CreateMarketplaceModelEndpoint`, and `RegisterMarketplaceModelEndpoint` calls so responders can verify model provenance before the model is trusted for inference. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm whether a related change request or model onboarding ticket exists. + - Determine if the identity is an approved ML/MLOps role or automation principal. +- **Validate the model artifact source** + - In `aws.cloudtrail.flattened.request_parameters`, review the model source location (e.g., the S3 URI for an import job) and confirm the bucket belongs to your organization and is not attacker-controlled. + - For marketplace endpoints, confirm the model package ARN / product corresponds to an approved vendor. +- **Correlate activity** + - Look for subsequent `InvokeModel` / `InvokeModelWithResponseStream` activity targeting the new model or endpoint. + - Check for prior enumeration such as `ListFoundationModels`, `ListCustomModels`, or `ListImportedModels`. + - Review other recent actions by the same identity for signs of broader compromise. + + +*False positive analysis* + +- **Planned model onboarding**: ML teams routinely import models and register endpoints. Validate against a ticket and confirm the artifact source. +- **Automation**: IaC or MLOps pipelines may create these resources during deployment. Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + +- **If unauthorized** + - Delete or disable the imported model, custom model deployment, or marketplace endpoint. + - Prevent downstream applications from invoking the untrusted model until provenance is established. + - Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and rotate credentials if compromise is suspected. + - Audit the S3 source bucket for tampering and review the model artifact for backdoors. +- **Hardening** + - Restrict `bedrock:CreateModelImportJob`, `bedrock:CreateCustomModelDeployment`, and marketplace endpoint creation/registration permissions to approved roles. + - Enforce that model artifacts originate only from organization-owned, controlled S3 locations. + + +*Additional information* + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "CreateModelImportJob" or + "CreateCustomModelDeployment" or + "CreateMarketplaceModelEndpoint" or + "RegisterMarketplaceModelEndpoint" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Implant Internal Image +** ID: T1525 +** Reference URL: https://attack.mitre.org/techniques/T1525/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-kms-imported-key-material-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-kms-imported-key-material-deleted.asciidoc new file mode 100644 index 0000000000..c0490a7fc2 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-kms-imported-key-material-deleted.asciidoc @@ -0,0 +1,124 @@ +[[aws-kms-imported-key-material-deleted]] +=== AWS KMS Imported Key Material Deleted + +Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html +* https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Imported Key Material Deleted* + + +AWS KMS keys can be created with an external key material origin (BYOK), where the customer imports the cryptographic material rather than having KMS generate it. "DeleteImportedKeyMaterial" removes that material, immediately transitioning the key to a "PendingImport" state where it can no longer encrypt or decrypt. All data protected by the key becomes inaccessible until the exact same material is re-imported. Unlike "ScheduleKeyDeletion", there is no pending window, so the impact is instant and, for an adversary who controls and withholds the original material, effectively irreversible. + +Because this action only applies to external-origin keys and is uncommon in normal operations, it should be treated as a high-risk, destructive action when performed unexpectedly. Adversaries may delete imported key material to sabotage recovery, destroy data, or hold encrypted resources for ransom. + + +*Possible investigation steps* + + +- Identify the actor and authentication context in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.access_key_id", and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" to determine whether the action came from an expected network path or automation platform. +- Identify the affected key from "aws.cloudtrail.resources.arn" or the "keyId" in "aws.cloudtrail.request_parameters", and determine which services and data depend on it (S3, EBS, RDS, Secrets Manager, etc.). +- Determine whether the same material was re-imported shortly after ("ImportKeyMaterial") or whether the key was left unusable. +- Correlate with surrounding activity by the same principal, such as KMS key policy changes, scheduled key deletions, S3 or EBS destructive actions, or credential changes that may indicate a broader sabotage or ransom attempt. + + +*False positive analysis* + + +- Organizations with BYOK/HYOK requirements may delete and re-import key material during planned rotation, migration, or decommissioning. Confirm the change is expected and exclude known administration roles or automation on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, re-import the original key material if it is securely retained, and restore access to affected services. +- Treat any encrypted data whose key material cannot be re-imported as potentially unrecoverable, and engage incident response and data owners to assess impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain "kms:DeleteImportedKeyMaterial" and "kms:ImportKeyMaterial" to a small set of trusted administrators. +- Use AWS Organizations SCPs to limit who can manage imported key material in production accounts. + + +*Additional information* + + +- https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html[DeleteImportedKeyMaterial API] +- https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html[Importing key material into AWS KMS keys] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: "DeleteImportedKeyMaterial" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-event-source-mapping-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-event-source-mapping-creation.asciidoc new file mode 100644 index 0000000000..fb7b3e17db --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-event-source-mapping-creation.asciidoc @@ -0,0 +1,135 @@ +[[aws-lambda-event-source-mapping-creation]] +=== AWS Lambda Event Source Mapping Creation + +Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html +* https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Event Source Mapping Creation* + + +AWS Lambda event source mappings poll an event source (Amazon SQS, Kinesis or DynamoDB streams, Amazon MSK or self-managed Kafka, or Amazon MQ) and invoke a target function as records arrive. Creating a mapping is a low-frequency, high-impact configuration change: it can establish event-driven persistence and execution, or quietly relay sensitive records from a stream or queue into attacker-controlled code. + +This rule detects successful `CreateEventSourceMapping` calls. Investigate whether the principal, the target function, and the event source are expected for the environment. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine whether the call came from the console, CLI, SDK, or automation. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`/`functionArn` and the `eventSourceArn` to identify the target function and the source queue, stream, topic, or broker. +- Determine whether the target function and the event source belong to the same application and account, and whether the function code, role, and recent changes are trusted (correlate with `CreateFunction`, `UpdateFunctionCode`, and `AddPermission`). +- Review whether the event source contains sensitive data (for example a DynamoDB stream or SQS queue carrying business records) that the mapping could be used to exfiltrate. +- Pivot on the same principal and access key for other recent Lambda, IAM, or data-plane activity. + + +*False positive analysis* + + +- Event source mappings are a normal building block of serverless data pipelines and queue/stream consumers. Mappings created by approved deployment roles, CI/CD pipelines, or application teams are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the mapping is unauthorized, disable or delete it (`DeleteEventSourceMapping`) and review the target function's code, configuration, and execution role. +- Determine whether records were processed by the function while the mapping was active and assess potential data exposure. +- Rotate or restrict credentials for the principal that created the mapping if compromise is suspected, and constrain `lambda:CreateEventSourceMapping` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html[AWS Lambda event source mappings] +- https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html[CreateEventSourceMapping API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: CreateEventSourceMapping* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-deletion.asciidoc new file mode 100644 index 0000000000..b53609d3cf --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-deletion.asciidoc @@ -0,0 +1,117 @@ +[[aws-lambda-function-deletion]] +=== AWS Lambda Function Deletion + +Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Deletion* + + +Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a backdoor function and erase evidence after their objective is met. + +This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are expected, and whether the deletion correlates with other suspicious activity. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and environment (prod, staging, dev). +- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy operation by comparing `@timestamp` against deployment and change-management records. +- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions. +- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a single planned change. + + +*False positive analysis* + + +- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and confirm its code, configuration, and execution role match a known-good state. +- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html[DeleteFunction API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: (DeleteFunction or DeleteFunction20*) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-by-an-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-by-an-unusual-principal.asciidoc new file mode 100644 index 0000000000..2c6fde944c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-by-an-unusual-principal.asciidoc @@ -0,0 +1,124 @@ +[[aws-lambda-function-invoked-by-an-unusual-principal]] +=== AWS Lambda Function Invoked by an Unusual Principal + +Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked by an Unusual Principal* + + +Most Lambda invocations are driven by event sources (S3, EventBridge, SQS, API Gateway, etc.), which CloudTrail records with `aws.cloudtrail.user_identity.invoked_by` set to the calling service. A principal invoking a function **directly** (via the SDK, CLI, or console) is comparatively rare and, when it comes from an identity that does not normally do so, can indicate lateral movement, credential abuse, or data retrieval from a function. This rule uses a new terms approach to surface the first time a given principal directly invokes a function in an account within the prior 14 days. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify the actor, and `source.ip` / `user_agent.original` to determine how the call was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and sensitivity. +- Determine whether the principal is expected to invoke functions directly and whether the activity aligns with an approved operation, test, or deployment. +- Correlate with recent activity by the same principal or access key, such as credential issuance, role assumption, or other data-plane access, and check whether the credential was recently seen from an unusual source. + + +*False positive analysis* + + +- Direct invocation is a normal operational and testing activity. Confirm whether the principal is a known operator or automation identity and exclude it on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the invocation is unauthorized, review what the function returns and accesses, and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:InvokeFunction` to the identities and services that require it. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and aws.cloudtrail.user_identity.arn: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..4367c9e62b --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc @@ -0,0 +1,126 @@ +[[aws-lambda-function-invoked-from-an-unusual-source-asn]] +=== AWS Lambda Function Invoked from an Unusual Source ASN + +Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked from an Unusual Source ASN* + + +Lambda execution-role credentials and user credentials are frequently abused after theft (for example via SSRF or RCE against a function, or leaked access keys). When such credentials are replayed from attacker infrastructure, the resulting direct `Invoke` calls originate from a network the legitimate principal has not used. This rule uses a new terms approach over the source ASN organization and the principal, excluding common cloud provider networks, to surface invocation from unfamiliar external networks. + + +*Possible investigation steps* + + +- Review `source.ip`, `source.as.organization.name`, and `source.geo` for the invoking network and determine whether it is expected for the principal in `aws.cloudtrail.user_identity.arn`. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and `user_agent.original` for the client used. +- Determine whether the credential (`aws.cloudtrail.user_identity.access_key_id`) was recently seen used elsewhere or outside the Lambda runtime, which would corroborate credential theft. +- Correlate with other activity by the same principal from the same network, including data-plane access, IAM, or STS calls. + + +*False positive analysis* + + +- New legitimate networks (offices, VPNs, home IPs, new egress) will generate this alert. Confirm the principal and network are expected and exclude known operator networks or identities after validation. +- If source ASN is legitimate and expected, add as an exclusion to reduce false-positives. + + +*Response and remediation* + + +- If credential abuse is confirmed, rotate or revoke the affected credentials and execution-role permissions, and review what the invoked function accessed or returned. +- Constrain `lambda:InvokeFunction` to expected identities and, where possible, restrict invocation to known networks using IAM conditions. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). Source +ASN enrichment (`source.as.organization.name`) must be available on the ingested events. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and source.as.organization.name:(* and not (Amazon* or AMAZON* or Google* or GOOGLE* or Microsoft* or MICROSOFT*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc new file mode 100644 index 0000000000..20be0a1ffb --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc @@ -0,0 +1,130 @@ +[[aws-lambda-function-policy-updated-to-allow-cross-account-invocation]] +=== AWS Lambda Function Policy Updated to Allow Cross-Account Invocation + +Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Cross-Account Invocation* + + +AWS Lambda resource policies control which principals may invoke a function. `AddPermission` granting `lambda:InvokeFunction` to a principal in another AWS account creates a cross-account invocation path. Adversaries use this to maintain execution access or to relay function output to infrastructure they control, without changing the function code that defenders typically scrutinize. + +This rule detects grants of invoke permission to a specific external account, excluding public grants (handled by the related public-invocation rule) and AWS service principals used for normal event triggers. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`, the `action` granted, and the `principal` account id receiving access; confirm whether that account is known and trusted. +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the change was made. +- Determine whether the function processes or has access to sensitive data that the external account could now reach. +- Correlate with other activity by the same principal, including function code or configuration changes and additional policy modifications. +- Verify whether the cross-account grant aligns with an approved integration or change request. + + +*False positive analysis* + + +- Multi-account architectures and partner integrations legitimately grant cross-account invoke permissions. Confirm the grant is approved and exclude known trusted account ids or service roles on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the grant is unauthorized, remove the statement from the function's resource policy (`RemovePermission`) and review the function's code, configuration, and execution role. +- Determine whether the external account invoked the function while the grant was in place and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html[Lambda resource-based policies] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html[AddPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and not stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + and not stringContains(aws.cloudtrail.request_parameters, ".amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-url-created-with-public-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-url-created-with-public-access.asciidoc new file mode 100644 index 0000000000..876e0e821f --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-function-url-created-with-public-access.asciidoc @@ -0,0 +1,128 @@ +[[aws-lambda-function-url-created-with-public-access]] +=== AWS Lambda Function URL Created with Public Access + +Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html +* https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function URL Created with Public Access* + + +A Lambda function URL is a dedicated HTTPS endpoint for a function. When configured with `authType=NONE`, anyone on the internet can invoke the function without AWS authentication. Adversaries use this to create a public, persistent entry point for command and control, data exfiltration, or running attacker-controlled code without needing AWS credentials. + +This rule detects successful `CreateFunctionUrlConfig` and `UpdateFunctionUrlConfig` calls where the auth type is set to NONE. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and the auth type, and review `aws.cloudtrail.response_elements` for the resulting `functionUrl`. +- Determine whether the function is intended to be public and whether the owning team requested an unauthenticated endpoint. +- Review the function's code, execution role, and recent changes (`UpdateFunctionCode`, `UpdateFunctionConfiguration`, `AddPermission`) for signs of tampering. +- Correlate with other activity by the same principal, and check the function's invocation and access logs for traffic from unexpected sources after the URL was exposed. + + +*False positive analysis* + + +- Public webhooks, simple APIs, and front-end integrations sometimes use unauthenticated function URLs intentionally. Confirm the exposure is approved and exclude known public endpoints on `functionName` or `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the exposure is unauthorized, change the function URL auth type to `AWS_IAM` or delete the function URL configuration, and review the function code and execution role for compromise. +- Examine invocation logs for unauthenticated requests received while the URL was public and assess potential impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:CreateFunctionUrlConfig` and `lambda:UpdateFunctionUrlConfig` to trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html[Lambda function URLs] +- https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html[Security and auth model for Lambda function URLs] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and (event.action : "CreateFunctionUrlConfig*" or event.action : "UpdateFunctionUrlConfig*") + and stringContains(aws.cloudtrail.request_parameters, "authType=NONE") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lambda-layer-shared-externally.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lambda-layer-shared-externally.asciidoc new file mode 100644 index 0000000000..6c77380212 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-lambda-layer-shared-externally.asciidoc @@ -0,0 +1,127 @@ +[[aws-lambda-layer-shared-externally]] +=== AWS Lambda Layer Shared Externally + +Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Layer Shared Externally* + + +AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. `AddLayerVersionPermission` modifies a layer version's permission policy to allow another AWS account, an organization, or the public (`principal=*`) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer. + +This rule detects successful `AddLayerVersionPermission` calls. Public grants (`principal=*`) are the highest concern; specific cross-account grants should be validated against approved sharing. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `layerName`, version number, `action`, and the granted `principal` (a specific account id, an organization id, or `*` for public). +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the grant was made. +- Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved. +- Identify which functions reference the layer and whether the grant could influence their runtime. +- Correlate with other activity by the same principal, such as layer publication (`PublishLayerVersion`) or function changes. + + +*False positive analysis* + + +- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on `aws.cloudtrail.user_identity.arn` or the layer name after validation. + + +*Response and remediation* + + +- If the sharing is unauthorized, remove the layer permission (`RemoveLayerVersionPermission`) and rotate any secrets that may have been exposed in the layer. +- Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddLayerVersionPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html[AWS Lambda layers] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html[AddLayerVersionPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: AddLayerVersionPermission* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..2d299fa000 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-suspicious-user-agent.asciidoc @@ -0,0 +1,176 @@ +[[azure-ad-graph-access-with-suspicious-user-agent]] +=== Azure AD Graph Access with Suspicious User-Agent + +Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 9m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools +* https://www.sophos.com/en-us/research/tampering-with-conditional-access-policies-using-azure-ad-graph-api +* https://github.com/gerenios/aadinternals + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Suspicious User-Agent* + + +Azure AD Graph (graph.windows.net) is the legacy directory REST API that Microsoft has been retiring for years. +Legitimate first-party traffic against it is dominated by a small set of recognisable user agents (`Microsoft.OData.Client`, +`Microsoft Azure Graph Client Library`, `Microsoft ADO.NET Data Services`, the Azure portal with a Chrome user agent, +and an empty-UA tail from first-party AppIds). Traffic identifying as Python, aiohttp, curl, Go-http-client, or any +of the `*hound` enumeration families is almost always either a developer prototype or adversary tooling. This rule +flags any such request even at a single event, because tooling samples for AAD Graph are inherently low-volume in +normal tenants. + + +*Possible investigation steps* + + +- Confirm the matching user agent. + - `user_agent.original` (e.g., `aiohttp`, `AADInternals`, `curl`, `bav2ropc`). +- Identify the caller and the calling client. + - `user.id` for the caller, `azure.aadgraphactivitylogs.properties.app_id` for the OAuth client. +- Review which directory object types were touched. + - `url.path` (e.g., `/users`, `/policies`, `/servicePrincipals`). +- Check the success / failure pattern. + - `http.response.status_code`. Many 4xx responses suggest permission probing. +- Cross-reference with the API version. + - `azure.aadgraphactivitylogs.properties.api_version`. A non-Microsoft UA combined with `1.6-internal` or `1.61-internal` is a stronger signal of offensive tooling. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the token was obtained. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration (Azure Event Hub). Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and azure.aadgraphactivitylogs.properties.actor_type == "User" + and user_agent.original is not null +| eval Esql.ua_lower = to_lower(user_agent.original) +| where Esql.ua_lower like "*fasthttp*" + or Esql.ua_lower like "*aiohttp*" + or Esql.ua_lower like "*hound*" + or Esql.ua_lower like "*aadinternals*" + or Esql.ua_lower like "*go-http-client*" + or Esql.ua_lower like "python*" + or Esql.ua_lower like "*curl/*" + or Esql.ua_lower like "*okhttp*" + or Esql.ua_lower like "*axios*" + or Esql.ua_lower like "*node-fetch*" + or Esql.ua_lower like "*go-resty*" + or Esql.ua_lower like "*bav2ropc*" + or Esql.ua_lower like "*undici*" +| keep + _id, + _version, + _index, + @timestamp, + user.id, + source.ip, + source.as.organization.name, + user_agent.original, + azure.aadgraphactivitylogs.properties.app_id, + azure.aadgraphactivitylogs.properties.api_version, + url.path, + http.response.status_code, + azure.tenant_id, + Esql.ua_lower + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-unusual-client-and-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-unusual-client-and-user.asciidoc new file mode 100644 index 0000000000..7902e1d3bd --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-access-with-unusual-client-and-user.asciidoc @@ -0,0 +1,152 @@ +[[azure-ad-graph-access-with-unusual-client-and-user]] +=== Azure AD Graph Access with Unusual Client and User + +Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.aadgraphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/secureworks/family-of-client-ids-research +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Unusual Client and User* + + +A (client, user) pair appearing on AAD Graph for the first time in 14 days is a high-signal indicator. Legacy +AAD Graph traffic is dominated by a small set of recognised first-party callers per user; new combinations +suggest one of: + +- A FOCI refresh-token swap landed under a new client identity. +- The user newly consented to (or was phished into consenting to) an OAuth application. +- An adversary is using stolen tokens / credentials under a client identity the user does not normally use. + + +*Possible investigation steps* + + +- Identify the calling client and confirm whether the app is sanctioned. + - `azure.aadgraphactivitylogs.properties.app_id`. Pivot to Azure portal → Enterprise Applications to check whether it is first-party, sanctioned third-party, or unfamiliar. +- Identify the user and check the surrounding auth context. + - `user.id`, then pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user around the same time. Look for unusual sign-in geography, MFA bypass, or risky session signals. +- Review source posture. + - `user_agent.original`, `source.ip`, `source.as.organization.name`. Residential / VPS / anonymising-network egress raises priority. +- Review what was queried. + - `url.path`. Bulk recon or User-collection access via internal API versions raises triage priority. +- Check tenant-wide blast radius for the client. + - Is the same client ID hitting AAD Graph for many other users? That pattern points to large-scale consent abuse rather than a single account compromise. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the client is not a sanctioned application, revoke its OAuth consent. + - `GET /v1.0/oauth2PermissionGrants?$filter=clientId eq '{servicePrincipalId}'`, then `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.aadgraphactivitylogs" and + azure.aadgraphactivitylogs.properties.actor_type : "User" and + azure.aadgraphactivitylogs.properties.app_id: (* and not ( + "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "bb8f18b0-9c38-48c9-a847-e1ef3af0602d" or + "00000006-0000-0ff1-ce00-000000000000" or + "18ed3507-a475-4ccb-b669-d66bc9f2a36e") + ) and user.id:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc new file mode 100644 index 0000000000..f1d80616d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc @@ -0,0 +1,155 @@ +[[azure-ad-graph-high-4xx-error-ratio-from-user]] +=== Azure AD Graph High 4xx Error Ratio from User + +Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://aadinternals.com/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph High 4xx Error Ratio from User* + + +A high 4xx rate on AAD Graph from a single calling identity is consistent with automated permission probing, +recon against endpoints the caller is not authorized for, or a token whose client has been blocked from AAD +Graph. The pattern is structurally distinct from sparse 4xx in first-party traffic. + + +*Possible investigation steps* + + +- Confirm the surge volume and ratio. + - Review `Esql.error_rate` (4xx as a fraction of total) and `Esql.total_calls` to assess the magnitude. +- Identify the caller and calling client. + - `user.id` for the calling identity, `source.ip` for the egress, and `Esql.app_ids` (from `azure.aadgraphactivitylogs.properties.app_id`) for the OAuth client. +- Review which endpoints produced the errors. + - `Esql.sample_paths` captures the distinct `url.path` values that 4xx'd. +- Correlate with successful calls from the same user / source to understand what reached AAD Graph. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source for token-mint context. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user if the surge indicates unauthorized recon. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" +| eval Esql.is_4xx = case( + http.response.status_code >= 400 and + http.response.status_code < 500, 1, 0 + ) +| eval Esql.time_window = date_trunc(2 minutes, @timestamp) +| stats + Esql.total_calls = count(*), + Esql.azure_tenants = values(azure.tenant_id), + Esql.errors = sum(Esql.is_4xx), + Esql.url_path_count = count_distinct(url.path), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.source_ips = values(source.ip), + Esql.source_asn_name = values(source.as.organization.name), + Esql.user_agents = values(user_agent.original), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + source.as.number, + Esql.time_window +| eval Esql.error_rate = round(Esql.errors * 1.0 / Esql.total_calls, 2) +| where + Esql.total_calls > 20 and Esql.errors >= 10 and + Esql.error_rate >= 0.4 and Esql.url_path_count >= 15 +| keep + user.id, + source.as.number, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-potential-enumeration-roadrecon.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-potential-enumeration-roadrecon.asciidoc new file mode 100644 index 0000000000..1fb00f9242 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-ad-graph-potential-enumeration-roadrecon.asciidoc @@ -0,0 +1,207 @@ +[[azure-ad-graph-potential-enumeration-roadrecon]] +=== Azure AD Graph Potential Enumeration (ROADrecon) + +Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/dirkjanm/ROADtools/blob/master/roadrecon/roadtools/roadrecon/gather.py +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Potential Enumeration (ROADrecon)* + + +This is an ES|QL aggregation rule. Alert documents contain summarized fields per burst window: the calling identity, the tenant, and a one-minute bucket. The alert itself is the signal that something resembling ROADrecon's `gather` walk happened against AAD Graph; the actual investigation happens against the raw `logs-azure.aadgraphactivitylogs-*` events for the same identity and window. + + +*Possible investigation steps* + + +- Confirm the burst by filtering raw AAD Graph activity for the alerting user, tenant, and time window. + - Filter `logs-azure.aadgraphactivitylogs-*` on the alerting user, tenant, and burst window. + - ROADrecon's full `gather` walks ~16 directory collections; five or more in a single minute is the structural fingerprint. +- Tool fingerprint: aiohttp UA plus the hardcoded internal API version. + - `user_agent.original` contains `aiohttp`. + - `api_version = 1.61-internal` (hardcoded in `gather.py`, returns internal-only fields like `strongAuthenticationDetail`). + - No first-party Microsoft component identifies as aiohttp or pins `1.61-internal`. +- Calling client + auth method: the typical device-code-flow ROADrecon entrypoint. + - ROADrecon is usually pointed at the Azure CLI client (`04b07795-…`) via the `-c` flag. + - Uses a public-client auth method (no client secret or certificate). +- HTTP shape distinguishes enumeration from operator follow-on. + - `gather` reads only, so GETs dominate. + - A 403/404 tail indicates the identity probing endpoints it lacks permission for. + - PATCH / POST / DELETE in the same burst means the operator did more than enumerate. +- Source posture: residential ISP, generic VPS, or anonymising-network egress raises triage priority. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) via the sign-in correlation ID on each AAD Graph event to land on the originating token-mint. +- Pivot to audit logs (`logs-azure.auditlogs-*`) for any directory writes by the same user near the burst that suggest persistence or modification activity. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + - Check for red team engagement, penetration test, or internal tooling validation. + - Validate against the engagement window and the operator's known source range. + + +*Response and remediation* + + +- Enumerate device registrations created by the user during or around the burst window. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`. + - De-register anything not attributable to a known endpoint via `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Audit OAuth grants and app role assignments the user holds; revoke anything minted from a kit-egress or otherwise suspicious source. + - `GET /v1.0/oauth2PermissionGrants?$filter=principalId eq '{id}'`, revoke via `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. + - `GET /v1.0/users/{id}/appRoleAssignments`, revoke via `DELETE /v1.0/servicePrincipals/{spId}/appRoleAssignedTo/{assignmentId}`. +- Reset the user's password and audit authentication methods added during the window. + - `GET /v1.0/users/{id}/authentication/methods` to list. + - Remove anything unexpected via the method-type-specific endpoint. +- Audit directory writes by the user near the burst and roll back unauthorized changes. + - Query `logs-azure.auditlogs-*` for `Register device`, `Update user`, `User registered security info`, role assignment activity by the same user in the window. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and to_lower(user_agent.original) like "*aiohttp*" + +| eval Esql.target_endpoints = case( + url.path like "*/eligibleRoleAssignments*", "eligibleRoleAssignments", + url.path like "*/roleAssignments*", "roleAssignments", + url.path like "*/users*", "users", + url.path like "*/groups*", "groups", + url.path like "*/servicePrincipals*", "servicePrincipals", + url.path like "*/applications*", "applications", + url.path like "*/devices*", "devices", + url.path like "*/directoryRoles*", "directoryRoles", + url.path like "*/roleDefinitions*", "roleDefinitions", + url.path like "*/administrativeUnits*", "administrativeUnits", + url.path like "*/contacts*", "contacts", + url.path like "*/oauth2PermissionGrants*", "oauth2PermissionGrants", + url.path like "*/authorizationPolicy*", "authorizationPolicy", + url.path like "*/settings*", "settings", + url.path like "*/policies*", "policies", + url.path like "*/tenantDetails*", "tenantDetails", + "other" + ) +| where Esql.target_endpoints != "other" + +| eval Esql.time_window = date_trunc(1 minutes, @timestamp) + +| stats + Esql.request_count = count(*), + Esql.distinct_endpoints = count_distinct(Esql.target_endpoints), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.user_agent = values(user_agent.original), + Esql.http_methods = values(http.request.method), + Esql.status_codes = values(http.response.status_code), + Esql.source_ips = values(source.ip), + Esql.source_asn_orgs = values(source.`as`.organization.name), + Esql.source_countries = values(source.geo.country_name), + Esql.actor_types = values(azure.aadgraphactivitylogs.properties.actor_type), + Esql.client_auth_methods = values(azure.aadgraphactivitylogs.properties.client_auth_method), + Esql.session_ids = values(azure.aadgraphactivitylogs.properties.session_id), + Esql.sign_in_activity_ids = values(azure.aadgraphactivitylogs.properties.sign_in_activity_id), + Esql.scopes = values(azure.aadgraphactivitylogs.properties.scopes), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + azure.tenant_id, + Esql.time_window + +| where Esql.distinct_endpoints >= 5 + +| keep + user.id, + azure.tenant_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-compute-vm-command-executed.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-compute-vm-command-executed.asciidoc index e4a6f012a5..02cd5ab49e 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-compute-vm-command-executed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-compute-vm-command-executed.asciidoc @@ -1,9 +1,9 @@ [[azure-compute-vm-command-executed]] === Azure Compute VM Command Executed -Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run via PowerShell on the VM, which execute as System. Other roles, such as certain Administrator roles may be able to execute commands on a VM as well. +Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. -*Rule type*: query +*Rule type*: new_terms *Rule indices*: @@ -25,16 +25,21 @@ Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machi * https://adsecurity.org/?p=4277 * https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a * https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed *Tags*: * Domain: Cloud +* Domain: Endpoint * Data Source: Azure -* Use Case: Log Auditing +* Data Source: Azure Activity Logs +* Use Case: Threat Detection * Tactic: Execution * Resources: Investigation Guide -*Version*: 108 +*Version*: 109 *Rule authors*: @@ -50,9 +55,6 @@ Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machi *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 Azure Compute VM Command Executed* @@ -63,7 +65,8 @@ Azure Virtual Machines (VMs) allow users to run applications and services in the *Possible investigation steps* -- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name values "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" and "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Identify the VM in question via the `azure.resource.name` field. This can aid with pivoting into endpoint analysis of the commands executed. - Check the event.outcome field to confirm the success of the command execution and gather details about the command executed. - Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM. - Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies. @@ -92,17 +95,20 @@ Azure Virtual Machines (VMs) allow users to run applications and services in the - Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised. - Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future. -==== Setup - - -The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ==== Rule query [source, js] ---------------------------------- -data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" and event.outcome:(Success or success) +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION" + ) and event.outcome:(Success or success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * and + source.as.number: * and + azure.resource.name: * ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/azure-vm-boot-diagnostics-retrieved.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-vm-boot-diagnostics-retrieved.asciidoc new file mode 100644 index 0000000000..146067aced --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-vm-boot-diagnostics-retrieved.asciidoc @@ -0,0 +1,116 @@ +[[azure-vm-boot-diagnostics-retrieved]] +=== Azure VM Boot Diagnostics Retrieved + +Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.microsoft.com/en-us/msrc/blog/2023/08/azure-serial-console-attack-and-defense-part-1 +* https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Boot Diagnostics Retrieved* + + +Retrieving boot diagnostics (`retrieveBootDiagnosticsData/action`) returns SAS URIs to the VM serial console log and a +console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and +sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no +guest footprint, and bypasses NSG/JIT. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. Service principal or + managed identity retrieval is more suspicious than a known support user. +- Review the source: `source.ip`, `source.as.number`, `source.as.organization.name`, `source.geo.country_name`. + Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress. +- Inspect `azure.resource.id` / `azure.resource.name` to identify the target VM. Was the same principal recently granted + access to it, or is this their first interaction? +- Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the + VM or subscription? + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or + other secrets that now require rotation. +- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence. + + +*Response and remediation* + + +- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke + the principal's access if compromised. +- Collect activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION" and + event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..63d409ac22 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc @@ -0,0 +1,138 @@ +[[azure-vm-extension-crud-operation-with-unusual-source-asn]] +=== Azure VM Extension CRUD Operation with Unusual Source ASN + +Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension CRUD Operation with Unusual Source ASN* + + +Azure VM and VM scale set extensions (for example CustomScript, DSC, and AADSSHLoginForLinux) execute on the guest with +high privilege. Creating or updating an extension (`EXTENSIONS/WRITE`) can run attacker-supplied code as SYSTEM or root, +while deleting one (`EXTENSIONS/DELETE`) can remove security tooling or clean up after execution. This rule uses a new +terms approach keyed on the pair (`azure.resource.name`, `source.as.number`), so it fires when a given extension resource +is operated on from a source network that has not been seen managing it within the history window. Well-known Microsoft +AS numbers used by first-party automation are excluded in the query. + + +*Triage checklist* + + +- Identify the source via `source.ip`, `source.as.number`, and `source.as.organization.name`. Operations from cloud + hosting, VPS, or anonymizing networks are more suspicious than known corporate egress. +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. +- Inspect `azure.resource.id` for the target VM/VMSS and `azure.resource.name` for the extension. CustomScript/DSC + extensions and randomly named extensions warrant closer review. +- Determine the operation: WRITE (create/update — code execution) vs DELETE (removal — possible defense evasion or + cleanup). +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the operation timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the extension settings/protected settings from the VM (the activity log does not contain the script body) to + assess intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following the operation. + + +*Response and remediation* + + +- If unauthorized, remove the malicious extension, isolate the VM, rotate credentials reachable from it, and review RBAC + on the affected scope. +- Block or investigate the source AS/network if it is not an expected management path. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/WRITE" + ) and event.outcome:(Success or success) and + azure.resource.name:* and + source.as.number:(* and not (3598 or 8068 or 8069 or 8070 or 8071 or 8072 or 8073 or 8074 or 8075 or 12076)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc new file mode 100644 index 0000000000..256bb5b154 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc @@ -0,0 +1,121 @@ +[[azure-vm-managed-run-command-created-or-updated-with-unusual-principal]] +=== Azure VM Managed Run Command Created or Updated with Unusual Principal + +Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Managed Run Command Created or Updated with Unusual Principal* + + +The managed Run Command (`runCommands/write`) creates or updates a persistent run command resource on a VM or VM scale +set. Creating the resource executes the supplied script as SYSTEM (Windows) or root (Linux). This rule uses a new terms +approach keyed on the acting principal, so it fires the first time a given identity performs this operation within the +history window. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal or + managed identity activity is more suspicious than a known admin user. +- Is the source IP/ASN consistent with corporate infrastructure or a known VPN? +- Inspect `azure.resource.id` for the target VM/VMSS and the run command resource name. Attacker-created names are often + random or descriptive of intent. +- Did the same principal recently perform reconnaissance, role assignments, or other VM operations + (`runCommand/action`, `extensions/write`, serial console connect)? +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the write timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the run command script content from the VM (the activity log does not contain the script body) to assess + intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following execution. + + +*Response and remediation* + + +- If unauthorized, delete the managed run command resource, isolate the VM, rotate credentials reachable from it, and + review RBAC on the affected scope. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMANDS/WRITE" + ) and event.outcome:(success or Success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..6445ec4c4e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,137 @@ +[[azure-vm-serial-console-connection-with-unusual-user-and-asn]] +=== Azure VM Serial Console Connection with Unusual User and ASN + +Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-overview +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Serial Console Connection with Unusual User and ASN* + + +The Azure Serial Console gives text-based console access to a VM over the boot diagnostics serial port. It works even +when the VM has no inbound network connectivity, so a session bypasses NSGs, JIT, and other network controls. This rule +flags successful `MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION` operations where the combination of acting +principal and source ASN has not been seen in the history window. + +This rule uses a new terms approach keyed on the acting principal and source ASN, so it surfaces a +known identity connecting from an unusual network as well as any new identity using the Serial Console. + + +*Triage checklist* + + +- Identify the caller via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal + Serial Console access is unusual and warrants scrutiny. +- Review `source.as.organization.name`, `source.as.number`, and `source.geo.country_name` - is the network a known + corporate/VPN ASN or an unexpected hosting/residential provider? +- Was the connect preceded by reconnaissance, role assignment changes, or Run Command / extension activity on the same VM? +- Were there preceding failed Serial Console connect attempts (`event.outcome:failure`) suggesting access probing? +- Does the target VM normally require Serial Console access, or is it a production system that should be reachable over + the network? + + +*Possible investigation steps* + + +- Review `azure.resource.id` to identify the VM and confirm boot diagnostics is enabled. +- Correlate with Entra ID sign-in logs for the caller and review MFA / conditional access posture. +- Pivot on the VM for endpoint telemetry around the connect timestamp (interactive shell, new local accounts, credential + access) since Serial Console sessions execute as SYSTEM/root. +- Review the principal's RBAC role assignments on the subscription, resource group, and VM. + + +*Response and remediation* + + +- If unauthorized, terminate the session, rotate credentials reachable from the VM, and review RBAC on the affected scope. +- Consider disabling the subscription-level Serial Console where it is not operationally required. +- Isolate the VM and collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:"MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION" and + event.outcome:("success" or "Success") and + azure.activitylogs.identity.authorization.evidence.principal_id:* and + source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Sub-technique: +** Name: Direct Cloud VM Connections +** ID: T1021.008 +** Reference URL: https://attack.mitre.org/techniques/T1021/008/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc new file mode 100644 index 0000000000..ba08e30b4e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-linux-restricted-shell-breakout-via-linux-binary-s.asciidoc @@ -0,0 +1,254 @@ +[[deprecated-linux-restricted-shell-breakout-via-linux-binary-s]] +=== Deprecated - Linux Restricted Shell Breakout via Linux Binary(s) + +Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/apt/ +* https://gtfobins.github.io/gtfobins/apt-get/ +* https://gtfobins.github.io/gtfobins/nawk/ +* https://gtfobins.github.io/gtfobins/mawk/ +* https://gtfobins.github.io/gtfobins/awk/ +* https://gtfobins.github.io/gtfobins/gawk/ +* https://gtfobins.github.io/gtfobins/busybox/ +* https://gtfobins.github.io/gtfobins/c89/ +* https://gtfobins.github.io/gtfobins/c99/ +* https://gtfobins.github.io/gtfobins/cpulimit/ +* https://gtfobins.github.io/gtfobins/crash/ +* https://gtfobins.github.io/gtfobins/env/ +* https://gtfobins.github.io/gtfobins/expect/ +* https://gtfobins.github.io/gtfobins/find/ +* https://gtfobins.github.io/gtfobins/flock/ +* https://gtfobins.github.io/gtfobins/gcc/ +* https://gtfobins.github.io/gtfobins/mysql/ +* https://gtfobins.github.io/gtfobins/nice/ +* https://gtfobins.github.io/gtfobins/ssh/ +* https://gtfobins.github.io/gtfobins/vi/ +* https://gtfobins.github.io/gtfobins/vim/ +* https://gtfobins.github.io/gtfobins/capsh/ +* https://gtfobins.github.io/gtfobins/byebug/ +* https://gtfobins.github.io/gtfobins/git/ +* https://gtfobins.github.io/gtfobins/ftp/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - Linux Restricted Shell Breakout via Linux Binary(s)* + +Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or +environments by spawning an interactive system shell. +Here are some possible avenues of investigation: +- Examine the entry point to the host and user in action via the Analyse View. + - Identify the session entry leader and session user +- Examine the contents of session leading to the abuse via the Session View. + - Examine the command execution pattern in the session, which may lead to suspricous activities +- Examine the execution of commands in the spawned shell. + - Identify imment threat to the system from the executed commands + - Take necessary incident response actions to contain any malicious behviour caused via this execution. + + +*Related rules* + + +- A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences. +- Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment + + +*Response and remediation* + + +Initiate the incident response process based on the outcome of the triage. + +- If the triage releaved suspicious netwrok activity from the malicious spawned shell, + - Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware execution via the maliciously spawned shell, + - Search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- If the triage revelaed defence evasion for imparing defenses + - Isolate the involved host to prevent further post-compromise behavior. + - Identified the disabled security guard components on the host and take necessary steps in renebaling the same. + - If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same. +- If the triage revelaed addition of persistence mechanism exploit like auto start scripts + - Isolate further login to the systems that can initae auto start scripts. + - Identify the auto start scripts and disable and remove the same from the systems +- If the triage revealed data crawling or data export via remote copy + - Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling + - Intiate compromised credential deactivation and credential rotation process for all exposed crednetials. + - Investiagte if any IPR data was accessed during the data crawling and take appropriate actions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. + +*To confirm that Session View data is enabled:* + +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and process.executable != null and +( + /* launching shell from capsh */ + (process.name == "capsh" and process.args == "--" and not process.parent.executable == "/usr/bin/log4j-cve-2021-44228-hotpatch") or + + /* launching shells from unusual parents or parent+arg combos */ + (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or + (process.parent.name == "git" and process.parent.args : ("!*sh", "exec *sh") and not process.name == "ssh" ) or + (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and + ( + process.parent.args : "BEGIN {system(*)}" or + ( + (process.parent.args : "exec=*sh" or (process.parent.args : "-I" and process.parent.args : "*sh")) or + (process.args : "exec=*sh" or (process.args : "-I" and process.args : "*sh")) + ) + ) + ) or + + /* shells specified in parent args */ + /* nice rule is broken in 8.2 */ + (process.parent.args : "*sh" and + ( + (process.parent.name == "nice") or + (process.parent.name == "cpulimit" and process.parent.args == "-f") or + (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and + process.parent.args == ";" and process.parent.args : "/bin/*sh") or + (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/") + ) + ) + )) or + + /* shells specified in args */ + (process.args : "*sh" and ( + (process.parent.name == "crash" and process.parent.args == "-h") or + (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog") + /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */ + + )) or + (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not + process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and + process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs" and + not process.parent.executable == "/bin/busybox") or + (process.name == "env" and process.args_count == 2 and process.args : "*sh") or + (process.parent.name in ("vi", "vim") and process.parent.args == "-c" and process.parent.args : ":!*sh") or + (process.parent.name in ("c89", "c99", "gcc") and process.parent.args : "*sh,-s" and process.parent.args == "-wrapper") or + (process.parent.name == "expect" and process.parent.args == "-c" and process.parent.args : "spawn *sh;interact") or + (process.parent.name == "mysql" and process.parent.args == "-e" and process.parent.args : "\\!*sh") or + (process.parent.name == "ssh" and process.parent.args == "-o" and process.parent.args : "ProxyCommand=;*sh 0<&2 1>&2") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-mfa-disabled-for-google-workspace-organization.asciidoc new file mode 100644 index 0000000000..8874c4a3f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-mfa-disabled-for-google-workspace-organization.asciidoc @@ -0,0 +1,144 @@ +[[deprecated-mfa-disabled-for-google-workspace-organization]] +=== Deprecated - MFA Disabled for Google Workspace Organization + +Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/7061566 +* 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: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - MFA Disabled for Google Workspace Organization* + + +Multi-factor authentication (MFA) is a process in which users are prompted for an additional form of identification, such as a code on their cell phone or a fingerprint scan, during the sign-in process. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the users's password is weak or has been exposed elsewhere, an attacker could use it to gain access. Requiring a second form of authentication increases security because attackers cannot easily obtain or duplicate the additional authentication factor. + +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197[official documentation]. + +This rule identifies when MFA enforcement is turned off in Google Workspace. This modification weakens account security and can lead to accounts and other assets being compromised. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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. +- Reactivate the multi-factor authentication enforcement. +- Review the permissions assigned to the implicated user 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.provider:admin and event.category:iam and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc index 3ffecfbd73..7f75ff64b1 100644 --- a/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc @@ -1,14 +1,14 @@ [[domain-added-to-google-workspace-trusted-domains]] === Domain Added to Google Workspace Trusted Domains -Detects when a domain is added to the list of trusted Google Workspace domains. An adversary may add a trusted domain in order to collect and exfiltrate data from their target’s organization with less restrictive security controls. +Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. *Rule type*: query *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: high @@ -34,7 +34,7 @@ Detects when a domain is added to the list of trusted Google Workspace domains. * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,36 +54,53 @@ Detects when a domain is added to the list of trusted Google Workspace domains. *Investigating Domain Added to Google Workspace Trusted Domains* -Organizations use trusted domains in Google Workspace to give external users access to resources. +Google Workspace allowlisted domains define which external organizations users may collaborate with across services such +as Drive, Chat, and Classroom. Adding a domain to this list expands who can receive shared content under the tenant's +trust policies. Threat actors with administrative access may add a domain they operate to bypass out-of-domain sharing +controls and establish a durable path for collection or exfiltration. -A threat actor with administrative privileges may be able to add a malicious domain to the trusted domain list. Based on the configuration, potentially sensitive resources may be exposed or accessible by an unintended third-party. - -This rule detects when a third-party domain is added to the list of trusted domains in Google Workspace. +This rule identifies when an administrator adds a domain via the `ADD_TRUSTED_DOMAINS` event in the +`google_workspace.admin` data stream. *Possible investigation steps* -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- After identifying the user, verify if the user should have administrative privileges to add external domains. -- Check the `google_workspace.admin.domain.name` field to find the newly added domain. -- Use reputational services, such as VirusTotal, for the trusted domain's third-party intelligence reputation. -- Filter your data. Create a filter where `event.dataset` is `google_workspace.drive` and `google_workspace.drive.file.owner.email` is being compared to `user.email`. - - If mismatches are identified, this could indicate access from an external Google Workspace domain. +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert. +- Identify the domain added by reviewing `google_workspace.admin.domain.name`. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or partner onboarding record for the new domain. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Review allowlisted domains in the Google Admin console: + - Navigate to Account > Domains > Allowlisted domains. + - Confirm the domain from `google_workspace.admin.domain.name` appears on the list and whether it is appropriate for your organization's sharing model. +- Assess domain reputation and ownership using external intelligence (for example, VirusTotal or WHOIS) to determine whether the domain is associated with your organization or a known partner. +- Search Kibana for related admin and sharing activity: + - Find other trust or sharing policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ADD_TRUSTED_DOMAINS" or "REMOVE_TRUSTED_DOMAINS") + ``` + - After the add, review Drive events for files shared to users outside your domain: + ``` + data_stream.dataset: "google_workspace.drive" and event.action: ("change_user_access" or "change_document_visibility") + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours. *False positive analysis* -- Verify that the user account should have administrative privileges that allow them to edit trusted domains in Google Workspace. -- Talk to the user to evaluate why they added the third-party domain and if the domain has confidentiality risks. +- Verify the domain belongs to an approved partner or subsidiary with a documented business need for cross-organization collaboration. +- Adding test or lab domains during migrations is possible — validate timing against change windows. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. +- Initiate the incident response process based on triage findings. +- If the add is not clearly authorized, remove the domain from Allowlisted domains while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Review recent Drive and Chat sharing to external users for sensitive data exposure tied to the newly trusted domain. - 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. @@ -91,7 +108,7 @@ This rule detects when a third-party domain is added to the list of trusted doma - 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 user to ensure that the least privilege principle is being followed. +- 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). @@ -119,7 +136,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:ADD_TRUSTED_DOMAINS +data_stream.dataset:google_workspace.admin and event.action:ADD_TRUSTED_DOMAINS ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-guest-account-promoted-to-member.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-guest-account-promoted-to-member.asciidoc new file mode 100644 index 0000000000..20b57943d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-guest-account-promoted-to-member.asciidoc @@ -0,0 +1,114 @@ +[[entra-id-guest-account-promoted-to-member]] +=== Entra ID Guest Account Promoted to Member + +Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/external-id/user-properties +* https://learn.microsoft.com/en-us/entra/identity/users/convert-external-users-internal + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Guest Account Promoted to Member* + + +A Guest-to-Member UserType conversion is a rarely needed, high-impact operation that removes all +guest account restrictions. In most tenants it occurs fewer than once per month. + + +*Possible investigation steps* + + +- Identify the administrator who performed the conversion (`azure.auditlogs.properties.initiated_by`) + and verify whether the action was authorized. +- Check when the guest account was originally invited: look for "Invite external user" in AuditLogs + with the same target object ID. +- Review post-conversion sign-in activity in `azure.signinlogs.*` for the target account -- look for + directory enumeration patterns (access to Graph API `/users`, `/groups`, `/applications`). +- Check whether the converting actor's role was recently granted and whether other high-privilege + operations were performed around the same time. + + +*False positive analysis* + + +- Planned B2B-to-member migrations coordinated by HR or IT should be documented in change records. + Confirm via ticket correlation before closing. + + +*Response and remediation* + + +- Revert the UserType to Guest if unauthorized: Entra ID > Users > Edit properties. +- Revoke all sessions for the affected account. +- Review all directory objects the account accessed after the conversion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update user" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "UserType" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value: *Guest* and +azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: *Member* and +event.outcome: (Success or success) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc new file mode 100644 index 0000000000..c4f7fa5539 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc @@ -0,0 +1,146 @@ +[[entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn]] +=== Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN + +Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.app_display_name`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, +`source.as.number`, `source.as.organization.name`, and `user_agent.original`. + +Confirm whether the user intentionally registered or joined a device and whether the source ASN is expected for your +enrollment or remote-access programs. + + +*Possible investigation steps* + + +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins for the same user, especially multi-IP OAuth + flows or follow-on primary refresh token usage. +- Review Entra ID audit logs for device registration activity around the same timestamp. +- Compare `source.as.organization.name` against approved VPN, MDM, and automation egress in your environment. +- Hunt for additional users signing in from the same ASN with the same application pair in a short window. + + +*False positive analysis* + + +- Corporate or consumer VPN exit nodes that use ASNs in the rule list are a common source of benign matches during + standard Windows or mobile device join. +- Cloud hosting or ISP NAT pools may intermittently map to listed ASNs without indicating compromise. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, disable suspicious registered devices, and reset credentials per + policy. +- Review conditional access for the Microsoft Authentication Broker and device registration requirements. +- Escalate per incident procedures when paired with identity protection alerts or impossible travel. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and +source.as.number:( + 399629 or 14061 or 136787 or 9009 or 45102 or 215540 or 29802 or 62240 or 204957 or 395092 or 393406 or 400940 or + 59711 or 132203 +) and +azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" and +azure.signinlogs.properties.resource_display_name:"Device Registration Service" + +---------------------------------- + +*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: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-application-redirect-uri-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-application-redirect-uri-modified.asciidoc new file mode 100644 index 0000000000..947ce70cc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-application-redirect-uri-modified.asciidoc @@ -0,0 +1,127 @@ +[[entra-id-oauth-application-redirect-uri-modified]] +=== Entra ID OAuth Application Redirect URI Modified + +Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity-platform/reply-url +* https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Application Redirect URI Modified* + + +A redirect URI addition to an existing trusted application does not generate a consent event and does +not require registering a new application -- both of which are commonly monitored. The modified +application retains all existing user consents. + + +*Possible investigation steps* + + +- Identify the actor who modified the application (`azure.auditlogs.properties.initiated_by`) and + verify whether the change was authorized by the application owner or a change management ticket. +- Review the specific URIs added by comparing `modifiedProperties.oldValue` and `newValue` for the + `ReplyUrls` field in the audit event's `target_resources`. +- Geolocate and WHOIS the domain of any newly added URI -- hosting providers, recently registered + domains, or URL shorteners are strong indicators of compromise. +- Check whether the actor recently became an owner of this application: look for + "Add owner to application" events in AuditLogs for the same application object ID. +- Review the application's Graph API permissions -- applications with Mail, Files, or directory + scopes are the highest-value targets for redirect URI hijacking. + + +*False positive analysis* + + +- Localhost and loopback URIs (`http://localhost:*`, `http://127.0.0.1:*`) added by developers are + expected in non-production applications. Verify the application's sensitivity before closing. +- CI/CD-driven URI updates typically originate from service principal actors, not human users. + + +*Response and remediation* + + +- Remove the unauthorized redirect URI via Entra ID > App registrations > Authentication. +- Revoke all tokens issued to the application since the modification timestamp. +- Review sign-in logs for the application for any sign-ins from unexpected sources after the change. +- If the URI was externally controlled, treat as a full OAuth token compromise for all users of + the application and initiate token revocation and user notification. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update application" and +event.outcome: ("Success" or "success") and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "AppAddress" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc new file mode 100644 index 0000000000..4ada57d303 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc @@ -0,0 +1,201 @@ +[[entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration]] +=== Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration + +Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.aadgraphactivitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/Gerenios/AADInternals +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration* + + +Device-code phishing redeems an OAuth access token directly into the adversary's hands without +ever touching the victim's password or MFA factor. When the redemption targets the legacy AAD +Graph audience from an unmanaged device, the resulting token is overwhelmingly used to drive +directory recon under the compromised identity. ROADrecon / ROADtools, AADInternals +(`Get-AADIntTenantDetails`, `Get-AADIntUsers`), and manual `roadtx` flows all match this shape. + + +*Possible investigation steps* + + +- Confirm the sign-in shape. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - `azure.signinlogs.properties.resource_id` is `00000002-0000-0000-c000-000000000000` (legacy AAD Graph audience). + - `azure.signinlogs.properties.device_detail.is_managed` is `false`. +- Identify the calling client used to drive the device-code grant. + - `azure.signinlogs.properties.app_id`, `azure.signinlogs.properties.app_display_name`. + - FOCI / pre-consented Microsoft clients (Teams, Office, Azure CLI, Azure PowerShell) are the canonical ride-along clients for device-code phishing because they bypass app consent. +- Review source posture for the redemption and the Graph follow-on independently. + - `source.ip`, `source.as.organization.name`, `source.geo.country_name`. Residential / VPS / anonymising-network egress raises priority. + - A code redeemed from one IP and Graph driven from another is a strong adversary-in-the-middle signal: the user clicked, the attacker is now driving the session. +- Review what was queried on the Graph side. + - `url.path` on the second event. `applicationRefs`, `eligibleRoleAssignments`, and `directoryObjects` casts (`$/Microsoft.DirectoryServices.ServicePrincipal`) are the textbook ROADrecon signature; `tenantDetails` from an `AADInternals` user-agent is the AADInternals signature. +- Check the API version on the Graph call. + - `azure.aadgraphactivitylogs.properties.api_version`. `1.61-internal` is a strong tooling indicator and returns data the public surface withholds (Conditional Access policies, MFA configuration on user objects). +- Pivot to surrounding sign-ins for the same user. Other device-code redemptions to Microsoft Graph, Azure Resource Manager, or Exchange in the same window suggest the attacker is multi-homing the token harvest. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the compromised user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the device-code grant: require a managed / compliant device or block the device-code grant outside of explicitly approved app + user populations. + + +==== Setup + + + +*Microsoft Entra ID Sign-in Logs and Azure AD Graph Activity Logs* + +Requires both data streams ingested via the Elastic Azure integration: +- Microsoft Entra ID sign-in logs into `logs-azure.signinlogs-*` (enable the `SignInLogs` diagnostic-settings category on Entra ID). +- Azure AD Graph Activity Logs into `logs-azure.aadgraphactivitylogs-*` (enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.id, azure.tenant_id with maxspan=5m +[authentication where + data_stream.dataset == "azure.signinlogs" and + event.outcome == "success" and + azure.signinlogs.properties.authentication_protocol == "deviceCode" and + azure.signinlogs.properties.device_detail.is_managed == false and + azure.signinlogs.properties.resource_id == "00000002-0000-0000-c000-000000000000"] +[web where + data_stream.dataset == "azure.aadgraphactivitylogs" and + url.path : ( + "*/users*", + "*/groups*", + "*/servicePrincipals*", + "*/applications*", + "*/applicationRefs*", + "*/devices*", + "*/directoryRoles*", + "*/roleAssignments*", + "*/eligibleRoleAssignments*", + "*/roleDefinitions*", + "*/directoryObjects*", + "*/policies*", + "*/oauth2PermissionGrants*", + "*/administrativeUnits*", + "*/tenantDetails*", + "*/directorySettingTemplates*", + "*/me*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-temporary-access-pass-created-for-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-temporary-access-pass-created-for-user.asciidoc new file mode 100644 index 0000000000..e39f366e9a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-temporary-access-pass-created-for-user.asciidoc @@ -0,0 +1,141 @@ +[[entra-id-temporary-access-pass-created-for-user]] +=== Entra ID Temporary Access Pass Created for User + +Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass +* https://dirkjanm.io/lateral-movement-and-hash-dumping-with-temporary-access-passes-microsoft-entra/ +* https://specterops.io/blog/2023/03/29/id-tap-that-pass/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Temporary Access Pass Created for User* + + +A Temporary Access Pass is a time-limited credential that bypasses all existing MFA factors for the +target account. In a steady-state tenant, TAP creation is rare and should be correlated against help +desk records or onboarding workflows. + + +*Possible investigation steps* + + +- Identify the administrator who created the TAP (`azure.auditlogs.properties.initiated_by`) and verify + whether the action was authorized by a help desk ticket or change management record. +- Identify the target account and assess its privilege level -- TAPs issued for Global Administrators, + Application Administrators, or accounts with high-value data access are highest risk. +- Check for sign-ins by the target account using the TAP credential: look for sign-ins where + `azure.signinlogs.properties.authentication_details` contains "Temporary Access Pass" shortly after + the TAP creation event. +- If the TAP was used to sign in, review what authentication methods were registered during or after + the session -- an attacker will use the TAP window to add a persistent authenticator. +- Check whether the creating administrator's account shows anomalous activity in the preceding 24 hours. + + +*False positive analysis* + + +- TAP creation by your identity team for locked-out users is a legitimate workflow. Confirm via help + desk ticket correlation. +- New employee onboarding that provisions TAPs as part of passwordless enrollment is expected behavior. + + +*Response and remediation* + + +- Revoke the TAP immediately if unauthorized: Entra ID > Users > Authentication methods. +- Audit all authentication methods registered by the target account after TAP creation and remove any + that were not previously present. +- Reset the target account's password and revoke all active sessions. +- Review the creating administrator's recent actions for signs of compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +( + ( + azure.auditlogs.operation_name: "User registered security info" and + azure.auditlogs.properties.result_reason: "User registered temporary access pass method" + ) or ( + azure.auditlogs.operation_name: "Create Temporary Access Pass method for user" + ) or ( + azure.auditlogs.operation_name: "Admin registered security info" and + azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: *TemporaryAccessPass* + ) +) and +event.outcome: ("Success" or "success") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc index c9d452d268..20ab54b23b 100644 --- a/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -1,14 +1,13 @@ [[first-time-seen-google-workspace-oauth-login-from-third-party-application]] === First Time Seen Google Workspace OAuth Login from Third-Party Application -Detects the first time a third-party application logs in and authenticated with OAuth. OAuth is used to grant permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges. +Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. *Rule type*: new_terms *Rule indices*: -* filebeat-* -* logs-google_workspace* +* logs-google_workspace.token-* *Severity*: medium @@ -33,9 +32,10 @@ Detects the first time a third-party application logs in and authenticated with * Data Source: Google Workspace * Tactic: Defense Evasion * Tactic: Initial Access +* Tactic: Persistence * Resources: Investigation Guide -*Version*: 11 +*Version*: 12 *Rule authors*: @@ -51,46 +51,66 @@ Detects the first time a third-party application logs in and authenticated with *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 First Time Seen Google Workspace OAuth Login from Third-Party Application* -OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation. +Threat actors may trick users into authorizing adversary-controlled OAuth applications after credential theft, AiTM +relay, or spearphishing. A successful `authorize` grant issues tokens the application can reuse to act on behalf of the +user. Novel third-party client IDs are a strong signal as malicious consent often appears as a first-time application in the tenant. + +This rule uses `new_terms` to flag the first appearance of a `google_workspace.token.client.id` when +a user grants at least one identity or sign-in scope in `google_workspace.token.scope.value` (for example `openid`, +`userinfo.email`, `userinfo.profile`, or `OAuthLogin`). *Possible investigation steps* -- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field. -- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage. -- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity. -- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies. -- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists. -- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources. +- Identify the user who authorized the application by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert. +- Identify the application by reviewing `google_workspace.token.app_name` and `google_workspace.token.client.id`. +- Review granted scopes in `google_workspace.token.scope.value` to determine whether the app received identity-only access or additional permissions (for example calendar, drive, or mail scopes on the same grant). +- Determine whether the authorization is expected and authorized: + - If `source.ip` or timing is unusual for the user, treat the alert as higher priority until proven benign.' + +- Search Kibana for related activity: + - Find prior authorizations for the same client in the org: + ``` + data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "" + ``` + - Correlate with sign-in anomalies for the same user: + ``` + data_stream.dataset: "google_workspace.login" and user.email: "" + ``` + - Scope for other OAuth or admin changes from the same `user.email` within the last 48 hours. *False positive analysis* -- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts. -- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates. -- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts. -- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives. +- Internal development or QA OAuth clients may appear as new `client.id` values during testing; coordinate with engineering teams and exclude known test clients if needed. +- Some vendors rotate OAuth client IDs during major upgrades, which can look like a new application, confirm with the vendor or IT owner before closing as benign. *Response and remediation* -- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access. -- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred. -- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used. -- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. -- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity. -- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration. -- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services. +- Initiate the incident response process based on triage findings. +- If the authorization is not clearly authorized, revoke the application's access for the affected user under Security > Access and data control > API controls (or remove the user token via admin OAuth reports). +- If the user account is suspected compromised, reset credentials, revoke active sessions, and review all OAuth grants for that user. +- Review activity performed with the new token (Drive, Gmail, Calendar, or other services implied by `google_workspace.token.scope.value`). +- 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 user 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). + @@ -98,11 +118,9 @@ OAuth is a protocol that allows third-party applications to access user data wit - 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 @@ -114,8 +132,10 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset: "google_workspace.token" and event.action: "authorize" and -google_workspace.token.scope.data: *Login and google_workspace.token.client.id: *apps.googleusercontent.com +data_stream.dataset: "google_workspace.token" + and event.action: "authorize" + and google_workspace.token.scope.value: (*openid* or *userinfo.email* or *userinfo.profile* or *Login*) + and google_workspace.token.client.id: *apps.googleusercontent.com ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled-by-user.asciidoc new file mode 100644 index 0000000000..15373f92d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled-by-user.asciidoc @@ -0,0 +1,162 @@ +[[google-workspace-2sv-policy-disabled-by-user]] +=== Google Workspace 2SV Policy Disabled By User + +Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.login-* +* logs-google_workspace.user_accounts-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-190m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?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*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace 2SV Policy Disabled By User* + + +Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove +the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can +support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is +especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions. + +In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user +notices, making it easier to re-enter the account later using stolen credentials alone. + +This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in +both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by +`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested. + + +*Possible investigation steps* + + +- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources. +- Determine whether the disable is expected or unauthorized: + - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement). + - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign. +- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert: + - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts` + - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login` + - OAuth activity in `google_workspace.token` if token abuse is suspected +- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled. + + +*False positive analysis* + + +- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds. +- 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. +- Review the permissions assigned to the implicated user 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 190 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. +- 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) for Filebeat and 3 hours for the Fleet Integration `login` datastream. 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.login" or "google_workspace.user_accounts") and event.action:"2sv_disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc new file mode 100644 index 0000000000..b300e11cca --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc @@ -0,0 +1,163 @@ +[[google-workspace-admin-role-assigned-to-a-user-or-group]] +=== Google Workspace Admin Role Assigned to a User or Group + +Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. + +*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 <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/172176?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: Identity and Access Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Assigned to a User or Group* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups. Because these roles can +grant broad administrative control over identity, devices, and security settings, role assignments should follow the +principle of least privilege (PoLP) and be carefully controlled. Threat actors may assign high-privilege roles (for +example, Super Admin or other *_ADMIN_ROLE roles) to establish persistence, expand access, and perform follow-on actions +such as creating OAuth tokens, modifying security controls, changing mail routing, or altering SSO settings. Unexpected +admin privileges can also lead to operational impact if changes are made unintentionally. + +This rule identifies when a Google Workspace administrative role is assigned to a user or a group. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that performed the change by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the target principal that received the role assignment: + - For assignments, review `user.target.email` and `user.target.name`. + - For group assignments, determine which users are members of that group at the time of assignment. +- Identify the role assigned by reviewing `google_workspace.admin.role.name`. +- Determine whether the assignment is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to grant this level of access. + - If the role is high privilege (for example, Super Admin), treat as urgent until proven benign. +- Scope for additional role assignments by searching for `event.action: ASSIGN_ROLE` over an expanded time window and filtering on: + - The same `user.email` (actor) to find other role changes performed by the same account. + - The same `google_workspace.admin.role.name` to identify other principals granted the role. + - The same target (`user.target.email`) to identify multiple roles granted to the same principal. +- Evaluate whether the target user (or group members) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + - If available, correlate with sign-in events for unusual geolocation, impossible travel, unfamiliar devices, or sign-ins from the `source.ip`. +- Determine whether the target user account was recently created by searching for `event.action: CREATE_USER` and filtering for `user.target.email`. + + +*False positive analysis* + + +- Verify the role assignment aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not performing role assignments from unusual IPs, devices, or locations. +- For group assignments, verify the group is intended for administrative delegation and validate recent membership changes that could expand who effectively received the privilege. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the assignment is not clearly authorized, remove the role assignment from the user/group and/or place the target account(s) under administrative restriction while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review the permissions assigned to the implicated user/group to ensure PoLP is being followed, and consider replacing broad roles with narrower delegated roles where feasible. +- 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:"ASSIGN_ROLE" + and google_workspace.admin.role.name : *_ADMIN_ROLE + +---------------------------------- + +*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 Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc index 85f1503e7b..4260a18872 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc @@ -1,14 +1,14 @@ [[google-workspace-admin-role-deletion]] === Google Workspace Admin Role Deletion -Detects when a custom admin role is deleted. An adversary may delete a custom admin role in order to impact the permissions or capabilities of system administrators. +Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. *Rule type*: query *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -32,9 +32,10 @@ Detects when a custom admin role is deleted. An adversary may delete a custom ad * Data Source: Google Workspace * Use Case: Identity and Access Audit * Tactic: Impact +* Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,44 +55,64 @@ Detects when a custom admin role is deleted. An adversary may delete a custom ad *Investigating Google Workspace Admin Role Deletion* -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where further domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated +privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations, +remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the +Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing +historical audit logs. -Deleted administrator roles may render some user accounts inaccessible or cause operational failure where these roles are relied upon to perform daily administrative tasks. The deletion of roles may also hinder the response and remediation actions of administrators responding to security-related alerts and events. Without specific roles assigned, users will inherit the permissions and privileges of the root organizational unit. - -This rule identifies when a Google Workspace administrative role is deleted within the Google Admin console. +This rule identifies when a custom administrative role is deleted in the Google Admin console. *Possible investigation steps* -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role deleted by reviewing `google_workspace.admin.role.name` in the alert. -- With the user identified, verify if he has administrative privileges to disable or delete administrative roles. -- To identify other users affected by this role removed, search for `event.action: ASSIGN_ROLE`. - - Add `google_workspace.admin.role.name` with the role deleted as an additional filter. - - Adjust the relative time accordingly to identify all users that were assigned this admin role. +- Identify the initiating (actor) account that deleted the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role deleted by reviewing `google_workspace.admin.role.name`. +- Determine whether the deletion is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Confirm the role is deleted in the Google Admin console: + - Navigate to Account > Admin roles. + - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list. +- Search Kibana for principals previously assigned the role to determine blast radius: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion. +- Search Kibana for privileges the deleted role contained: + - Use the following KQL example to review any privileges that were granted to the role before deletion: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "" + ``` + - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals. +- Scope for related role activity by searching for the same `user.email` (actor) performing other IAM actions such as `DELETE_ROLE`, `ADD_PRIVILEGE`, `ASSIGN_ROLE`, or security policy changes within the last 48 hours. +- Evaluate whether the deletion coincides with other suspicious activity: + - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments. *False positive analysis* -- After identifying the user account that disabled the admin role, verify the action was intentional. +- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations. +- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Discuss with the user the affected users as a result of this action to mitigate operational discrepencies. -- Disable or limit the account during the investigation and response. -- 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 user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds. +- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether the deleted role contained security-relevant privileges (for example, audit log access or security settings management) that could impair detection or response if removed. - 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). @@ -119,7 +140,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:DELETE_ROLE +data_stream.dataset:google_workspace.admin and event.action:DELETE_ROLE ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc index f078e5ecf9..4ae72bdd5a 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -1,22 +1,22 @@ [[google-workspace-api-access-granted-via-domain-wide-delegation]] === Google Workspace API Access Granted via Domain-Wide Delegation -Detects when a domain-wide delegation of authority is granted to a service account. Domain-wide delegation can be configured to grant third-party and internal applications to access the data of Google Workspace users. An adversary may configure domain-wide delegation to maintain access to their target’s data. +Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. *Rule type*: query *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium *Risk score*: 47 -*Runs every*: 5m +*Runs every*: 10m -*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -33,8 +33,9 @@ Detects when a domain-wide delegation of authority is granted to a service accou * Use Case: Identity and Access Audit * Resources: Investigation Guide * Tactic: Persistence +* Tactic: Privilege Escalation -*Version*: 211 +*Version*: 212 *Rule authors*: @@ -54,38 +55,66 @@ Detects when a domain-wide delegation of authority is granted to a service accou *Investigating Google Workspace API Access Granted via Domain-Wide Delegation* -Domain-wide delegation is a feature that allows apps to access users' data across an organization's Google Workspace environment. Only super admins can manage domain-wide delegation, and they must specify each API scope that the application can access. Google Workspace services all have APIs that can be interacted with after domain-wide delegation is established with an OAuth2 client ID of the application. Typically, GCP service accounts and applications are created where the Google Workspace APIs are enabled, thus allowing the application to access resources and services in Google Workspace. +Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on +behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes +that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD +grants create durable third-party access paths that survive individual user password resets. -Applications authorized to interact with Google Workspace resources and services through APIs have a wide range of capabilities depending on the scopes applied. If the principle of least privilege (PoLP) is not practiced when setting API scopes, threat actors could abuse additional privileges if the application is compromised. New applications created and given API access could indicate an attempt by a threat actor to register their malicious application with the Google Workspace domain in an attempt to establish a command and control foothold. - -This rule identifies when an application is authorized API client access. +This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream. *Possible investigation steps* -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. - - Only users with super admin privileges can authorize API client access. -- Identify the API client name by reviewing the `google_workspace.admin.api.client.name` field in the alert. - - If GCP audit logs are ingested, pivot to reviewing the last 48 hours of activity related to the service account ID. - - Search for the `google_workspace.admin.api.client.name` value with wildcards in the `gcp.audit.resource_name` field. - - Search for API client name and aggregated results on `event.action` to determine what the service account is being used for in GWS. -- After identifying the involved user, verify super administrative privileges to access domain-wide delegation settings. +- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and + `event.ingested` if present in the alert. +- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant + with `google_workspace.admin.domain.name`. +- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes + (for example full mail or drive access) warrant higher urgency. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the client and scopes. + - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign. +- Review DWD configuration in the Google Admin console: + - Sign in to https://admin.google.com[admin.google.com] with an authorized administrator account. + - Navigate to Security > Access and data control > API controls > Domain-wide delegation. + - Confirm the client ID, client name, and scopes match the alert fields. +- Search Kibana for related admin activity: + - Find other DWD grants or revocations by the same administrator: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS") + ``` + - Scope for all grants to the same API client: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "" + ``` + - Correlate with other high-risk admin actions from the same actor in the last 48 hours: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE") + ``` +- If GCP audit logs are ingested, pivot on the service account or client: + - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine + how the service account is being used after authorization. *False positive analysis* -- Changes to domain-wide delegation require super admin privileges. Check with the user to ensure these changes were expected. -- Review scheduled maintenance notes related to expected API access changes. +- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against + known service accounts and documented scope requirements. +- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Review the scope of the authorized API client access in Google Workspace. -- Disable or limit the account during the investigation and response. +- Initiate the incident response process based on triage findings. +- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data + control > API controls > Domain-wide delegation while the investigation proceeds. +- Rotate or disable the associated GCP service account keys if the client is suspected malicious. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review + delegated admin roles assigned to that account. +- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`. - 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. @@ -93,7 +122,7 @@ This rule identifies when an application is authorized API client access. - 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 user to ensure that the least privilege principle is being followed. +- 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). @@ -104,6 +133,7 @@ This rule identifies when an application is authorized API client access. *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: @@ -121,10 +151,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- data_stream.dataset:google_workspace.admin - and event.provider:admin - and event.category:iam and event.action:AUTHORIZE_API_CLIENT_ACCESS - and event.outcome:success ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc index f04a670d3c..8d6acac891 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc @@ -8,7 +8,7 @@ Google Workspace administrators whom manage Windows devices and have Windows dev *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -34,7 +34,7 @@ Google Workspace administrators whom manage Windows devices and have Windows dev * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -65,9 +65,10 @@ This rule identifies a user with administrative privileges and access to the adm - Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.org_unit.name`, `google_workspace.admin.setting.name`, and `google_workspace.admin.old_value` / `new_value` to confirm BitLocker was disabled and for which OU. - After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints. -- From the Google Workspace admin console, review `Reporting > Audit` and `Investigation > Device` logs, filtering on the user email identified from the alert. - - If a Google Workspace user logged into their account using a potentially compromised account, this will create an `Device sync event` event. +- Review Admin and Device logs, filtering on the user email identified from the alert. +- Confirm the policy change under `Devices` (Windows device management) or the relevant Chrome/Windows endpoint settings area for the affected OU. *False positive analysis* @@ -117,7 +118,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and event.category:(iam or configuration) +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and google_workspace.admin.new_value:"Disabled" and google_workspace.admin.setting.name:BitLocker* ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc index 1144a9ba1f..f59d93fb9c 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc @@ -1,14 +1,14 @@ [[google-workspace-custom-admin-role-created]] === Google Workspace Custom Admin Role Created -Detects when a custom admin role is created in Google Workspace. An adversary may create a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. +Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. *Rule type*: query *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -33,8 +33,9 @@ Detects when a custom admin role is created in Google Workspace. An adversary ma * Use Case: Identity and Access Audit * Resources: Investigation Guide * Tactic: Persistence +* Tactic: Privilege Escalation -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,49 +55,60 @@ Detects when a custom admin role is created in Google Workspace. An adversary ma *Investigating Google Workspace Custom Admin Role Created* -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also +be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to +a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant +access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage. -Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might create new admin roles with privileges to advance their intrusion efforts and laterally move throughout the organization if existing roles or users do not have privileges aligned with their modus operandi. Users with unexpected privileges from new admin roles may also cause operational dysfunction if unfamiliar settings are adjusted without warning. Instead of modifying existing roles, administrators might create new roles to accomplish short-term goals and unintentionally introduce additional risk exposure. - -This rule identifies when a Google Workspace administrative role is added within the Google Workspace admin console. +This rule identifies when a custom administrative role is created in the Google Admin console. *Possible investigation steps* -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role added by reviewing the `google_workspace.admin.role.name` field in the alert. -- After identifying the involved user, verify if they should have administrative privileges to add administrative roles. -- To identify if users have been assigned this role, search for `event.action: ASSIGN_ROLE`. - - Add `google_workspace.admin.role.name` with the role added as an additional filter. - - Adjust the relative time accordingly to identify all users that were possibly assigned this admin role. -- Monitor users assigned the admin role for the next 24 hours and look for attempts to use related privileges. - - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. - - The `event.action` field will help trace what actions are being taken by users. +- Identify the initiating (actor) account that created the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role created by reviewing `google_workspace.admin.role.name`. +- Determine whether the role creation is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which administrative permissions were granted. + - Review the Admins tab to see which users or groups are currently assigned the role. +- Search Kibana for role assignments to identify principals that received the new role: + - Search Google Workspace admin logs with a time range starting at the role creation timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step. +- Scope for related role activity by searching for: + - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation. + - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes. +- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. *False positive analysis* -- After identifying the user account that created the role, verify whether the action was intentional. -- Verify that the user who created the role should have administrative privileges in Google Workspace to create custom roles. -- Review organizational units or groups the role may have been added to and ensure the new privileges align properly. -- Create a filter with the user's `user.name` and filter for `event.action`. In the results, check if there are multiple `CREATE_ROLE` actions and note whether they are new or historical. +- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations. +- Compare the custom role’s privileges against the stated business need; overly broad privileges (for example, Super Admin–equivalent access) warrant closer review even if the creation was authorized. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- 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 user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible. - 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). @@ -124,7 +136,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:CREATE_ROLE +data_stream.dataset:google_workspace.admin and event.action:CREATE_ROLE ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc index e5b618df65..263b9ea8b6 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -1,14 +1,14 @@ [[google-workspace-drive-encryption-key-s-accessed-from-anonymous-user]] === Google Workspace Drive Encryption Key(s) Accessed from Anonymous User -Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users. +Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. *Rule type*: eql *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.drive-* *Severity*: high @@ -32,9 +32,10 @@ Detects when an external (anonymous) user has viewed, copied or downloaded an en * Data Source: Google Workspace * Use Case: Configuration Audit * Tactic: Credential Access +* Tactic: Collection * Resources: Investigation Guide -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -50,47 +51,53 @@ Detects when an external (anonymous) user has viewed, copied or downloaded an en *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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User* -Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings. +Threat actors and opportunistic scanners frequently abuse Google Drive links set to "Anyone with the link" to access +sensitive files without authenticating. Private keys, keystores, and token files stored in user drives are high-value +targets. Possession of these files can enable decryption of protected data, signing or impersonation, and lateral +movement into systems that trust the exposed material. + +This rule uses EQL to detect `view`, `copy`, or `download` activity in `google_workspace.drive` where +`google_workspace.drive.visibility` is `people_with_link`, `source.user.email` is empty (anonymous access), and +`file.extension` matches common key or credential file types. *Possible investigation steps* -- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query. -- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity. -- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history. -- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized. -- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access. -- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks. +- Identify the file accessed by reviewing `file.name` and `google_workspace.drive.file.type`, and note `event.action` (`view`, `copy`, or `download`) and `event.ingested`. +- Identify the file owner by reviewing `google_workspace.drive.file.owner.email` and determine whether that user should store key material in Drive. +- Review `source.user.id` and any available IP or user-agent context in the raw event to characterize the anonymous accessor. +- Confirm sharing posture in Google Drive: + - Open the file in Drive as an administrator or the owner and review Share settings. + - Verify whether access is "Anyone with the link" and whether the link was intentionally published or may have been exposed after account compromise. +- Search Kibana for related Drive activity for the same file or owner: + ``` + data_stream.dataset: "google_workspace.drive" and google_workspace.drive.file.owner.email: "" and file.name: "" + ``` + - Look for earlier `change_user_access`, `change_document_visibility`, or `rename` events that may indicate when the link was opened. + - Search for other key-like files owned by the same user with `people_with_link` visibility. +- Determine blast radius — identify which systems, applications, or cloud resources the key protects (VPN, TLS, code signing, service accounts, encrypted archives). +- Contact the file owner and security stakeholders to confirm whether anonymous access was expected (for example, a documented external audit). Treat unexpected access as high priority. *False positive analysis* -- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users. -- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account. -- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts. -- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts. -- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats. +- Legitimate use of link-based sharing for key files is rare; validate business justification before closing as benign. +- Automated scanners or DLP tools may touch public links — correlate with known security tooling and owner intent. *Response and remediation* -- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users. -- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure. -- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise. -- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use. -- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts. -- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications. -- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links. +- Initiate the incident response process based on triage findings. +- Revoke the open link or restrict sharing to specific users; move key material out of broadly link-shared locations. +- If access is unauthorized, rotate or replace the exposed keys and review dependent systems for abuse. +- Review the file owner's account for signs of compromise (unusual logins, OAuth grants, or mass sharing changes). diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..7b50072738 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc @@ -0,0 +1,157 @@ +[[google-workspace-gmail-routing-or-forwarding-rule-created-or-modified]] +=== Google Workspace Gmail Routing or Forwarding Rule Created or Modified + +Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2685650?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 +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Gmail Routing or Forwarding Rule Created or Modified* + + +Gmail administrators can change where mail is delivered using several Admin console areas under Apps > Google Workspace > Gmail: + +- Routing — specialized rules (modify message, change route, also deliver to, change envelope recipient). Audit: `UNIFIED_MAIL_ROUTING` or `MESSAGE_SECURITY_RULE` (legacy); `google_workspace.admin.setting.metadata.rule.type` may repeat the legacy type on `RuleState` rows. +- Email forwarding using recipient address map — rewrite or forward by address mapping. Audit: `ALIAS_TABLE`. +- Hosts / Outbound gateway — custom SMTP routes. Audit: `EMAIL_ROUTE`. + +Google may emit multiple admin audit events per single save (legacy `CREATE_GMAIL_SETTING`, new `CREATE_APPLICATION_SETTING`, rule body, and rule enabled state). Expect duplicate documents at the same `@timestamp`; correlate on `user.name`, `google_workspace.admin.USER_DEFINED_SETTING_NAME` (rule id), and `event.id`. + + +*Possible investigation steps* + + +- Identify the administrator (`user.name`, `user.email`) and confirm the change was authorized. +- In Admin console, review the rule matching `google_workspace.admin.USER_DEFINED_SETTING_NAME`: + - Routing (`UNIFIED_MAIL_ROUTING`, `MESSAGE_SECURITY_RULE`): Apps > Gmail > Routing + - Recipient address map (`ALIAS_TABLE`): Apps > Gmail > Default routing > Email forwarding using recipient address map + - Mail hosts / outbound gateway (`EMAIL_ROUTE`): Apps > Gmail > Hosts +- Map the alert to the admin area using `google_workspace.admin.setting.name` and `google_workspace.admin.setting.metadata.rule.type` +- Review whether the rule adds also deliver to, change envelope recipient, or routes to an external mail host or domain. +- Review related `event.action` values for the same administrator in the last 48 hours. +- If licensed for Gmail log events (BigQuery / Enterprise Plus), use Reporting > Audit and investigation > Gmail log events to confirm messages were delivered per the rule (`message_info.flattened_destinations`, `triggered_rule_info`). +- Submit suspicious URLs or attachments from affected mail to reputational services as needed. + + +*False positive analysis* + + +- Legitimate mail migrations, journaling, compliance archiving, and internal dual-delivery are common. +- Tune with exceptions for known administrator accounts, rule ids (`USER_DEFINED_SETTING_NAME`), or approved external domains. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- 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 user 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 uses `timestamp_override = event.ingested` and is configured to run every 10 minutes with a lookback of 20 minutes, aligned with the integration's default Admin poll interval (`interval`: 15m) and lag time (`lag_time`: 3m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/docs/reference/integrations/google_workspace + +==== Setup + + +The Google Workspace Fleet integration with the Admin data stream (`logs-google_workspace.admin-*`) is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:( + "CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING" + or "CREATE_APPLICATION_SETTING" or "CHANGE_APPLICATION_SETTING" +) +and ( + google_workspace.admin.setting.name:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + or "MESSAGE_SECURITY_RULE" + ) + or google_workspace.admin.setting.metadata.rule.type:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled-for-organization.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled-for-organization.asciidoc new file mode 100644 index 0000000000..6dd4b4043e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled-for-organization.asciidoc @@ -0,0 +1,196 @@ +[[google-workspace-mfa-enforcement-disabled-for-organization]] +=== Google Workspace MFA Enforcement Disabled For Organization + +Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?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: Impact +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace MFA Enforcement Disabled For Organization* + + +Threat actors with Google Workspace administrative access may disable organization-wide 2-step verification (2SV) +controls to weaken authentication for many users at once. Unlike a single user turning off 2SV on their own account, +this change affects tenant policy and can allow password-only sign-ins across an organizational unit or the entire +domain. This supports large-scale credential abuse, reduces MFA friction for follow-on compromise, and can blind +security teams if paired with other admin tampering. + +This rule identifies when an administrator sets `google_workspace.admin.new_value` to `false` for either +`ENFORCE_STRONG_AUTHENTICATION` (2SV enforcement turned off) or `ALLOW_STRONG_AUTHENTICATION` (users can no longer turn +on 2SV). + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed by reviewing `event.action`: + - `ENFORCE_STRONG_AUTHENTICATION` — 2SV enforcement was disabled for the affected scope. + - `ALLOW_STRONG_AUTHENTICATION` — users were prevented from turning on 2SV. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the prior and updated policy state. +- Determine the scope of impact by reviewing `google_workspace.admin.org_unit.name` (if present) and identifying which users or groups inherit the weakened policy. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request/ticket and that the actor is authorized to modify authentication policy. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for related authentication and admin activity: + - Use the following KQL example to find other MFA policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ENFORCE_STRONG_AUTHENTICATION" or "ALLOW_STRONG_AUTHENTICATION") + ``` + - Search for user-level 2SV disables that follow this change: + ``` + data_stream.dataset: ("google_workspace.login" or "google_workspace.user_accounts") and event.action: "2sv_disable" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as password policy changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the MFA policy change aligns with an approved change window, migration, or troubleshooting activity. +- Confirm the initiating administrator is legitimate and not acting from unusual IPs, devices, or locations. +- Even authorized changes materially weaken tenant security, validate business justification and time-bound rollback plans. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the change is not clearly authorized, restore 2SV enforcement and re-enable Allow users to turn on 2-Step Verification for the affected scope while the investigation proceeds. +- 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:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) + and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc index 01f2b98800..e969fac605 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc @@ -1,14 +1,14 @@ [[google-workspace-password-policy-modified]] === Google Workspace Password Policy Modified -Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. +Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. *Rule type*: query *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -32,9 +32,10 @@ Detects when a Google Workspace password policy is modified. An adversary may at * Data Source: Google Workspace * Use Case: Identity and Access Audit * Tactic: Persistence +* Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,47 +55,64 @@ Detects when a Google Workspace password policy is modified. An adversary may at *Investigating Google Workspace Password Policy Modified* -Google Workspace administrators manage password policies to enforce password requirements for an organization's compliance needs. Administrators have the capability to set restrictions on password length, reset frequency, reuse capability, expiration, and much more. Google Workspace also allows multi-factor authentication (MFA) and 2-step verification (2SV) for authentication. +Threat actors with Google Workspace administrative access may modify tenant password policies to weaken authentication +controls across an organizational unit or domain. Relaxing password complexity, reuse, or rotation requirements increases +the likelihood of successful password spraying, credential stuffing, and reuse of passwords exposed in third-party +breaches. Because policy changes apply to all users in scope, a single modification can materially expand the attack +surface for the entire unit. -Threat actors might rely on weak password policies or restrictions to attempt credential access by using password stuffing or spraying techniques for cloud-based user accounts. Administrators might introduce increased risk to credential access from a third-party by weakening the password restrictions for an organization. - -This rule detects when a Google Workspace password policy is modified to decrease password complexity or to adjust the reuse and reset frequency. +Saving changes in the Admin console can update multiple password settings at once. Google logs each setting change as a +separate `CHANGE_APPLICATION_SETTING` or `CREATE_APPLICATION_SETTING` event (for example, minimum length, maximum +length, reset frequency, strong password enforcement, and password reuse). Alert suppression groups by `user.email`, +`google_workspace.admin.org_unit.name`, and `source.ip` within the rule lookback so analysts receive one alert per +password policy modification session instead of one alert per setting. *Possible investigation steps* -- Identify associated user account(s) by reviewing the `user.name` or `source.user.email` fields in the alert. -- Identify the password setting that was created or adjusted by reviewing `google_workspace.admin.setting.name` field. -- Check if a password setting was enabled or disabled by reviewing the `google_workspace.admin.new_value` and `google_workspace.admin.old_value` fields. -- After identifying the involved user, verify administrative privileges are scoped properly to change. -- Filter `event.dataset` for `google_workspace.login` and aggregate by `user.name`, `event.action`. - - The `google_workspace.login.challenge_method` field can be used to identify the challenge method used for failed and successful logins. +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed in the alert by reviewing `google_workspace.admin.setting.name`. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to determine whether the change weakened policy. Examples of high-risk changes include: + - `Password Management - Enforce strong password` set to disabled + - `Password Management - Enable password reuse` set to enabled + - `Password Management - Minimum password length` reduced + - `Password Management - Password reset frequency` increased (less frequent rotation) +- Identify the scope of impact by reviewing `google_workspace.admin.org_unit.name` and determining which users inherit the updated policy. +- Determine whether the modification is expected and authorized: + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for all password settings changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` and `` as needed: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("CHANGE_APPLICATION_SETTING" or "CREATE_APPLICATION_SETTING") and user.email: "" and google_workspace.admin.setting.name: Password Management - * + ``` + - Optionally filter on `google_workspace.admin.org_unit.name: ""` to isolate changes for the same organizational unit. + - Review all `google_workspace.admin.setting.name`, `google_workspace.admin.old_value`, and `google_workspace.admin.new_value` fields returned to understand the full scope of the modification. +- Scope for related activity by searching for the same `user.email` performing other security-weakening admin actions within the last 48 hours, such as MFA enforcement changes, SSO/SAML modifications, or role assignments. *False positive analysis* -- After identifying the user account that updated the password policy, verify whether the action was intentional. -- Verify whether the user should have administrative privileges in Google Workspace to modify password policies. -- Review organizational units or groups the role may have been added to and ensure the new privileges align properly. +- Verify the password policy change aligns with an approved change window, compliance exception, or migration activity. +- Policy hardening can also generate alerts for this rule — use `old_value` and `new_value` to distinguish benign hardening from weakening changes. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Consider resetting passwords for potentially affected users. -- Disable or limit the account during the investigation and response. +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, restore password policy settings to their prior values for the affected organizational unit while the investigation proceeds. +- 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. -- Reactivate multi-factor authentication for the user. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. +- 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). @@ -122,7 +140,7 @@ The Google Workspace Fleet integration, the Filebeat module, or data that's simi [source, js] ---------------------------------- -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and +data_stream.dataset:google_workspace.admin and event.action:(CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING) and google_workspace.admin.setting.name:( "Password Management - Enforce strong password" or diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc index 9f941da0cf..9b0c5cce31 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc @@ -8,7 +8,7 @@ Detects when the Google Marketplace restrictions are changed to allow any applic *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -34,7 +34,7 @@ Detects when the Google Marketplace restrictions are changed to allow any applic * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 112 +*Version*: 113 *Rule authors*: @@ -67,6 +67,8 @@ This rule identifies when the global allow-all setting is enabled for Google Wor - Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Confirm `google_workspace.admin.new_value` is `ALLOW_ALL` and review `google_workspace.admin.old_value` for the prior restriction. +- In the admin console, verify the change under `Apps > Google Workspace Marketplace apps` (global allowlist access setting). - This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. - Search for `event.action` is `ADD_APPLICATION` to identify applications installed after these changes were made. - The `google_workspace.admin.application.name` field will help identify what applications were added. @@ -79,9 +81,8 @@ This rule identifies when the global allow-all setting is enabled for Google Wor - Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. -- Google Workspace administrators may intentionally add an application from the marketplace based on organizational needs. - - Follow up with the user who added the application to ensure this was intended. -- Verify the application identified has been assessed thoroughly by an administrator. +- Google Workspace administrators may intentionally enable allow-all marketplace access based on organizational needs. + - Follow up with the administrator who made the change to ensure this was intended. *Response and remediation* @@ -123,7 +124,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and event.category:(iam or configuration) +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" and google_workspace.event.type:"APPLICATION_SETTINGS" and google_workspace.admin.application.name:"Google Workspace Marketplace" and google_workspace.admin.setting.name:"Apps Access Setting Allowlist access" and google_workspace.admin.new_value:"ALLOW_ALL" diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc index 89b3c1ce47..45e6ece249 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc @@ -1,7 +1,7 @@ [[google-workspace-role-modified]] === Google Workspace Role Modified -Detects when a custom admin role or its permissions are modified. An adversary may modify a custom admin role in order to elevate the permissions of other user accounts and persist in their target’s environment. +Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. *Rule type*: query @@ -33,8 +33,9 @@ Detects when a custom admin role or its permissions are modified. An adversary m * Use Case: Identity and Access Audit * Resources: Investigation Guide * Tactic: Persistence +* Tactic: Privilege Escalation -*Version*: 210 +*Version*: 211 *Rule authors*: @@ -54,51 +55,68 @@ Detects when a custom admin role or its permissions are modified. An adversary m *Investigating Google Workspace Role Modified* -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt admin roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. Each Google Workspace service has a set of custodial privileges that can be added to custom roles. +Google Workspace allows administrators to modify custom admin roles by adding, removing, or updating privileges across +services such as Users, Groups, Gmail, Drive, and Security. Threat actors may expand privileges on an existing role to +establish persistence or escalate access for accounts already assigned that role, without triggering role assignment +alerts. Selecting a privilege category in the Admin console (for example, Organization Units) can add multiple related +privilege groups in a single action, each logged as a separate `ADD_PRIVILEGE` event. -Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might modify existing roles with new privileges to advance their intrusion efforts and laterally move throughout the organization. Users with unexpected privileges might also cause operational dysfunction if unfamiliar settings are adjusted without warning. - -This rule identifies when a Google Workspace role is modified. +This rule identifies when a Google Workspace role is modified via `ADD_PRIVILEGE` or `UPDATE_ROLE` events. Alert +suppression groups alerts by `user.email`, `google_workspace.admin.role.name`, and `source.ip` within a 130-minute window +(matching the rule lookback) so analysts receive one alert per role modification session instead of one alert per privilege. *Possible investigation steps* -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role modified by reviewing the `google_workspace.admin.role.name` field in the alert. -- Identify the privilege that was added or removed by reviewing the `google_workspace.admin.privilege.name` field in the alert. -- After identifying the involved user, verify administrative privileges are scoped properly. -- To identify other users with this role, search for `event.action: ASSIGN_ROLE` - - Add `google_workspace.admin.role.name` with the role added as an additional filter. - - Adjust the relative time accordingly to identify all users that were assigned this role. -- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. -- If a privilege was added, monitor users assigned this role for the next 24 hours and look for attempts to use the new privilege. - - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. - - The `event.action` field will help trace actions that are being taken by users. +- Identify the initiating (actor) account that modified the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role modified by reviewing `google_workspace.admin.role.name`. +- Identify the privilege changed by reviewing `google_workspace.admin.privilege.name`. Because suppression may group multiple events, search for all related changes in the same session (see Kibana steps below). +- Determine whether the modification is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to modify admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which permissions were added or removed and whether they align with the organization's delegation model. + - Review the Admins tab to identify which users or groups currently hold the role and will inherit the modified privileges. +- Search Kibana for all privileges changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("ADD_PRIVILEGE" or "UPDATE_ROLE") and google_workspace.admin.role.name: "" + ``` + - Optionally filter on the actor with `user.email` to isolate changes from the same administrator. + - Review all `google_workspace.admin.privilege.name` values returned to understand the full scope of the modification. +- Search Kibana for principals recently assigned the role to determine blast radius: + - Use the following KQL example: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. +- Scope for related activity by searching for the same `user.email` (actor) performing other IAM or security actions such as `ASSIGN_ROLE`, `CREATE_ROLE`, `CREATE_USER`, or security policy changes within the last 48 hours. +- Evaluate whether principals assigned the modified role performed suspicious activity after the change: + - Review admin/audit events for security control changes, user or group changes, and Gmail configuration changes. *False positive analysis* -- After identifying the user account that modified the role, verify the action was intentional. -- Verify that the user is expected to have administrative privileges in Google Workspace to modify roles. -- Review organizational units or groups the role might have been added to and ensure the new privileges align properly. -- Use the `user.name` to filter for `event.action` where `ADD_PRIVILEGE` or `UPDATE_ROLE` has been seen before to check if these actions are new or historical. +- Verify the role modification aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not modifying roles from unusual IPs, devices, or locations. +- Selecting a privilege category in the Admin console can add multiple related privileges in one action; alert suppression should consolidate these into a single alert. +- Compare the modified role's privileges against the stated business need; overly broad privileges warrant closer review even if the change was authorized. *Response and remediation* -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- 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 user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, revert the role privileges to their prior state and/or remove the role assignment from affected users or groups while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether principals assigned the modified role require the new privileges, and replace broad custom roles with narrower delegated roles where feasible. - 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). diff --git a/docs/detections/prebuilt-rules/rule-details/host-file-system-changes-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/rule-details/host-file-system-changes-via-windows-subsystem-for-linux.asciidoc index 0e57d09bd3..e41ce3689b 100644 --- a/docs/detections/prebuilt-rules/rule-details/host-file-system-changes-via-windows-subsystem-for-linux.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/host-file-system-changes-via-windows-subsystem-for-linux.asciidoc @@ -26,6 +26,7 @@ Detects file creation and modification on the host system from the Windows Subsy *References*: * https://github.com/microsoft/WSL +* https://detect.fyi/the-interesting-case-of-wsl-for-payload-staging-bfaa0f69329a *Tags*: @@ -39,7 +40,7 @@ Detects file creation and modification on the host system from the Windows Subsy * Resources: Investigation Guide * Data Source: SentinelOne -*Version*: 114 +*Version*: 115 *Rule authors*: @@ -69,7 +70,7 @@ Windows Subsystem for Linux (WSL) allows users to run a Linux environment direct - Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}". -- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories, excluding the Downloads folder. +- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories. - Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes. - Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern. - Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access. @@ -129,9 +130,7 @@ sequence by process.entity_id with maxspan=5m /* Plan9FileSystem CLSID - WSL Host File System Worker */ process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"] [file where host.os.type == "windows" and process.name : "dllhost.exe" and - not file.path : ( - "?:\\Users\\*\\Downloads\\*", - "?:\\Windows\\Prefetch\\DLLHOST.exe-????????.pf")] + not file.path : "?:\\Windows\\Prefetch\\DLLHOST.exe-????????.pf"] ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/ipsec-nat-traversal-port-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/ipsec-nat-traversal-port-activity.asciidoc index 8d217f7ffc..7fd3eccbe7 100644 --- a/docs/detections/prebuilt-rules/rule-details/ipsec-nat-traversal-port-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/ipsec-nat-traversal-port-activity.asciidoc @@ -12,6 +12,7 @@ This rule detects events that could be describing IPSEC NAT Traversal traffic. I * filebeat-* * logs-network_traffic.* * logs-panw.* +* logs-pfsense.log-* *Severity*: low @@ -31,9 +32,10 @@ This rule detects events that could be describing IPSEC NAT Traversal traffic. I * Domain: Endpoint * Use Case: Threat Detection * Data Source: PAN-OS +* Data Source: pfSense * Resources: Investigation Guide -*Version*: 110 +*Version*: 111 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/java-dropped-and-executed-with-dns-lookup.asciidoc b/docs/detections/prebuilt-rules/rule-details/java-dropped-and-executed-with-dns-lookup.asciidoc new file mode 100644 index 0000000000..6b7a09632c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/java-dropped-and-executed-with-dns-lookup.asciidoc @@ -0,0 +1,136 @@ +[[java-dropped-and-executed-with-dns-lookup]] +=== Java Dropped and Executed With DNS Lookup + +Identifies a recently dropped or modified javaw.exe process started from a user-writable path to run a JAR or Java classpath application, followed by a DNS lookup. Adversaries may drop Java payloads into user directories and execute them immediately to establish command and control while evading application control focused on native Windows binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Java Dropped and Executed With DNS Lookup* + + +This rule correlates a recently created or modified `javaw.exe` launch from `Users`, `ProgramData`, or `Windows\Temp` with an immediate +DNS lookup from the same process. Attackers often drop JAR-based payloads to user-writable locations and invoke them +with `-jar` or `-cp`/`-classpath` to blend in with legitimate Java usage while reaching out to command and control +infrastructure. + + +*Possible investigation steps* + + +- Review `process.executable`, `process.command_line`, and `process.args` to identify the JAR or classpath target and + whether the path is user-writable or unexpected for the host role. +- Inspect `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` to confirm the + binary or payload was staged immediately before execution. +- Examine the parent process tree for download, archive extraction, or script activity that may have dropped the JAR + or `javaw.exe`. +- Pivot on the DNS event for `dns.question.name`, `dns.resolved_ip`, and any follow-on connection attempts from the + same `process.entity_id`. +- Check code signature details for `javaw.exe` and any referenced JAR files when file telemetry is available. +- Hunt for the same JAR hash, command line, or queried domain on other hosts. + + +*False positive analysis* + + +- Developer workflows, local Java applications, and enterprise tools may run freshly updated JARs from user profiles or + `ProgramData`. Validate the JAR path, signer, parent process, and queried domain against known software before + closing as benign. +- Some installers or updaters drop a private JRE under `ProgramData` and launch JAR utilities during setup. Confirm the + activity aligns with a known deployment or update window. + + +*Response and remediation* + + +- Isolate the host if the JAR, domain, or parent activity appears malicious. +- Quarantine the dropped JAR, related Java runtime files, and any staging artifacts identified in the process tree. +- Block malicious domains or IPs at DNS and network enforcement points. +- Reset credentials for accounts active on the host during the suspicious session if follow-on activity is observed. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and + (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) and + (process.name : "javaw.exe" or process.pe.original_file_name == "javaw.exe") and process.executable : ("?:\\Users\\*", "?:\\ProgramData\\*", "?:\\Windows\\Temp\\*") and user.id != "S-1-5-18" and + ( + (process.args_count == 3 and process.args : "-jar") or + (process.args_count == 4 and process.args : ("-cp", "-classpath") and process.command_line : " *.* ") + )] + [network where host.os.type == "windows" and event.action: "lookup_requested"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc index 885114f438..9340282029 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc @@ -43,7 +43,7 @@ Detects the use of the insmod binary to load a Linux kernel object file. Threat * Data Source: Crowdstrike * Resources: Investigation Guide -*Version*: 216 +*Version*: 217 *Rule authors*: @@ -197,7 +197,15 @@ not ( "/usr/bin/kcarectl", "/usr/share/ksplice/ksplice-apply", "/opt/commvault/Base/linux_drv", "/usr/sbin/veeamsnap-loader", "/bin/falcoctl" ) or - (?process.parent.name like ("python*", "platform-python*") and ?process.parent.args in ("--smart-update", "--auto-update")) + (?process.parent.name like ("python*", "platform-python*") and ?process.parent.args in ("--smart-update", "--auto-update")) or + ( + process.name == "modprobe" and process.args == "-q" and process.args == "--" and process.args in ("net-pf-10", "netdev-", "binfmt-464c") + ) or + ( + process.name == "modprobe" and process.args == "-n" and process.args == "-v" and process.args in ("usb-storage", "dccp", "squashfs", "udf", "sctp", "cramfs", "hfsplus") + ) or + ?process.parent.executable like ("/sbin/iptables-multi*", "/var/ossec/bin/wazuh-modulesd", "/usr/sbin/mkinitramfs", "/usr/share/initramfs-tools/hooks/lvm2") or + ?process.parent.args like "/usr/share/initramfs-tools/hooks/*" ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc index cd84242b94..3cbae0652e 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc @@ -41,7 +41,7 @@ Identifies attempts to add a user to a privileged group. Attackers may add users * Data Source: Crowdstrike * Data Source: SentinelOne -*Version*: 114 +*Version*: 115 *Rule authors*: @@ -75,7 +75,7 @@ This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign *Possible investigation steps* -- Investigate whether the user was succesfully added to the privileged group. +- Investigate whether the user was successfully added to the privileged group. - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} - Investigate whether the user is currently logged in and active. - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} @@ -160,6 +160,16 @@ process.executable != null and process.args in ( ( process.name in ("usermod", "adduser") or (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) +) and +not ( + ?process.parent.executable like ( + "/usr/lib/google/guest_agent/core_plugin", "/usr/libexec/platform-python*", "/usr/lib/google/guest_agent/GuestAgentCorePlugin/core_plugin", + "/usr/bin/google_guest_agent" + ) or + ( + ?process.entry_leader.executable == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.entry_leader.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc new file mode 100644 index 0000000000..4e0fb601e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc @@ -0,0 +1,152 @@ +[[m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device]] +=== M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device) + +Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) from a device reported as non-compliant in the Microsoft 365 unified audit log for the first time within the rule's historical window (defined by the new terms history setting), independent of the requesting application or target resource. A match means the user has not been seen in this flow during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token, typically completed from a personal or attacker-controlled device that is not enrolled or compliant. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Examine `o365.audit.DeviceProperties` to understand the device posture (compliance, management state, OS, browser) and whether the device is recognized for this user. +- Confirm `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the application and resource the grant was for. Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and developer tooling (Azure CLI, PowerShell) are commonly abused. +- Inspect `source.as.number`, `source.as.organization.name`, `source.ip`, and `source.geo.*` and compare with the user's normal sign-in origins. Hosting, VPN, or datacenter providers are unusual for interactive user authentication. +- Examine `user_agent.original` for automation or headless-browser patterns. +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration). +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in on a personal or non-compliant device. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows using the device code flow on an unmanaged device. +- If a user or device combination is confirmed benign and recurring, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it, and require compliant or hybrid-joined devices, via Conditional Access policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..223ec62aea --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,154 @@ +[[m365-identity-device-code-grant-with-unusual-user-and-asn]] +=== M365 Identity Device Code Grant with Unusual User and ASN + +Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant with Unusual User and ASN* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) to the Microsoft Authentication Broker for Microsoft Graph from a source ASN not seen for that user within the rule's historical window (defined by the new terms history setting). A match means the user has not authenticated via this flow from that ASN during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token. The grant therefore frequently appears from residential proxy or hosting/datacenter infrastructure the user has not authenticated from during the window. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Inspect `source.as.number` and `source.as.organization.name` for the source ASN. Hosting, VPN, or datacenter providers (for example Tencent, Alibaba, DigitalOcean) are unusual for interactive user authentication. +- Review `source.ip`, `source.geo.country_name`, and `source.geo.city_name` and compare with the user's normal sign-in locations. +- Examine `o365.audit.DeviceProperties` and `user_agent.original` for non-managed devices and automation or headless-browser patterns. +- Confirm `o365.audit.ApplicationId` is the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and `o365.audit.Target.ID` is Microsoft Graph (`00000003-0000-0000-c000-000000000000`). +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, including `is_interactive`, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration) from the same or related ASNs. +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in from a new ISP, mobile carrier, corporate VPN, or while traveling. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows that use the device code flow against the Authentication Broker. +- If a source ASN is confirmed benign and recurring for the environment, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it via Conditional Access authentication flow policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.ApplicationId: "29d9ed98-a469-4536-ade2-f981bc1d605e" + and o365.audit.Target.ID: "00000003-0000-0000-c000-000000000000" + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc new file mode 100644 index 0000000000..a329c0fad7 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc @@ -0,0 +1,134 @@ +[[m365-teams-rogue-help-desk-chat-created]] +=== M365 Teams Rogue Help Desk Chat Created + +Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/ +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Teams Rogue Help Desk Chat Created* + + +Threat actors create external Microsoft 365 tenants and initiate unsolicited one-on-one Teams chats while impersonating +IT help desk or Microsoft security personnel. These chats often precede vishing, Quick Assist abuse, or malicious link +delivery. + +Review `user.email`, `user.domain`, `o365.audit.Members.DisplayName`, `o365.audit.ChatThreadId`, and +`o365.audit.ParticipantInfo`. Correlate follow-on `MessageSent` events for `source.ip` and `source.geo`, and +`CallParticipantDetail` events sharing the same `o365.audit.CallId` or chat thread for vishing activity. + + +*Possible investigation steps* + + +- Identify the external sender from `user.email`, `user.domain`, and `o365.audit.Members` and determine whether the + tenant or domain is known and trusted. +- Compare `user.name` to `o365.audit.Members.DisplayName` — actors often use a lowercase mailbox alias such as + `helpdesk` while presenting as `Help Desk` in Teams. +- Confirm `o365.audit.ParticipantInfo.HasForeignTenantUsers` is true and that no guest users are involved. +- Pivot on `o365.audit.ChatThreadId` for `MessageSent` and `CallParticipantDetail` events in the same session. +- Review `MessageSent` `source.ip` and `source.geo` for unexpected origin countries relative to the sender profile. +- Correlate with mail-flood, MFA fatigue, or URL click alerts for the targeted user in the same time window. +- Review whether the victim accepted the chat or responded, and hunt for follow-on remote support tool execution on + their endpoint. +- Check whether the sender tenant appears newly created, trial-based, or otherwise anomalous for your environment. + + +*False positive analysis* + + +- Approved external support vendors may use help desk-style display names. Maintain an allowlist of trusted external + tenants or sender domains when recurring benign matches occur. +- The `user.email` and `user.name` impersonation clauses target external mailbox aliases such as `helpdesk@`. Prefer + exceptions anchored on verified tenant IDs or sender domains rather than broad name-based exclusions. + + +*Response and remediation* + + +- Warn the targeted user not to engage and confirm whether they accepted the chat or shared credentials. +- Block or restrict the external tenant via Teams federation policy if malicious. +- Hunt for additional `ChatCreated` events from the same external tenant across the organization. +- Review Teams external access settings and consider blocking trial tenants or restricting federation to an allowlist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider:"MicrosoftTeams" and event.outcome:"success" and + o365.audit.ParticipantInfo.HasOtherGuestUsers:false and o365.audit.ParticipantInfo.HasGuestUsers:false and + o365.audit.ParticipantInfo.HasForeignTenantUsers:true and o365.audit.CommunicationType:"OneOnOne" and + ( + o365.audit.Members:( + "Help Desk" or "Help Desk Team" or "Help Desk IT" or "IT Help Desk" or + "Microsoft Security" or "Microsoft Security" or "Microsoft Support" + ) or + user.email:( + *helpdesk* or *help.desk* or *help-desk* or *help_desk* or + *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support* + ) or + user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport*) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc new file mode 100644 index 0000000000..9b7c69d000 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc @@ -0,0 +1,166 @@ +[[multiple-dhcp-servers-responding-to-the-same-transaction]] +=== Multiple DHCP Servers Responding to the Same Transaction + +Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-44815 +* https://nvd.nist.gov/vuln/detail/CVE-2024-3661 +* https://www.leviathansecurity.com/blog/tunnelvision +* https://nvd.nist.gov/vuln/detail/CVE-2018-5732 +* https://msrc.microsoft.com/update-guide + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*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 Multiple DHCP Servers Responding to the Same Transaction* + + +DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response +on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining +precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly +that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second +window, and is operating-system agnostic, since it keys only on server behavior observed on the wire. + + +*Possible investigation steps* + + +- Identify the server source IPs in `Esql.values_server_ips` and `Esql.values_server_identifiers`. Determine which is + the sanctioned DHCP server and which is unexpected. +- Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the + victim by definition. +- Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile + configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy + auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass). +- Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their + endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution. + Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g. + CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient). + + +*False positive analysis* + + +- DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two + peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or + load-balancing architecture genuinely does this, add its server IPs to an exception. +- DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each + transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known + architectural fact, which can be excepted by those IPs. + + +*Response and remediation* + + +- Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch + Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix). +- Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a + compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire/renew leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. A +sensor not on the same L2 broadcast domain (or not behind the relevant DHCP relay) will not observe competing OFFER/ACK +packets. + +Zeek is intentionally not supported: the zeek.dhcp data stream does not expose a transaction ID and aggregates a full +DORA exchange into one record, so the per-transaction server-count comparison cannot be expressed on it. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.transaction_id = COALESCE(network_traffic.dhcpv4.transaction_id, dhcpv4.transaction_id), + server_identifier = COALESCE(network_traffic.dhcpv4.option.server_identifier, dhcpv4.option.server_identifier) +| where message_type in ("offer", "ack") and Esql.transaction_id is not null and source.ip is not null +| eval Esql.time_window = DATE_TRUNC(30 seconds, @timestamp) +| stats + Esql.count_distinct_servers = COUNT_DISTINCT(source.ip), + Esql.values_server_ips = VALUES(source.ip), + Esql.values_server_identifiers = VALUES(server_identifier), + Esql.count_replies = COUNT(*) + by Esql.time_window, Esql.transaction_id +| where Esql.count_distinct_servers >= 2 +| keep Esql.transaction_id, Esql.time_window, Esql.count_distinct_servers, Esql.values_server_ips, Esql.values_server_identifiers, Esql.count_replies + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: DHCP Spoofing +** ID: T1557.003 +** Reference URL: https://attack.mitre.org/techniques/T1557/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-version-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-version-discovery.asciidoc index 22947730b4..12a78bf54a 100644 --- a/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-version-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/pluggable-authentication-module-pam-version-discovery.asciidoc @@ -41,7 +41,7 @@ This rule detects PAM version discovery activity on Linux systems. PAM version d * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 107 +*Version*: 108 *Rule authors*: @@ -149,10 +149,17 @@ process where host.os.type == "linux" and event.type == "start" and not ( ?process.parent.name in ("dcservice", "inspectorssmplugin") or ?process.working_directory in ("/var/ossec", "/opt/msp-agent") or + ?process.entry_leader.executable in("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/usr/sbin/ScanAssistant") or ?process.parent.executable in ( "/opt/CyberCNSAgent/cybercnsagent_linux", "/usr/local/manageengine/uems_agent/bin/dcpatchscan", "/usr/local/manageengine/uems_agent/bin/dcconfig", "/usr/share/vicarius/topiad", - "/etc/rc.d/init.d/sshd-chroot" + "/etc/rc.d/init.d/sshd-chroot", "/var/ossec/bin/wazuh-modulesd", + "/usr/lib/venv-salt-minion/bin/python.original" + ) or + ( + process.executable == "/usr/bin/rpm" and + ?process.parent.name == "systemd" and + ?process.env_vars == "LD_LIBRARY_PATH=/usr/lib/venv-salt-minion/lib" ) ) diff --git a/docs/detections/prebuilt-rules/rule-details/polkit-version-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/polkit-version-discovery.asciidoc index b6a29de02e..0268d295dc 100644 --- a/docs/detections/prebuilt-rules/rule-details/polkit-version-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/polkit-version-discovery.asciidoc @@ -39,7 +39,7 @@ This rule detects Polkit version discovery activity on Linux systems. Polkit ver * Data Source: Auditd Manager * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -142,7 +142,12 @@ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_start ) and not ( ?process.working_directory in ("/opt/msp-agent", "/opt/CyberCNSAgent") or - ?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") + ?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") or + ?process.entry_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/sf/edr/agent/bin/edr_monitor") or + ( + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc new file mode 100644 index 0000000000..def4e8665c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc @@ -0,0 +1,163 @@ +[[potential-amsi-bypass-via-rpc-runtime-hooking]] +=== Potential AMSI Bypass via RPC Runtime Hooking + +Identifies PowerShell script block content associated with an Antimalware Scan Interface (AMSI) bypass that hooks the RPC runtime marshaling stub NdrClientCall3 (or NdrClientCall2) in rpcrt4.dll. Unlike bypasses that patch AmsiScanBuffer or set amsiInitFailed, this technique operates at the RPC layer used by AMSI to delegate scan requests to the antivirus provider, tampering with the request before it reaches the engine and leaving AMSI itself unmodified. The loader allocates an executable trampoline and marshals a delegate to the native stub; these primitives appear in PowerShell Script Block Logging before the hook takes effect. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/andreisss/Ghosting-AMSI + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: PowerShell Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AMSI Bypass via RPC Runtime Hooking* + + +The Antimalware Scan Interface (AMSI) delegates scan requests to the registered antivirus provider over RPC. By hooking +the RPC runtime marshaling stub `NdrClientCall3`/`NdrClientCall2` in `rpcrt4.dll`, an adversary can tamper with these +requests so that malicious content is reported as clean, without modifying `amsi.dll` or patching `AmsiScanBuffer`. +This makes the bypass harder to catch via AMSI buffer or memory-write telemetry; the most reliable host artifact is the +loader's own PowerShell script content, captured by Script Block Logging. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` for references to `NdrClientCall3`/`NdrClientCall2`, resolution of + functions in `rpcrt4.dll`, allocation of executable (`PAGE_EXECUTE_READWRITE`) memory, and delegate marshaling via + `GetDelegateForFunctionPointer`. +- PowerShell logs each statement as a separate event; pivot on `host.id` and the PowerShell process id to reconstruct + the full loader sequence and confirm intent. +- Identify how PowerShell was launched (interactive, encoded command, remote session) and review the parent process + tree for download or staging activity. +- Correlate with Elastic Defend endpoint telemetry on the same host around the same time. Note that this RPC-layer hook + may not surface as a memory modification of `rpcrt4.dll`, which is expected for this technique. +- Hunt for the same script content, user, or host pattern across the environment. + + +*False positive analysis* + + +- Security research, detection engineering, and red-team development that legitimately references the RPC runtime + marshaling functions or allocates executable memory from PowerShell can match. Validate the user, host, parent + process, and surrounding script blocks against authorized testing before closing as benign, and add exceptions for + known testing identities or hosts. + + +*Response and remediation* + + +- Isolate the host if the activity is confirmed malicious and review for follow-on payload execution that the bypass + was intended to conceal. +- Terminate the offending PowerShell session and preserve the Script Block Logging events for analysis. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, or WDAC. +- Reset credentials for accounts active on the host during the session if follow-on activity is observed. + + +*Limitations* + + +This rule detects the technique only when it is delivered as logged PowerShell script-block text. In-memory delivery, a +PowerShell v2 downgrade, or implementing the hook outside PowerShell (compiled binary) can evade Script Block Logging +and therefore this rule. For customers running Elastic Defend, prefer the companion Endpoint Rule which detects the +VirtualProtect call targeting rpcrt4.dll!NdrClientCall* directly via API telemetry and is not dependent on Script +Block Logging. + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (event ID 4104). The +`Microsoft-Windows-PowerShell/Operational` channel must be collected by the Windows integration or Winlogbeat. + +Setup instructions: https://ela.st/powershell-logging-setup + +==== Rule query + + +[source, js] +---------------------------------- +event.code: "4104" and host.os.type: "windows" and + powershell.file.script_block_text : ( + "NdrClientCall" or + "NdrClientCall2" or + "NdrClientCall3" + ) and + powershell.file.script_block_text : ( + "GetProcAddress" or + "GetDelegateForFunctionPointer" or + "VirtualProtect" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc index 6df7f6d5be..4029fbf58f 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc @@ -9,6 +9,7 @@ Identifies the network signature of CVE-2026-41940, a pre-auth root-level authen * packetbeat-* * logs-network_traffic.http* +* logs-zeek.http* *Severity*: high @@ -40,9 +41,10 @@ Identifies the network signature of CVE-2026-41940, a pre-auth root-level authen * Tactic: Initial Access * Data Source: Network Packet Capture * Data Source: Network Traffic +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -151,12 +153,37 @@ The rule requires all of the following on a single decoded HTTP transaction matc *Setup* -This rule requires HTTP traffic decoded by the Network Packet Capture integration (or legacy Packetbeat) with cPanel -admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that -`http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports -(2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. Because cPanel -admin traffic is normally TLS, the sensor needs decryption visibility (TLS interception, sidecar on the host, or -sensor on the management network upstream of TLS termination) for this rule to observe HTTP fields. +This rule supports two data sources: + +1. **Network Packet Capture / Packetbeat (preferred):** Requires the Network Packet Capture integration (or legacy + Packetbeat) with cPanel admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that + `http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports + (2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. +2. **Zeek HTTP logs (`zeek.http`):** Zeek records only the names of HTTP request and response headers in + `zeek.http.client_header_names` and `zeek.http.server_header_names`, not their values. The Zeek branch of this rule + therefore matches on the presence of `AUTHORIZATION` and `LOCATION` headers on a `GET /` to a cPanel admin port, + which is a less precise but still exploit-shaped signal. Confirm exploitation by retrieving the raw header values + from the upstream Zeek sensor or correlated packet capture. + + The Zeek branch has non-default sensor prerequisites that must be met or it will never match: + - **Header-name logging is not enabled by default.** `client_header_names` and `server_header_names` are produced by + the policy script `policy/protocols/http/header-names.zeek`, which is not loaded by `base/protocols/http` or the + default `site/local.zeek`. Add `@load policy/protocols/http/header-names.zeek` to the Zeek configuration. Without + it, neither field is emitted and the Zeek branch cannot fire. + - **Server header-name logging defaults to off.** Even with the script loaded, `HTTP::log_server_header_names` + defaults to `F`, so the `server_header_names:LOCATION` condition is unsatisfiable. Set + `redef HTTP::log_server_header_names = T;` (client header-name logging is on by default). + - **Non-standard ports are handled by DPD, not a port list.** Zeek ships port-independent HTTP DPD signatures + (`base/protocols/http/dpd.sig`) that detect HTTP by payload regardless of port, so plaintext `GET /` on cPanel + admin ports (2086/2082/2095) is parsed into `zeek.http` without registering those ports. The TLS ports + (2087/2083/2096) are encrypted and yield `zeek.ssl`, not `zeek.http`, unless the sensor sits upstream of TLS + termination (see decryption note below). + +cPanel/WHM exposes paired TLS and plaintext ports: 2087 (WHM HTTPS), 2083 (cPanel HTTPS), and 2096 (Webmail HTTPS) +require decryption visibility (TLS interception, sidecar on the host, or a sensor upstream of TLS termination) for +either data source to observe HTTP headers. The plaintext counterparts — 2086 (WHM HTTP), 2082 (cPanel HTTP), and 2095 +(Webmail HTTP) — carry headers in the clear and are observable without decryption. An attacker can exploit the +vulnerability over either variant, so both sets of ports are included in this rule. ==== Rule query @@ -164,13 +191,23 @@ sensor on the management network upstream of TLS termination) for this rule to o [source, js] ---------------------------------- -(data_stream.dataset:network_traffic.http OR (event.category:network_traffic AND network.protocol:http)) AND +( + ( + (data_stream.dataset:network_traffic.http OR (event.category:network_traffic AND network.protocol:http)) AND + http.response.status_code:[300 TO 399] AND + http.request.headers.authorization:Basic* AND + http.response.headers.location:\/cpsess* + ) + OR + ( + data_stream.dataset:zeek.http AND + zeek.http.client_header_names:AUTHORIZATION AND + zeek.http.server_header_names:LOCATION + ) +) AND http.request.method:GET AND url.path:"/" AND -destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096) AND -http.response.status_code>=300 and http.response.status_code < 400 AND -http.request.headers.authorization:Basic* AND -http.response.headers.location:/cpsess* +destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc index e11bfa37d7..239ffdfbf8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc @@ -48,7 +48,7 @@ Detects the use of curl to upload files to an internet server. Threat actors oft * Data Source: Auditd Manager * Data Source: Windows Security Event Logs -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -159,7 +159,36 @@ process.name : ("curl", "curl.exe") and process.command_line like ("*http:*", "*https:*", "*ftp:*", "*ftps:*") or process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" ) and -not process.args : ("https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*") +not ( + process.args : ( + "https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", + "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", + "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*" + ) or + process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ( + process.working_directory == "/home/oracle" and + process.args == "--trace" and + process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" + ) or + ( + process.working_directory == "/home/service/common/system.check" and + process.parent.command_line == "/bin/bash ./check.sh" + ) or + ( + process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ) or + ( + process.parent.executable == "/opt/rudder/share/commands/agent-run" and + process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + process.args like "/var/rudder/reports/ready/*" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ) +) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-masquerading-as-system32-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-masquerading-as-system32-dll.asciidoc index acf72ba57d..d23b2232bf 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-masquerading-as-system32-dll.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-masquerading-as-system32-dll.asciidoc @@ -9,9 +9,9 @@ Identifies suspicious instances of default system32 DLLs either unsigned or sign * logs-endpoint.events.library-* -*Severity*: low +*Severity*: high -*Risk score*: 21 +*Risk score*: 73 *Runs every*: 5m @@ -29,9 +29,9 @@ Identifies suspicious instances of default system32 DLLs either unsigned or sign * Use Case: Threat Detection * Tactic: Defense Evasion * Tactic: Persistence -* Rule Type: BBR +* Resources: Investigation Guide -*Version*: 110 +*Version*: 111 *Rule authors*: @@ -40,12 +40,69 @@ Identifies suspicious instances of default system32 DLLs either unsigned or sign *Rule license*: Elastic License v2 +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Masquerading as System32 DLL* + + +This rule fires when a DLL with a name matching a known Windows System32 library is loaded from an unexpected path, is unsigned or signed by a non-Microsoft certificate, and was recently created or modified (within the last hour). This pattern is consistent with DLL Search Order Hijacking, DLL planting, or backdooring/resigning of legitimate system DLLs — all common defense evasion and persistence techniques used by both commodity malware and sophisticated threat actors. + + +*Possible investigation steps* + + +- Examine the full `dll.path` to determine where the suspicious DLL was loaded from. Paths under user-writable directories (`AppData`, `Temp`, `Downloads`, `ProgramData`) or application directories are high-fidelity indicators. +- Review `dll.code_signature` fields — check whether the DLL is unsigned, self-signed, or signed by an unexpected publisher. A trusted signature from a legitimate vendor may indicate a false positive; an invalid or absent signature warrants deeper investigation. +- Check `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` — a DLL dropped and loaded within seconds or minutes of each other strongly suggests staged execution. +- Identify the loading process (`process.name`, `process.executable`, `process.pid`) and examine its parent chain for unusual ancestry (e.g. Office spawning a loader, or a browser dropping a DLL). +- Retrieve the DLL and hash it with `Get-FileHash -Algorithm SHA256`. Search the hash across VirusTotal, Hybrid-Analysis, MalwareBazaar, and CISCO Talos. +- Check whether other hosts in the environment have loaded the same DLL path or hash — a single host is likely targeted or hands-on, widespread hits may indicate a worm or supply chain issue. +- Correlate with process creation events around the same timestamp to identify what dropped the DLL (downloaders, document macros, installers, etc.). +- Inspect the directory containing the DLL for other recently created files, scripts, or executables that may be part of the same drop. + + +*False positive analysis* + + +- Legitimate third-party software occasionally ships DLLs with names that collide with System32 libraries (e.g. security vendors, game engines, virtualization software, and enterprise tooling). Validate the publisher via `dll.code_signature.subject_name` and cross-reference against known software installed on the host. +- Installer and update workflows may briefly stage DLLs in temp paths before moving them to their final location — check whether the loading process is a known installer (`msiexec.exe`, `setup.exe`, vendor updaters) and whether the DLL path disappears after a short window. +- DismHost.exe staging certain DLLs under `C:\Windows\Temp\` during servicing operations is a known benign pattern already excluded in the query. + + +*Related rules* + + +- Suspicious DLL Loaded for Persistence via Desktop File - c4818812-d44f-47be-aaef-4cfb2f9cc799 +- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26 +- Potential DLL Side-Loading via Trusted Microsoft Programs - 1160dcdb-0a0a-4a79-91d8-9b84af7e0240 + + +*Response and remediation* + + +- Initiate the incident response process based on triage outcome. If the DLL is confirmed malicious, treat the host as compromised. +- Isolate the affected host and preserve a memory dump and disk image before remediation to retain forensic evidence. +- Delete the malicious DLL and any associated files identified during investigation. +- If DLL Search Order Hijacking is confirmed, identify the vulnerable application and remediate by patching, applying a safe DLL search mode (`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode`), or restricting write permissions on directories in the application's search path. +- If a legitimate binary was backdoored and resigned, treat all binaries delivered via the same channel as suspect and investigate the supply chain. +- Block identified file hashes and signer certificates as appropriate at the endpoint and perimeter. +- Hunt for lateral movement or persistence mechanisms established after the DLL was loaded — check scheduled tasks, services, registry run keys, and WMI subscriptions created around the same timeframe. +- Determine the initial access vector and remediate to prevent reinfection. + + ==== Rule query [source, js] ---------------------------------- -library where event.action == "load" and dll.Ext.relative_file_creation_time <= 3600 and +library where host.os.type == "windows" and event.action == "load" and +(dll.Ext.relative_file_creation_time <= 3600 or dll.Ext.relative_file_name_modify_time <= 3600) and not ( dll.path : ( "?:\\Windows\\System32\\*", @@ -91,26 +148,45 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <= ) or ( dll.name : "ucrtbase.dll" and dll.code_signature.subject_name in ( - "Proofpoint, Inc.", "Rapid7 LLC", "Eclipse.org Foundation, Inc.", "Amazon.com Services LLC", "Windows Phone" + "Proofpoint, Inc.", "Rapid7 LLC", "Eclipse.org Foundation, Inc.", "Amazon.com Services LLC", "Windows Phone", "London Jamocha Community CIC", "Palo Alto Networks (Netherlands) B.V.", "Sophos Ltd" ) and dll.code_signature.trusted == true ) or ( - dll.name : ("libcrypto.dll", "wmi.dll", "geolocation.dll", "kerberos.dll") and + dll.name : "d3d9.dll" and dll.code_signature.subject_name == "Open Source Developer Alban CLIQUET" and dll.code_signature.trusted == true + ) or + ( + dll.name : ("libcrypto.dll", "wmi.dll", "geolocation.dll", "kerberos.dll", "UpdateAgent.dll") and dll.code_signature.subject_name == "Bitdefender SRL" and dll.code_signature.trusted == true ) or (dll.name : "ICMP.dll" and dll.code_signature.subject_name == "Paessler AG" and dll.code_signature.trusted == true) or (dll.name : "dbghelp.dll" and dll.code_signature.trusted == true) or (dll.name : "DirectML.dll" and dll.code_signature.subject_name == "Adobe Inc." and dll.code_signature.trusted == true) or (dll.name : "icsvc.dll" and dll.code_signature.subject_name in ("Dell Inc", "Dell Technologies Inc.") and dll.code_signature.trusted == true) or - (dll.name : "offreg.dll" and dll.code_signature.subject_name == "Malwarebytes Inc." and dll.code_signature.trusted == true) or - (dll.name : "AppMgr.dll" and dll.code_signature.subject_name == "Autodesk, Inc" and dll.code_signature.trusted == true) or + (dll.name : "offreg.dll" and dll.code_signature.subject_name in ("Malwarebytes Inc.", "Malwarebytes Inc") and dll.code_signature.trusted == true) or + (dll.name : ("AppMgr.dll", "icuuc.dll") and dll.code_signature.subject_name in ("Autodesk, Inc", "Autodesk, Inc.") and dll.code_signature.trusted == true) or (dll.name : ("SsShim.dll", "Msi.dll", "wdscore.dll") and process.name : "DismHost.exe" and dll.path : "C:\\Windows\\Temp\\*") or + (dll.code_signature.trusted == true and + dll.code_signature.subject_name in ( + "ALIBABA CLOUD COMPUTING LTD", + "Epic Systems Corporation", + "Google LLC", + "Agilysys, Inc.", + "CD PROJEKT S.A.", + "Check Point Software Technologies Ltd.", + "Dedalus Italia S.P.A.", + "AOMEI International Network Limited", + "CHENGDU AOMEI TECHNOLOGY CO., LTD.", + "GN Hearing A/S", + "Paessler GmbH", + "Symantec Corporation")) or ( dll.path : ( "?:\\Windows\\SystemApps\\*\\dxgi.dll", "?:\\Windows\\SystemApps\\*\\wincorlib.dll", "?:\\Windows\\dxgi.dll", - "?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll" + "?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll", + "?:\\Program Files (x86)\\SAP\\FrontEnd\\SAPgui\\dbghelp.dll", + "?:\\Program Files (x86)\\Common Files\\Crystal Decision\\2.0\\bin\\atl.dll" ) ) ) diff --git a/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc index 8544c4bf2d..c75e4eede8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc @@ -38,7 +38,7 @@ Identifies a Secure Shell (SSH) client or server process creating a known SSH ba * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 215 +*Version*: 216 *Rule authors*: @@ -184,7 +184,8 @@ file where host.os.type == "linux" and event.type == "creation" and process.name "/var/run/udev/ud.pid", "/var/run/udevd.pid" ) - ) + ) and + not file.path like ("/tmp/krb5cc*", "/tmp/ansible_*", "/storage/*", "/tmp/clearsigned.message.*", "/var/sftp/refinitiv/*", "/tmp/fileutil.message.*") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc new file mode 100644 index 0000000000..69f10b7d83 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc @@ -0,0 +1,157 @@ +[[potential-redis-config-set-cron-directory-persistence-redisraider]] +=== Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider) + +This rule detects attempts to abuse Redis CONFIG SET commands to redirect the database save directory to a cron directory on Linux hosts. Attackers issue CONFIG SET dir to a cron path such as /etc/cron.d or /var/spool/cron, set a filename via CONFIG SET dbfilename, write a cron payload via SET, and then call BGSAVE to flush it to disk, establishing persistence for execution of an XMRig cryptominer. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/redisraider-mining-campaign/ +* https://attack.mitre.org/techniques/T1053/003/ +* https://attack.mitre.org/techniques/T1496/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*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 Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider)* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers exploit this to redirect Redis's BGSAVE output into system directories such as `/etc/cron.d` or `/var/spool/cron`, writing attacker-controlled content as a cron job. The RedisRaider campaign used this technique to deploy XMRig cryptominers at scale by mass-scanning IPv4 blocks for unauthenticated Redis instances. + +A related variant (not specific to RedisRaider) targets SSH key injection using `CONFIG SET dir /root/.ssh` and `CONFIG SET dbfilename authorized_keys`. Consider a companion rule for that pattern if your Redis instances are internet-exposed. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Internet-sourced CONFIG SET to a cron path is almost certainly malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the primary target of RedisRaider-style campaigns. +- Review subsequent Redis commands from the same source IP for `SET` (cron payload write) and `BGSAVE` (flush to disk), which complete the persistence chain. +- Examine the Redis host for new or modified files under `/etc/cron.d`, `/etc/cron.daily`, `/etc/cron.hourly`, `/var/spool/cron`, or `/var/spool/cron/crontabs` at or after the alert time. +- Check for XMRig or other cryptominer process execution and unexplained CPU spikes on the host. +- Review outbound network connections from the Redis host for connections to known mining pools or C2 infrastructure. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command used during backup configuration, data migration, or operational changes. Verify whether the directory is a known backup or data path rather than a system directory. +- Legitimate Redis usage will never set `dir` to `/etc/cron.d`, `/var/spool/cron`, or any other system cron directory. A match on this pattern has an extremely low false positive rate. +- Automated deployment or configuration management tools (Ansible, Chef, Puppet) may issue CONFIG SET as part of Redis setup — verify the source IP and timing against known deployment windows. + + +*Response and remediation* + + +- Immediately check the target cron directories for newly created files written by the Redis process (owner: redis, unusual content). +- If a cron file was written, delete it and terminate any spawned miner processes before remediating. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis exposed to any network is the root cause of this attack class. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*CONFIG SET dir*" and + ( + network_traffic.redis.query like~ "*/etc/cron*" or + network_traffic.redis.query like~ "*/var/spool/cron*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-ssh-authorized-key-injection.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-ssh-authorized-key-injection.asciidoc new file mode 100644 index 0000000000..ca08c0705f --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-redis-config-set-ssh-authorized-key-injection.asciidoc @@ -0,0 +1,169 @@ +[[potential-redis-config-set-ssh-authorized-key-injection]] +=== Potential Redis CONFIG SET SSH Authorized Key Injection + +This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redis.io/docs/latest/operate/oss_and_stack/management/security/ +* https://attack.mitre.org/techniques/T1098/004/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Redis CONFIG SET SSH Authorized Key Injection* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers targeting unauthenticated Redis instances exploit this to redirect BGSAVE output into `/root/.ssh/authorized_keys`, injecting their own SSH public key and establishing persistent root shell access without credentials. + +The full attack chain is: +1. `CONFIG SET dir /root/.ssh` — redirects the save path to the SSH directory +2. `CONFIG SET dbfilename authorized_keys` — sets the output filename +3. `SET key " + +ssh-rsa ATTACKER_KEY + +"` — writes the public key with surrounding newlines +4. `BGSAVE` — flushes the in-memory dataset (including the injected key) to disk + +A related variant targets cron persistence (`CONFIG SET dir /etc/cron.d`) for cryptominer deployment, as used by the RedisRaider campaign. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Any external IP issuing CONFIG SET to an SSH directory should be treated as malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the prerequisite for this attack. +- Review subsequent Redis commands from the same source IP for `SET` (key write) and `BGSAVE` (flush to disk), which complete the injection chain. +- Examine `/root/.ssh/authorized_keys` and other user SSH directories on the Redis host for unexpected or recently modified entries at or after the alert time. +- Check SSH login events on the Redis host for successful logins from unknown keys or source IPs shortly after the alert. +- Review outbound connections from the Redis host for lateral movement or C2 activity following a successful key injection. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command, but pointing it to any `/.ssh` directory has no legitimate use case. A match on this pattern has an extremely low false positive rate. +- `CONFIG SET dbfilename authorized_keys` has no legitimate operational use. Any match should be investigated immediately. +- Automated deployment tooling (Ansible, Chef, Puppet) will never target SSH directories via Redis CONFIG SET — this combination is exclusively malicious. + + +*Response and remediation* + + +- Immediately inspect `/root/.ssh/authorized_keys` and all user `~/.ssh/authorized_keys` files on the Redis host for unauthorized entries and remove them. +- Rotate SSH host keys and audit all active SSH sessions on the affected host. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis reachable from any network is the root cause. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + ( + ( + network_traffic.redis.query like~ "*CONFIG SET dir*" and + network_traffic.redis.query like~ "*/.ssh*" + ) or + ( + network_traffic.redis.query like~ "*CONFIG SET dbfilename*" and + network_traffic.redis.query like~ "*authorized_keys*" + ) + ) + +---------------------------------- + +*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: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc new file mode 100644 index 0000000000..9f3f381d4b --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc @@ -0,0 +1,160 @@ +[[potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell]] +=== Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell) + +This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2025-49844 +* https://redis.io/blog/redis-security-advisory-cve-2025-49844 +* https://www.cisa.gov/known-exploited-vulnerabilities-catalog +* https://www.wiz.io/blog/pwn2own-berlin-2025-redis-cve-2025-49844 + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*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 Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell)* + + +CVE-2025-49844 is a use-after-free in the Redis Lua interpreter. An authenticated attacker sends an EVAL command whose Lua script calls `string.rep()` to create memory pressure, then `collectgarbage('collect')` to force GC, triggering the use-after-free to achieve RCE. This rule matches on the `network_traffic.redis.query` field populated by the network_traffic (Packetbeat) Redis protocol module. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is a known trusted host or an internet address. Internet-exposed Redis (port 6379) with this pattern is almost certainly malicious. +- Confirm the destination Redis version. If unpatched (6.2.x branch: < 6.2.20; 7.2.x branch: < 7.2.11; 7.4.x branch: < 7.4.6; 8.0.x branch: < 8.0.4; 8.2.x branch: < 8.2.2), treat the alert as a high-confidence exploitation attempt. +- Review surrounding Redis commands (AUTH, CONFIG, SLAVEOF, DEBUG) from the same source IP for evidence of post-exploitation configuration tampering. +- Examine the destination host for evidence of reverse-shell establishment: outbound connections from the Redis process, new listening ports, or child process spawning (bash -i, nc, /dev/tcp patterns). +- Pivot to endpoint telemetry on the Redis host for process execution anomalies at or after the alert time. + + +*False positive analysis* + + +- `string.rep()` and `collectgarbage('collect')` are valid Lua functions individually. Their deliberate combination inside a Redis EVAL is almost exclusively associated with CVE-2025-49844 or explicit security testing. +- Authorized penetration testing and vulnerability scanning against the CVE will trigger this rule. Validate against known scanner IPs and scheduled assessment windows before escalating. + + +*Response and remediation* + + +- Immediately patch affected Redis instances: 6.2.x >= 6.2.20, 7.2.x >= 7.2.11, 7.4.x >= 7.4.6, 8.0.x >= 8.0.4, 8.2.x >= 8.2.2. +- Restrict Redis network access to trusted hosts only. Redis should never be directly reachable from the internet. +- Require authentication (`requirepass` or ACL) and rotate credentials if exploitation is suspected. +- If Lua scripting is not required, restrict EVAL via ACLs (`ACL SETUSER -eval`). +- If successful exploitation is suspected, isolate the host, collect artifacts, and rotate all credentials stored in or accessible via Redis. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. The rule matches on the `network_traffic.redis.query` field (keyword — human-readable command text) populated +for every Redis transaction; the raw wire bytes are available in `network_traffic.redis.request` (text) if +deeper inspection is needed. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation — this rule only covers unencrypted Redis* + + +Redis uses a plaintext protocol by default (port 6379, no TLS). Packetbeat can inspect the full request payload +on unencrypted connections, which is the configuration used by the vast majority of internet-exposed instances +(8,500+ vulnerable instances identified as of October 2025 were all unencrypted). + +If TLS is configured for Redis (`tls-port`, `tls-cert-file`, and `tls-key-file` in redis.conf), Packetbeat cannot +inspect the payload without TLS decryption. For TLS-protected Redis deployments, supplement this rule with +endpoint detection (process command-line arguments, system call monitoring) on the Redis host itself. + + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*EVAL*" and + network_traffic.redis.query like~ "*string.rep*" and + network_traffic.redis.query like~ "*collectgarbage*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/rule-details/quick-assist-full-control-sharing-mode-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/quick-assist-full-control-sharing-mode-enabled.asciidoc new file mode 100644 index 0000000000..6f888e0d25 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/quick-assist-full-control-sharing-mode-enabled.asciidoc @@ -0,0 +1,141 @@ +[[quick-assist-full-control-sharing-mode-enabled]] +=== Quick Assist Full Control Sharing Mode Enabled + +Identifies when Microsoft Quick Assist sharing mode is set to FullControl on a Windows host. This grants the remote helper full interactive control of the target device and may indicate IT help desk fraud, unauthorized remote access, or lateral movement preparation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.application* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ +* https://attack.mitre.org/software/S1209/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Data Source: Windows Application Event Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Quick Assist Full Control Sharing Mode Enabled* + + +Microsoft Quick Assist is a built-in remote support tool. When a sharer grants FullControl, the helper can interact with +the desktop as if physically present. Adversaries abuse Quick Assist in help desk fraud and social engineering to gain +interactive access without deploying separate remote access software. + +Quick Assist logs these transitions in the Windows Application log under the Quick Assist provider. A `setsharingmode` +command with sharing mode `FullControl` is written to `winlog.event_data.param1`, often alongside a JSON payload that +includes `"result":"true"` when consent is granted. + + +*Possible investigation steps* + + +- Review `winlog.event_data.param1` and any related Quick Assist Application log events around `@timestamp` for + `beginsharing`, `setsharingmode`, and `endsharing` commands to reconstruct the session timeline. +- Identify the local user on `host.id` who initiated or approved the session and determine whether Quick Assist use is + expected for that user, host role, or business unit. +- Correlate with process telemetry for `QuickAssist.exe` on the same host and timeframe, including parent process, + command line, and code signature details when available. +- Check for related alerts on the same `host.id` or `user.id`, such as credential access, defense evasion, or + additional remote access activity during or shortly after the session. +- If the host is a server or privileged workstation, determine whether any follow-on actions occurred during the + FullControl window, such as new logons, service creation, or lateral movement. + + +*False positive analysis* + + +- IT help desk, managed service providers, and internal support teams legitimately use Quick Assist with FullControl + during approved troubleshooting. Confirm the session aligns with an open ticket, known support staff, and expected + host and user pairings before closing as benign. +- Before creating an exception, anchor it on the minimum confirmed workflow: `host.id`, `user.id`, and recurring + support patterns. Avoid broad exceptions on the Quick Assist provider alone. + + +*Response and remediation* + + +- If confirmed malicious, terminate the Quick Assist session, isolate the affected host when feasible, and reset + credentials for accounts used or exposed during the session. +- Preserve Application log events containing `winlog.event_data.param1` and related Quick Assist telemetry before + remediation. +- Review whether Quick Assist should remain enabled organization-wide or be restricted via policy for high-value hosts. +- Hunt for additional hosts where the same remote helper pattern or concurrent Quick Assist FullControl sessions + occurred. + +==== Setup + + + +*Setup* + + +Windows Application event log collection must be enabled via the Elastic Agent System integration to ingest Application log events. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and winlog.channel:"Application" and event.provider:"Quick Assist" and event.code:"0" and + winlog.event_data.param1:(*FullControl* and *setsharingmode*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/rdp-remote-desktop-protocol-from-the-internet.asciidoc index 2628bb050c..83c52185f7 100644 --- a/docs/detections/prebuilt-rules/rule-details/rdp-remote-desktop-protocol-from-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -9,6 +9,9 @@ This rule detects network events that may indicate the use of RDP traffic from t * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* *Severity*: medium @@ -31,11 +34,14 @@ This rule detects network events that may indicate the use of RDP traffic from t * Tactic: Initial Access * Domain: Endpoint * Use Case: Threat Detection +* Data Source: Corelight * Data Source: PAN-OS * Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 110 +*Version*: 111 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc index 43682aae9f..d51826d16b 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc @@ -34,7 +34,7 @@ Detects use of the systemsetup command to enable remote SSH Login. * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -133,11 +133,23 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- process where host.os.type == "macos" and event.type in ("start", "process_started") and - process.name == "systemsetup" and - process.args like~ "-setremotelogin" and - process.args like~ "on" and - process.parent.executable != null and - not process.parent.executable like ("/usr/local/jamf/bin/jamf", "/usr/libexec/xpcproxy", "/usr/bin/sudo") +( + ( + process.name == "systemsetup" and + process.args like~ "-setremotelogin" and + process.args like~ "on" + ) or + ( + process.name == "launchctl" and + process.args in ("load", "bootstrap") and + ( + process.command_line like~ "*/System/Library/LaunchDaemons/ssh.plist*" or + process.command_line like~ "*com.openssh.sshd*" + ) + ) +) and +process.parent.executable != null and +not process.parent.executable like ("/usr/local/jamf/bin/jamf", "/usr/libexec/xpcproxy", "/usr/bin/sudo") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-from-the-internet.asciidoc index 2c320c2438..f22bbdcacf 100644 --- a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-from-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-from-the-internet.asciidoc @@ -9,6 +9,9 @@ This rule detects network events that may indicate the use of RPC traffic from t * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* *Severity*: high @@ -29,10 +32,14 @@ This rule detects network events that may indicate the use of RPC traffic from t * Tactic: Initial Access * Domain: Endpoint * Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Network Traffic * Data Source: PAN-OS +* Data Source: pfSense +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc index ee266ee6fb..accb1f41b7 100644 --- a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc @@ -9,6 +9,9 @@ This rule detects network events that may indicate the use of RPC traffic to the * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* *Severity*: high @@ -30,11 +33,14 @@ This rule detects network events that may indicate the use of RPC traffic to the * Tactic: Lateral Movement * Domain: Endpoint * Use Case: Threat Detection +* Data Source: Corelight * Data Source: PAN-OS * Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 110 +*Version*: 111 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/security-file-access-via-common-utilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/security-file-access-via-common-utilities.asciidoc index 3da2154080..e182b6e062 100644 --- a/docs/detections/prebuilt-rules/rule-details/security-file-access-via-common-utilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/security-file-access-via-common-utilities.asciidoc @@ -36,7 +36,7 @@ This rule detects sensitive security file access via common utilities on Linux s * Data Source: Elastic Endgame * Resources: Investigation Guide -*Version*: 107 +*Version*: 108 *Rule authors*: @@ -157,7 +157,12 @@ process.args like ( ?process.parent.args in ("/opt/imperva/ragent/bin/get_sys_resources.sh", "/usr/sbin/lynis", "./terra_linux.sh") or process.args == "/usr/bin/coreutils" or (process.parent.name == "pwsh" and process.parent.command_line like "*Evaluate-STIG*") or - ?process.parent.executable == "/usr/sap/audit_scripts/auto_audit_gral.sh" + ?process.parent.executable like ( + "/usr/sap/audit_scripts/auto_audit_gral.sh", "/opt/saltstack/salt/bin/python3*", "/opt/puppetlabs/puppet/bin/ruby" + ) or + ?process.entry_leader.executable like ( + "/usr/sbin/ScanAssistant", "/opt/Tanium/TaniumClient/TaniumClient", "/tmp/CVU_*resource/exectask", "/opt/nessus/sbin/nessus-service" + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/smb-windows-file-sharing-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/smb-windows-file-sharing-activity-to-the-internet.asciidoc index 684dda7e30..23c0000df9 100644 --- a/docs/detections/prebuilt-rules/rule-details/smb-windows-file-sharing-activity-to-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/smb-windows-file-sharing-activity-to-the-internet.asciidoc @@ -9,6 +9,9 @@ This rule detects network events that may indicate the use of Windows file shari * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* *Severity*: medium @@ -30,11 +33,14 @@ This rule detects network events that may indicate the use of Windows file shari * Tactic: Exfiltration * Domain: Network * Use Case: Threat Detection +* Data Source: Corelight * Data Source: PAN-OS * Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -97,7 +103,7 @@ SMB, a protocol for sharing files and resources within trusted networks, is vuln [source, js] ---------------------------------- -(data_stream.dataset:network_traffic.flow or event.category:(network or network_traffic)) +(data_stream.dataset:(network_traffic.flow or zeek.smb_cmd or zeek.smb_files or zeek.smb_mapping) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:(139 or 445) 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 diff --git a/docs/detections/prebuilt-rules/rule-details/smtp-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/rule-details/smtp-on-port-26-tcp.asciidoc index 33f6851f30..654a1fa20b 100644 --- a/docs/detections/prebuilt-rules/rule-details/smtp-on-port-26-tcp.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/smtp-on-port-26-tcp.asciidoc @@ -9,6 +9,9 @@ This rule detects events that may indicate use of SMTP on TCP port 26. This port * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* *Severity*: low @@ -31,11 +34,14 @@ This rule detects events that may indicate use of SMTP on TCP port 26. This port * Tactic: Exfiltration * Domain: Endpoint * Use Case: Threat Detection +* Data Source: Corelight * Data Source: PAN-OS * Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-child-execution-via-web-server.asciidoc index 2730c59b6a..64721dc23f 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-child-execution-via-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-child-execution-via-web-server.asciidoc @@ -35,7 +35,7 @@ Identifies suspicious child processes executed via a web server, which may sugge * Resources: Investigation Guide * Data Source: Elastic Defend -*Version*: 114 +*Version*: 115 *Rule authors*: @@ -256,12 +256,31 @@ process where host.os.type == "linux" and event.type == "start" and event.action "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", // Misc. tools - "whoami", "ifconfig", "ip", "ss", "top", "htop", "df", "du", "lsblk", "lsof", "tcpdump", + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", - "cat", "touch", "cp", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", "passwd" ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_19_resource_*/exectask*", "/u01/app/*/grid/bin/crsctl.bin", "/u01/app/*/grid/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/app/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.working_directory == "/var/lib/logrotate" and + process.name == "cat" + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-command-execution-via-web-server.asciidoc index 7e6c78aef8..679bedd9a9 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-command-execution-via-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-command-execution-via-web-server.asciidoc @@ -32,7 +32,7 @@ Identifies suspicious command executions via a web server, which may suggest a v * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -72,7 +72,16 @@ This alert fires when a Linux web server launches a shell to run commands that l - A legitimate web administration or diagnostics function may invoke `sh -c` to run commands such as `id`, `whoami`, `hostname`, or read OS metadata for status pages; verify the command matches documented application behavior and correlate it to an authorized request in web or application logs. - A normal application workflow may use the web server to unpack user uploads or stage temporary content under `/tmp`, `/var/tmp`, or `/dev/shm` during import, conversion, or update operations; verify the execution aligns with a known user action or scheduled maintenance window and that the created files are expected temporary artifacts owned by the service account. -I'm sorry, but I cannot assist with that request. + +*Response and remediation* + + +- Isolate the affected web server from the network or remove it from the load balancer immediately, preserve a forensic snapshot if possible, and block the attacker-controlled IPs, domains, and downloaded payload locations observed in the command chain. +- Hunt for and remove persistence by deleting web shells and dropped scripts in the document root, uploads, `/tmp`, `/var/tmp`, and `/dev/shm`, and by cleaning unauthorized cron entries, systemd services, startup scripts, SSH `authorized_keys`, and any attacker-created local accounts. +- Reset trust on the host by rotating application secrets, database passwords, API tokens, cloud credentials, and SSH keys that were present or reachable from the web server, and invalidate active sessions tied to the compromised application. +- Rebuild or reimage the server from a known-good source, patch the exploited web application or server component, restore only validated content and configurations, and verify no unauthorized binaries, modified packages, or backdoored application files remain before returning it to service. +- Escalate to incident response immediately if the shell command opened a reverse shell, downloaded or piped a payload into an interpreter, accessed sensitive files such as `/etc/shadow`, `.ssh`, or cloud credential stores, or if similar activity is found on additional hosts. +- Harden the environment by removing unnecessary shell execution from the application, disabling write and execute permissions in web-accessible upload and temp paths, enforcing least privilege for the web service account, enabling WAF or virtual patching for the exploited weakness, and increasing monitoring on web roots and startup locations. ==== Setup @@ -356,7 +365,7 @@ not ( ) or (process.parent.name == "java" and process.args like "chmod 777 *.csv") or process.command_line == "sh -c node -v || nodejs -v" or - process.working_directory == "/var/lib/puppet/rack/puppetmasterd" + process.working_directory like ("/var/lib/puppet/rack/puppetmasterd", "/u01/app/*/sysman/emd") ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc index 41cc9af435..5c0dfd99ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-kernel-feature-activity.asciidoc @@ -33,7 +33,7 @@ This rule detects the modification and reading of kernel features through built- * Resources: Investigation Guide * Data Source: Crowdstrike -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -122,7 +122,8 @@ not ( process.parent.executable like "/tmp/CVU_19_resource*/checkmemlock.sh" or process.parent.args == "/usr/share/mysql/mysql-systemd-start" or process.parent.command_line like "*ansible*" or - (process.parent.name in ("crond", "cron") and process.command_line like "*drop_caches*") + (process.parent.name in ("crond", "cron") and process.command_line like "*drop_caches*") or + (process.parent.name == "python.original" and process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion") ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-child-execution-via-web-server.asciidoc index 5612372cc2..114d6cfcd5 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-child-execution-via-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-execution-via-web-server.asciidoc @@ -31,7 +31,7 @@ This rule leverages the "new_terms" rule type to detect unusual child process ex * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -126,7 +126,7 @@ not ( ) or process.executable:( ./* or /boot/* or /dev/shm/* or /home/*/* or /lost+found/* or /proc/* or /root/* or /run/* or /sys/* or /tmp/* or - /var/mail/* or /var/run/* or /var/tmp/* or /var/www/* + /var/mail/* or /var/run/* or /var/tmp/* or /var/www/* or "/usr/bin/ffprobe" or "/usr/bin/ffmpeg" ) or process.parent.name:java and not process.parent.executable:/u0*/* or process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc index 2144c59b0e..6c07401b7e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc @@ -31,7 +31,7 @@ This rule leverages the "new_terms" rule type to detect unusual command executio * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -121,7 +121,11 @@ not ( process.parent.name:java and not process.parent.executable:/u0*/* or process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or - process.command_line:*/opt/sc/bin/showvulns* + process.command_line:*/opt/sc/bin/showvulns* or + (process.parent.name:nginx and process.name:busybox and process.args:gcc*/tmp/lua_*) or + (process.parent.name:apache2 and process.args:\"/usr/bin/7za*) or + (process.parent.name:zabbix_server and process.command_line:*fping*) or + (process.parent.name:php-fpm* and (process.command_line:*/usr/bin/pdftotext* or process.args:clamdscan*)) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-from-the-internet.asciidoc index 31252a597f..56e7aaec0c 100644 --- a/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-from-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-from-the-internet.asciidoc @@ -12,6 +12,7 @@ This rule detects network events that may indicate the use of VNC traffic from t * filebeat-* * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* *Severity*: high @@ -34,9 +35,10 @@ This rule detects network events that may indicate the use of VNC traffic from t * Domain: Endpoint * Use Case: Threat Detection * Data Source: PAN-OS +* Data Source: pfSense * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-to-the-internet.asciidoc index 91525d1e68..561ffa515e 100644 --- a/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-to-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/vnc-virtual-network-computing-to-the-internet.asciidoc @@ -12,6 +12,7 @@ This rule detects network events that may indicate the use of VNC traffic to the * filebeat-* * logs-network_traffic.* * logs-panw.panos* +* logs-pfsense.log-* *Severity*: medium @@ -34,9 +35,10 @@ This rule detects network events that may indicate the use of VNC traffic to the * Domain: Endpoint * Use Case: Threat Detection * Data Source: PAN-OS +* Data Source: pfSense * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: diff --git a/docs/index.asciidoc b/docs/index.asciidoc index 599a3a3153..71f53152fc 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -133,3 +133,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-23/prebuilt-rules- include::detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-26/prebuilt-rules-8-19-26-appendix.asciidoc[]